This series of patches improves the way in which virtio-serial port addresses are handled. See BZ1042505[1] for more background information. In a nutshell, the issue is that libvirt always assigns ports to the same virtio-serial controller (index 0). It does not take into account the maximum number of ports of the controller, nor whether there are other controllers with free ports. These patches modify the behaviour of libvirt in two ways: 1. Ports assigned out-of-range numbers are rejected right away, rather than having qemu failing at startup (see patch 2/3). 2. Ports without any explicit <address> elements are assigning a controller guaranteed to hold a free port, rather than always using controller index 0 (see patch 3/3). Care was taken to not override any field explicitly specified by the user (e.g. if the controller index is given, then that controller will be used). However, there are a few shortcomings with these patches (mostly due to my inexperience with the libvirt codebase and virtualization in general): 1. The limit of 31 ports per controller, mentioned here [2], is specific to qemu/kvm (although it is the only driver that supports virtio-serial ports for now). I've hardcoded the constant in these patches because I'm not sure how to properly contain them within qemu-specific code. There doesn't seem to be a way to query qemu to find out what the number of maximum ports are but looking at the qemu codebase indicates that the limit has always been 31. Not sure if a simple #define would be suitable for this. 2. I'm not sure how to handle the 'bus' attribute of virtio-serial port <address> elements. I haven't been able to get information regarding whether the bus is always 0, or how it affects port numbering. (So far haven't been able to start a VM with bus != 0). 3. More broadly, I'm not sure how in line these patches are with the overall design of libvirt. It seems like domain definitions should be completely independent of driver limitations, in which case enforcing a maximum number of ports at domain-definition-time might be the wrong thing to do. But since it is clear from the BZ that libvirt currently can modify the definition into an invalid unstartable state, it might be too late to go back on our word there. Advice and feedback appreciated, Jonathan [1] https://bugzilla.redhat.com/show_bug.cgi?id=1042505 [2] https://fedoraproject.org/wiki/Features/VirtioSerial?rd=VirtioSerial#Device Jonathan Lebon (3): add new function virDomainGetVirtioMaxPort check for out-of-range virtio-serial ports assign free controller to virtio-serial port src/conf/domain_conf.c | 77 ++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 66 insertions(+), 11 deletions(-) -- 1.8.3.1