Upstream patch:
https://www.redhat.com/archives/libvir-list/2014-August/msg00577.html

I rebased and resent the patch from last year:
https://www.redhat.com/archives/libvir-list/2015-May/msg01085.html

Now pushed:
commit 8728a78e904de7ddfa32b7761b40d6339fa15030
Author:     Ján Tomko <jtomko>
CommitDate: 2015-06-04 10:04:44 +0200

    Always add 'console' matching the 'serial' device
    
    We have been formatting the first serial device also
    as a console device, but only if there were no other consoles.
    
    If there is a <serial> device present in the XML, but no serial
    <console>, or if there isn't any <console> at all but the domain
    definition hasn't gone through a parse->format->parse round-trip,
    the <console> device would not be formatted.
    
    Change the code to always add the stub device for the first
    serial device.
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1089914

git describe: v1.2.16-59-g8728a78

1. Define a guest with below xml file(without console)
# virsh define /dev/stdin <<EOF
<domain type='kvm'>
  <name>r7</name>
  <memory unit='KiB'>1049600</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.2.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/r7.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
    <console type='pty' tty='/dev/pts/3'>
      <source path='/dev/pts/3'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
  </devices>
</domain>
EOF
Domain r7 defined from /dev/stdin

2. delete '<console></console>' part with 'virsh edit guest'
Domain r7 XML configuration edited.

3. check console part of guest 

# virsh dumpxml r7|grep console -A3 
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

4. Start guest, check the console part and hotplug another console 
# virsh start r7 
Domain r7 started

# cat console.xml 
<console type='pty'>
    <target type='virtio'/>
</console>

# virsh attach-device  r7 console.xml 
error: Failed to attach device from console.xml
error: internal error: no virtio-serial controllers are available

# virsh dumpxml r7|grep console -A3 
    <console type='pty' tty='/dev/pts/3'>
      <source path='/dev/pts/3'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>

5. Cold-plug another console 

# virsh attach-device  r7 console.xml --config
Device attached successfully

# virsh dumpxml r7 --inactive |grep console -A3  
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <console type='pty'>
      <target type='virtio' port='1'/>
    </console>

6. Destroy/start guest, then check console again
# virsh destroy r7 
Domain r7 destroyed

# virsh start r7 
Domain r7 started

# virsh dumpxml r7   |grep console -A3  
    <console type='pty' tty='/dev/pts/3'>
      <source path='/dev/pts/3'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <console type='pty'>
      <source path='/dev/pts/5'/>
      <target type='virtio' port='1'/>
      <alias name='console1'/>
    </console>

The failure in step 4 is because there is no virtio-serial type controller, if I add '<controller type='virtio-serial></controller>', then the hot-plug will succeed. 
So, should libvirt will auto add this controller when I hot-plug a pty type console?

I'd change this bug to be verified status if it's acceptable

Auto-adding a virtio-serial controller on hotplug is unrelated to this bug.

Please file a separate bug if you think the functionality would be helpful. Personally, I do not see the need for it - we don't auto add a controller for PCI devices either. And a virtio-serial controller can be hotplugged separately.

Jan, thanks
Verify this bug.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html