Description of problem: On Rawhide, libvirt cannot create guests. It gives the following error: could not create appliance through libvirt: unsupported configuration: CPU specification not supported by hypervisor [code=67 domain=10] Version-Release number of selected component (if applicable): libvirt-daemon-qemu-1.1.1-1.fc20.x86_64 qemu.x86_64 2:1.5.2-4.fc20 How reproducible: 100% Steps to Reproduce: 1. Try to create a guest. The full build logs: http://kojipkgs.fedoraproject.org//work/tasks/7088/5807088/build.log http://kojipkgs.fedoraproject.org//work/tasks/7088/5807088/root.log The libvirt XML is: <?xml version="1.0"?> <domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> <name>guestfs-k8y35eg6936bm6po</name> <memory unit="MiB">500</memory> <currentMemory unit="MiB">500</currentMemory> <cpu mode="host-model"> <model fallback="allow"/> </cpu> <vcpu>1</vcpu> <clock offset="utc"> <timer name="kvmclock"/> </clock> <os> <type>hvm</type> <kernel>/builddir/build/BUILD/libguestfs-1.23.15/tmp/.guestfs-500/kernel.13897</kernel> <initrd>/builddir/build/BUILD/libguestfs-1.23.15/tmp/.guestfs-500/initrd.13897</initrd> <cmdline>panic=1 console=ttyS0 udevtimeout=600 no_timer_check lpj=2533422 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=vt100</cmdline> </os> <on_reboot>destroy</on_reboot> <devices> <controller type="scsi" index="0" model="virtio-scsi"/> <disk device="disk" type="file"> <source file="/builddir/build/BUILD/libguestfs-1.23.15/tests/qemu/liveness1.img"/> <target dev="sda" bus="scsi"/> <driver name="qemu" type="raw" cache="none"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <disk type="file" device="disk"> <source file="/builddir/build/BUILD/libguestfs-1.23.15/tmp/libguestfsZBSf07/snapshot1"/> <target dev="sdb" bus="scsi"/> <driver name="qemu" type="qcow2" cache="unsafe"/> <address type="drive" controller="0" bus="0" target="1" unit="0"/> <shareable/> </disk> <serial type="unix"> <source mode="connect" path="/builddir/build/BUILD/libguestfs-1.23.15/tmp/libguestfsZBSf07/console.sock"/> <target port="0"/> </serial> <channel type="unix"> <source mode="connect" path="/builddir/build/BUILD/libguestfs-1.23.15/tmp/libguestfsZBSf07/guestfsd.sock"/> <target type="virtio" name="org.libguestfs.channel.0"/> </channel> </devices> <qemu:commandline> <qemu:env name="TMPDIR" value="/builddir/build/BUILD/libguestfs-1.23.15/tmp"/> </qemu:commandline> </domain>
If I had to guess, I'd say the reason for this is that you have type="qemu" rather than type="kvm". Is this a regression over previous libvirt, or is this CPU specification something new libguestfs is trying ?
(In reply to Daniel Berrange from comment #1) > If I had to guess, I'd say the reason for this is that you have type="qemu" > rather than type="kvm". Note it's running in Koji (ie. in a VM) so I believe type="qemu" is correct. > Is this a regression over previous libvirt, or is > this CPU specification something new libguestfs is trying ? The possible change in libguestfs is: https://github.com/libguestfs/libguestfs/commit/6f76fdb41eb6bd124fbc3d084f5c2a3371b37d9b which adds the following to the XML that was not present before: <cpu mode="host-model"> <model fallback="allow"/> </cpu> However this WFM in Fedora 19 on baremetal (on baremetal of course it's using type="kvm").
(In reply to Richard W.M. Jones from comment #2) > (In reply to Daniel Berrange from comment #1) > > Is this a regression over previous libvirt, or is > > this CPU specification something new libguestfs is trying ? > > The possible change in libguestfs is: > > https://github.com/libguestfs/libguestfs/commit/ > 6f76fdb41eb6bd124fbc3d084f5c2a3371b37d9b > > which adds the following to the XML that was not present before: > > <cpu mode="host-model"> > <model fallback="allow"/> > </cpu> > > However this WFM in Fedora 19 on baremetal (on baremetal of course > it's using type="kvm"). Ok, so since this is new libguestfs functionality, it doesn't look like a regression in libvirt. I would still expect libvirt to allow this config for QEMU though - it supports configuring CPU flags and 'host-model' is done in terms of explicit CPU flags - only 'host-passthrough' should be unsupported IIUC.
When I try to create a QEMU TCG based guest locally, it copes with mode=host-model without trouble. So wonder why it is failing in koji.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
FYI libguestfs has gone back to the old method (qemu32/qemu64 CPU) for TCG (only, not KVM). So this bug no longer affects us although it still looks like it is a bug.
There's another bug tracking cpu model + tcg weirdness, duping to that *** This bug has been marked as a duplicate of bug 1002066 ***