Description: Two virtio console devices can be live hotpluged successfully with a same port defined in xml and both work well in guest. However, one port should not be used by two virtio console devices at the same time. How producible: Always Product version: # rpm -q libvirt libvirt-1.1.1-29.el7.x86_64 Steps: 1. prepare the following xml. #cat console.xml <console type='pty'> <target type='virtio' port='0'/> </console> 2. hot-plug device with the above xml twice. # virsh attach-device demo console.xml Device attached successfully # virsh attach-device demo console.xml Device attached successfully 3. check the xml # virsh dumpxml demo | grep console -a6 <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <console type='pty' tty='/dev/pts/3'> <source path='/dev/pts/3'/> <target type='virtio' port='0'/> <alias name='console1'/> </console> <console type='pty' tty='/dev/pts/4'> <source path='/dev/pts/4'/> <target type='virtio' port='0'/> <alias name='console2'/> </console> 4. Login guest to check if the devices work well Both work well Actual Results: in step 3: As above shows, the two virtio console devices were attached successfully and they were using the same port. Expected Results: in step 3: Should check if the port which will be used by the hotpluging device conflicts with the existing ports in domain and output error like: error: port '0' is using by xxx device.
I can not reproduce the bug on libvirt-1.2.8-11.el7.x86_64, libvirt will force to sort all console port, we can not specify the port value for any console. [root@ibm-x3850x5-06 ~]# rpm -q libvirt qemu-kvm-rhev libvirt-1.2.8-11.el7.x86_64 qemu-kvm-rhev-2.1.2-17.el7.x86_64 [root@ibm-x3850x5-06 ~]# virsh edit r7 ... <console type='pty'> <target type='serial' port='0'/> </console> <console type='pty'> <target type='virtio' port='0'/> </console> <console type='pty'> <target type='virtio' port='0'/> </console> ... After saving the domain xml, the new ports of console were generated automatically by libvirt. [root@ibm-x3850x5-06 ~]# virsh dumpxml r7 | grep \/console -B2 <console type='pty'> <target type='serial' port='0'/> </console> <console type='pty'> <target type='virtio' port='1'/> </console> <console type='pty'> <target type='virtio' port='2'/> </console>
Sorry, please ignore my comment 2, the bug still can be reproduced. [root@ibm-x3850x5-06 ~]# rpm -q libvirt qemu-kvm-rhev libvirt-1.2.8-11.el7.x86_64 qemu-kvm-rhev-2.1.2-17.el7.x86_64 [root@ibm-x3850x5-06 ~]# virsh attach-device r7 console.xml Device attached successfully [root@ibm-x3850x5-06 ~]# virsh attach-device r7 console.xml Device attached successfully [root@ibm-x3850x5-06 ~]# virsh attach-device r7 console.xml Device attached successfully [root@ibm-x3850x5-06 ~]# virsh dumpxml r7 | grep \/console -B4 <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <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> <console type='pty'> <source path='/dev/pts/6'/> <target type='virtio' port='2'/> <alias name='console2'/> </console> <console type='pty' tty='/dev/pts/7'> <source path='/dev/pts/7'/> <target type='virtio' port='0'/> <alias name='console3'/> </console> <console type='pty' tty='/dev/pts/8'> <source path='/dev/pts/8'/> <target type='virtio' port='0'/> <alias name='console4'/> </console> <console type='pty' tty='/dev/pts/9'> <source path='/dev/pts/9'/> <target type='virtio' port='0'/> <alias name='console5'/> </console>
The ports are meaningless in libvirt's qemu driver - we do not pass them down to QEMU, they only serve as a counter of serial devices. The code that hotplugs (or coldplugs) the character devices does not check the specified port and adds the device to the domain definition even if it is out of order. After a round-trip via XML, they get corrected (reported in bug 1089997) Correcting the ports in the qemuDomainAttach* APIs should fix both issues.
*** Bug 1089997 has been marked as a duplicate of this bug. ***
Removing LibvirtFirstBug tag. I think the proper fix here involves reworking how we handle <target port=X/> in the generic domain parser which is a bit too subtle for a intro task candidate.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.