2015-11-06 16:20:06 +03:00
LC_ALL=C \
PATH=/bin \
HOME=/home/test \
USER=test \
LOGNAME=test \
QEMU_AUDIO_DRV=none \
2017-04-06 19:19:48 +03:00
/usr/bin/qemu-system-i686 \
2015-11-06 17:29:41 +03:00
-name QEMUGuest1 \
2015-11-06 16:20:06 +03:00
-S \
2018-03-29 13:51:55 +03:00
-machine pc,accel=tcg,usb=off,dump-guest-core=off \
2015-11-06 16:20:06 +03:00
-m 214 \
2016-06-23 14:29:16 +03:00
-smp 1,sockets=1,cores=1,threads=1 \
2015-11-06 17:29:52 +03:00
-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
2018-03-29 13:51:55 +03:00
-display none \
2018-03-29 13:51:55 +03:00
-no-user-config \
2015-11-06 16:20:06 +03:00
-nodefaults \
2017-06-26 17:40:39 +03:00
-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
server,nowait \
2018-03-29 01:04:58 +03:00
-mon chardev=charmonitor,id=monitor,mode=control \
2018-03-29 13:51:55 +03:00
-rtc base=utc \
2018-03-29 13:51:55 +03:00
-no-shutdown \
2015-11-06 16:20:06 +03:00
-no-acpi \
-boot c \
-usb \
2016-05-20 14:49:15 +03:00
-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-1,\
readonly=on \
2012-04-17 13:16:52 +04:00
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
2015-12-28 17:13:52 +03:00
-drive file=/tmp/idedisk.img,format=raw,if=none,id=drive-ide0-0-2 \
2012-04-17 13:16:52 +04:00
-device ide-hd,bus=ide.0,unit=2,drive=drive-ide0-0-2,id=ide0-0-2 \
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)
2015-04-30 23:59:04 +03:00
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3