Bug 1030793 - snapshot-revert fails if cpu mode=passthrough -- XML error: Non-empty feature list specified without CPU model
snapshot-revert fails if cpu mode=passthrough -- XML error: Non-empty feature...
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ján Tomko
Depends On:
  Show dependency treegraph
Reported: 2013-11-15 02:14 EST by Georg Meier
Modified: 2014-12-11 06:15 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-12-11 06:15:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1151885 None CLOSED libvirtd loses track of a running restored guest with host-passthrough cpu 2018-06-18 09:49 EDT

  None (edit)
Description Georg Meier 2013-11-15 02:14:06 EST
Description of problem:
Internal Domain Snapshots cannot be reverted if cpu mode=passthrouh is choosen in recent libvirt versions.

Version-Release number of selected component (if applicable):
qemu 1.6.1
libvirt 1.1.4

How reproducible:

Create a snapshot of a domain with cpu mode=passthrough and afterwards revert snapshot.

Steps to Reproduce:
1. virst define 
2. virsh snapshot-create
3. virsh snapshot-revert

Actual results:
error: XML error: Non-empty feature list specified without CPU model

Expected results:
snapshot is reverted as in libvirt version 1.0

Additional info:
I have already posted to the mailing list with additional informations:
Comment 1 Kashyap Chamarthy 2014-06-27 18:10:56 EDT
I can confirm that I see the same behavior of what you noticed with versions:

  $ rpm -q libvirt-daemon-kvm qemu

  $ virsh snapshot-revert devstack2 snap1
  error: XML error: Non-empty feature list specified without CPU model

Here's the dump XML of the above guest:
<domain type='kvm' id='15'>
  <memory unit='KiB'>10485760</memory>
  <currentMemory unit='KiB'>10485760</currentMemory>
  <vcpu placement='static'>1</vcpu>
    <type arch='x86_64' machine='pc-i440fx-2.0'>hvm</type>
    <boot dev='hd'/>
  <cpu mode='host-passthrough'>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/kashyapc/vmimages/devstack2.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x7'/>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb0'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb0'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb0'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    <interface type='network'>
      <mac address='52:54:00:f3:b6:06'/>
      <source network='default'/>
      <target dev='vnet3'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    <serial type='pty'>
      <source path='/dev/pts/8'/>
      <target port='0'/>
      <alias name='serial0'/>
    <console type='pty' tty='/dev/pts/8'>
      <source path='/dev/pts/8'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
  <seclabel type='dynamic' model='selinux' relabel='yes'>

Other info

`qemu-img info` indicating an internal snapshot of the guest:

$ qemu-img info --backing-chain /home/kashyapc/vmimages/devstack2.qcow2
image: /home/kashyapc/vmimages/devstack2.qcow2
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 4.1G
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         snap1                  821M 2014-06-27 14:06:20   00:38:04.922
Format specific information:
    compat: 1.1
    lazy refcounts: false

Haven't yet done more investigation of libvirt -> QEMU interactions.
Comment 2 Kashyap Chamarthy 2014-06-28 03:05:38 EDT
I did another test, by removing CPU passthrough, but added capabilities from cpu-baseline as below:
$ virsh  capabilities | virsh cpu-baseline /dev/stdin
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>Haswell</model>
  <feature policy='require' name='abm'/>
  <feature policy='require' name='pdpe1gb'/>
  <feature policy='require' name='rdrand'/>
  <feature policy='require' name='f16c'/>
  <feature policy='require' name='osxsave'/>
  <feature policy='require' name='pdcm'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='require' name='tm2'/>
  <feature policy='require' name='est'/>
  <feature policy='require' name='smx'/>
  <feature policy='require' name='vmx'/>
  <feature policy='require' name='ds_cpl'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='dtes64'/>
  <feature policy='require' name='pbe'/>
  <feature policy='require' name='tm'/>
  <feature policy='require' name='ht'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='acpi'/>
  <feature policy='require' name='ds'/>
  <feature policy='require' name='vme'/>

And, tried to revert:

  $ virsh snapshot-revert devstack2 snap1                           
  error: XML error: Non-empty feature list specified without CPU model

That's the QEMU invocation

 /usr/bin/qemu-kvm -name devstack2 -S -machine pc-i440fx-2.0,accel=kvm,usb=off -cpu host -m 10240 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid f87a9d7a-7964-419c-b77f-dd99cd809930 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/devstack2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -drive file=/home/kashyapc/vmimages/devstack2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:f3:b6:06,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
Comment 3 Kashyap Chamarthy 2014-10-30 12:45:06 EDT
Hmm, just recently hit this, some debugging information below:


  $ rpm -q libvirt-daemon-kvm qemu-system-x86

When I attempt to revert to an internal snapshot:

  $ virsh snapshot-list node1
   Name                 Creation Time             State
   snap1                2014-06-03 14:07:28 -0400 running

  $ virsh snapshot-revert node1 snap1                                                              
  error: XML error: Non-empty feature list specified without CPU model

Contextual guest XML:

  $ virsh dumpxml node1 | grep features -A3
    <cpu mode='host-passthrough'>
    <clock offset='utc'>

I see it's thrown from here, src/conf/cpu_conf.c, from function:

    [. . .]
    367     if (n > 0) {
    368         if (!def->model && def->mode != VIR_CPU_MODE_HOST_MODEL) {
    369             virReportError(VIR_ERR_XML_ERROR, "%s",
    370                            _("Non-empty feature list specified without "
    371                              "CPU model"));
    372             goto error;
    373         }
    [. . .]

Additional info

Comment from Eric Blake on IRC: Sounds like yet another incarnation of us not outputting correct information in our dumpxml output
Comment 4 Ján Tomko 2014-10-31 11:32:13 EDT
Proposed upstream patch:
Comment 7 Ján Tomko 2014-12-11 06:15:01 EST
Fixed upstream by:
commit 15abebdecb35308ddd4d2967efa6dffa4842fac9
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2014-12-11 12:03:36 +0100

    Ignore CPU features without a model for host-passthrough
    This fixes reverting to snapshots created by older libvirt
    and allows libvirt not to lose track of a domain that
    has this in its live status XML (such as a domain
    restored from managedsave)

commit dd324bb2703b9cf619c521b2a04f186cd9734f0a
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2014-12-11 12:03:36 +0100

    Do not format CPU features without a model
    For host-passthrough CPU we don't honor the CPU
    features specified in the XML, but we allow
    outputting them via the UPDATE_CPU flag for dumpxml,
    this gives user a rough idea of what features the CPU
    might have.
    After restoring a managedsave'd domain, the features
    might end up in the live status XML (in /var/run) without
    the model. This XML cannot be parsed by the daemon after
    restart and the domain might disappear.
    This fix skips formatting the features for HOST_PASSTHROUGH
    when UPDATE_CPU is not specified, so the newly restored domains
    and newly created snapshots won't be affected.
    Note: this doesn't fix existing snapshots or already restored
    running domains.

git describe: v1.2.11-rc2-5-g15abebd

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