Bug 1042505 - Upon assigning addresses to new virtio-serial ports, libvirt can over-allocate
Upon assigning addresses to new virtio-serial ports, libvirt can over-allocate
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ján Tomko
Depends On:
Blocks: 1076708
  Show dependency treegraph
Reported: 2013-12-12 18:00 EST by Jonathan Lebon
Modified: 2015-04-02 09:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1076708 (view as bug list)
Last Closed: 2015-04-02 09:09:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Lebon 2013-12-12 18:00:23 EST
Version: current git HEAD (8edb622)

Good afternoon,

While experimenting with virtio-serial ports (using SystemTap's stapvirt
utility), we noticed something interesting. When stapvirt adds a
virtio-serial port, it simply adds the following XML

  <channel type='unix'>
    <source mode='bind' path='/my/path/to/sock.sock'/>
    <target type='virtio' name='org.systemtap.stapsh.0'/>

and relies on libvirt to get assigned to a virtio-serial controller
rather than creating an <address> element itself. So the resulting XML
might look like this:

  <channel type='unix'>
    <source mode='bind' path='/my/path/to/sock.sock'/>
    <target type='virtio' name='org.systemtap.stapsh.0'/>
    <address type='virtio-serial' controller='0' bus='0' port='1'/>

When creating another port, libvirt simply looks at previous
virtio-serial ports and adds one to the port number.

There are a few issues however:

1. libvirt will always use controller='0' and bus='0' even if there is
already a controller on a different index. This is not a big deal in
itself, since we can make a reasonable assumption that a controller
index 0 will exist before index 1, except that

2. libvirt does not respect the maximum number of ports available on a
controller. Even if the controller is declared with ports='4', libvirt
will gladly create e.g. 10 ports on that controller. This of course will
cause qemu to complain, e.g.:

error: Failed to start domain TestVM
error: internal error: early end of file from monitor: possible problem:
qemu-system-x86_64: -device
virtio-serial-bus: Out-of-range port id specified, max. allowed: 3
qemu-system-x86_64: -device
Device 'virtserialport' could not be initialized

This means that by default, libvirt will implicitly create a controller with index 0, then continuously add ports to that same controller well passed the limit of 31.


libvirt respects the 'ports' attribute of the virtio-serial controller (assume 31 if missing) and creates a new controller if all the controllers are filled.

More generally, upon assigning an address, look at all the virtio-serial controllers available (including those to be inferred) and check if there are ports available on any of them. If not, then create a new controller (e.g. set controller to max_controller_index+1 and let it get implicitly created later during the definition process).

Comment 1 Ján Tomko 2015-03-03 09:47:31 EST
Upstream patches:
Comment 2 Ján Tomko 2015-04-02 09:09:22 EDT
Fixed upstream by:
commit 5903378834bafb031407ab02ce37dcc9ec782d1f
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-04-02 15:00:13 +0200

    Allocate virtio-serial addresses when starting a domain

git describe: v1.2.14-30-g5903378

commit 371ea92f058a0df3ba55c0b398f892653cbfca3             
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-04-02 15:00:13 +0200

    Auto add virtio-serial controllers
git describe: v1.2.14-33-g1371ea9

Note You need to log in before you can comment on or make changes to this bug.