]> xenbits.xensource.com Git - libvirt.git/commit
qemu: log error when domain has an unsupported IDE controller
authorLaine Stump <laine@laine.org>
Thu, 30 Apr 2015 20:59:04 +0000 (16:59 -0400)
committerLaine Stump <laine@laine.org>
Fri, 15 May 2015 19:40:43 +0000 (15:40 -0400)
commiteadd757ccee0e72156a5345e6c25477aa057a9f1
tree03fb8ed8dcd32e0ca02da5534061e9bd700ee643
parentb8f345b486c3e6d0c59cff7d8c4883d158d410cb
qemu: log error when domain has an unsupported IDE controller

We have previously effectively ignored all <controller type='ide'>
elements in a domain definition.

On the i440fx-based machinetypes there is an IDE controller that is
included in the chipset and can't be removed (which is the ide
controller with index='0'>), so it makes sense to ignore that one
controller. However, if an i440fx domain definition has a 2nd
controller, nothing catches this error (unless you also have a disk
attached to it, in which case qemu will complain that you're trying to
use the ide controller named "ide1", which doesn't exist), and if any
other type of domain has even a single controller defined, it will be
incorrectly ignored.

Ignoring a bogus controller definition isn't such a big problem, as
long as an error is logged when any disk is attached to that
non-existent controller. But in the case of q35-based machinetypes,
the hardcoded id ("alias" in libvirt terms) of its builtin SATA
controller is "ide", which happens to be the same id as the builtin
IDE controller on i440fx machinetypes. So libvirt creates a
commandline believing that it is connecting the disk to the builtin
(but actually nonexistent) IDE controller, qemu thinks that libvirt
wanted that disk connected to the builtin SATA controller, and
everybody is happy.

Until you try to connect a 2nd disk to the IDE controller. Then qemu
will complain that you're trying to set unit=1 on a controller that
requires unit=0 (SATA controllers are organized differently than IDE
controllers).

After this patch, if a domain has an IDE controller defined for a
machinetype that has no IDE controllers, libvirt will log an error
about the controller itself as it is building the qemu commandline
(rather than a (possible) error from qemu about disks attached to that
controller). This is done by adding IDE to the list of controller
types that are handled in the loop that creates controller command
strings in qemuBuildCommandline() (previously it would *always* skip
IDE controllers). Then qemuBuildControllerDevStr() is modified to log
an appropriate error in the case of IDE controllers.

In the future, if we add support for extra IDE controllers (piix3-ide
and/or piix4-ide) we can just add it into the IDE case in
qemuBuildControllerDevStr(). For now, nobody seems anxious to add
extra support for an aging and very slow controller, when there are so
many better options available.

Resolves:

https://bugzilla.redhat.com/show_bug.cgi?id=1176071 (Fedora)
src/qemu/qemu_command.c
tests/qemuxml2argvdata/qemuxml2argv-disk-blockio.args
tests/qemuxml2argvdata/qemuxml2argv-disk-blockio.xml
tests/qemuxml2argvdata/qemuxml2argv-disk-ide-drive-split.args
tests/qemuxml2argvdata/qemuxml2argv-disk-ide-drive-split.xml
tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool-mode.args
tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool-mode.xml
tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool.args
tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool.xml
tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-source-pool.xml