Bug 996007 - libvirt cpu=host-model fails in koji: unsupported configuration: CPU specification not supported by hypervisor
Summary: libvirt cpu=host-model fails in koji: unsupported configuration: CPU specific...
Keywords:
Status: CLOSED DUPLICATE of bug 1002066
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2013-08-12 07:58 UTC by Richard W.M. Jones
Modified: 2014-01-16 22:06 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-16 22:06:31 UTC
Type: Bug


Attachments (Terms of Use)

Description Richard W.M. Jones 2013-08-12 07:58:50 UTC
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>

Comment 1 Daniel Berrangé 2013-08-12 09:11:13 UTC
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 ?

Comment 2 Richard W.M. Jones 2013-08-12 09:19:09 UTC
(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").

Comment 3 Daniel Berrangé 2013-08-12 09:22:26 UTC
(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.

Comment 4 Daniel Berrangé 2013-08-12 09:34:23 UTC
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.

Comment 5 Fedora End Of Life 2013-09-16 16:30:37 UTC
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

Comment 6 Richard W.M. Jones 2013-09-23 15:00:25 UTC
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.

Comment 7 Cole Robinson 2014-01-16 22:06:31 UTC
There's another bug tracking cpu model + tcg weirdness, duping to that

*** This bug has been marked as a duplicate of bug 1002066 ***


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