[libvirt] [RFC PATCH 0/3] improve virtio-serial port address allocation
jlebon at redhat.com
Mon Jan 6 16:13:20 UTC 2014
This series of patches improves the way in which virtio-serial port
addresses are handled. See BZ1042505 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
However, there are a few shortcomings with these patches (mostly due to
my inexperience with the libvirt codebase and virtualization in
1. The limit of 31 ports per controller, mentioned here , 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 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(-)
More information about the libvir-list