Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1386223

Summary: Libvirt is blocking me running VMS because of no svm?
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: agedosier, berrange, clalancette, crobinso, dwalsh, itamar, jdenemar, laine, libvirt-maint, pahan, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-03 19:07:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virsh dumpxml f24_atomic_default none

Description Daniel Walsh 2016-10-18 12:48:46 UTC 
vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Starting domain.
There was an error talking to Libvirt. The error message is shown
below:

Call to virDomainCreateWithFlags failed: the CPU is incompatible with host CPU: Host CPU does not provide required features: svm
Comment 1 Daniel Walsh 2016-10-18 12:50:05 UTC 
These VM's were working before but they are broken in latest rawhide.

libvirt-2.3.0-1.fc26.x86_64

Happening on both kernels.

rpm -q kernel
kernel-4.7.7-200.fc24.x86_64
kernel-4.9.0-0.rc1.git0.2.fc26.x86_64
Comment 2 Jiri Denemark 2016-10-18 20:24:28 UTC 
Would you mind sharing the domain XML with us? And since it was working before, please attach the XML from a host where it works too.
Comment 3 Daniel Walsh 2016-10-19 16:40:41 UTC 
Created attachment 1212210 [details]
virsh dumpxml f24_atomic_default
Comment 4 Daniel Walsh 2016-10-19 16:43:11 UTC 
All of my vagrant images are showing the same error.

Trying to start a Centos image via virt-manager gives me.

Error starting domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: svm

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: the CPU is incompatible with host CPU: Host CPU does not provide required features: svm
Comment 5 Daniel Berrangé 2016-10-19 17:07:30 UTC 
This is a very strange configuration:

  <cpu mode='host-model'>
    <model fallback='allow'>qemu64</model>
  </cpu>

Specifying a named model doesn't make sense when using 'host-model'. Based on the error message it sounds like libvirt is trying to use the qemu64 model, instead of the host model, and thus seeing the 'svm' flag in qemu64, which is not present in your host model.
Comment 6 Daniel Walsh 2016-10-19 20:57:36 UTC 
Could this be a bug in how vagrant creates the images then.
Comment 7 Daniel Walsh 2016-10-19 20:58:11 UTC 
Should those lines be removed or changed?
Comment 8 Jiri Denemark 2016-10-20 08:12:06 UTC 
Yeah, sounds like a bug in vagrant or whatever created the XML. And since you say it was working well before, I believe they must have changed it recently. The XML should contain just

    <cpu mode='host-model'/>

I was thinking about changing libvirt to just ignore any CPU model for host-model CPUs, but unfortunately we can't do that because of backwards compatibility. Old libvirt used to add a CPU model and features into a host-model CPU specification for migration to make sure the domain won't lose any features on the destination host. We've recently switched to properly changing host-model CPU definition into a custom one when a domain is started, but we still need to be able to consume domain XMLs generated by older libvirt.
Comment 9 Daniel Walsh 2016-10-20 18:10:34 UTC 
Made that change but I still see the same error.  Could this be a setting in my bios causing this issue?
Comment 10 Pavel Alexeev 2016-12-08 17:07:49 UTC 
Fore me helps set cpu_model to host-passthrough. Add something like:

  config.vm.provider :libvirt do |domain|
      …
      domain.cpu_mode = "host-passthrough"
  end

into Vagrantfile.
Comment 11 Fedora End Of Life 2017-02-28 10:27:56 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 12 Cole Robinson 2017-05-03 19:07:21 UTC 
Since this stalled I assume it was either fixed or worked around, so closing. If anyone is still hitting this with latest f26/rawhide bits, please reopen