Host CPU does not provide required features: svm | with a intel CPU

[luk43]

When I try to "vagrant up" a machine I get a error message like this:

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

In my understanding, "svm" is the Virtualization driver for AMD CPU chips.
My CPU is an "Intel® Core™ i7-2620M CPU @ 2.70GHz × 4".
I didn't found, where this variable is set.

Here the full log:
http://pastebin.com/kpNB1BJ6

System configuration

OS/Distro version::
Arch Linux (newest packages, installed like here described: "https://wiki.archlinux.org/index.php/Vagrant#vagrant-libvirt")

Libvirt version:
libvirtd (libvirt) 2.3.0

Output of vagrant version; vagrant plugin list:
Installed Version: 1.8.6
Latest Version: 1.8.6

You're running an up-to-date version of Vagrant!
vagrant-libvirt (0.0.36)

A Vagrantfile to reproduce the issue:

Vagrant.configure("2") do |config|
  config.vm.box = "opensuse/openSUSE-42.1-x86_64"
end

I also tried this:

Vagrant.configure("2") do |config|
  config.vm.box = "opensuse/openSUSE-42.1-x86_64"
    config.vm.provider :libvirt do |libvirt|
                  libvirt.cpu_feature :name => 'vmx', :policy => 'require'
  end
end

same output.

Are you using upstream vagrant package or your distros package?
Vagrant package. As described in the Arch wiki.

Hopefully its just stupid me and not a serious bug :)
Anyway thanks for any help here!

[infernix]

Why not use nested if you want to expose those cpu flags? I'm assuming that's what you want to achieve here?

[luk43]

Okey. I have this problem:
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04717.html

    <cpu mode'custom' match='exact'>
        <model>qemu64</model>
        <feature name='svm' policy='disable'/>
    </cpu>

is a quick fix in the xml. or change the default model for all hosts.

[divansantana]

@luk43

Okey. I have this problem:
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04717.html

    <cpu mode'custom' match='exact'>                                 
        <model>qemu64</model>                                        
        <feature name='svm' policy='disable'/>                       
    </cpu>                                                           

is a quick fix in the xml. or change the default model for all hosts.

Thanks for this.

Though have you figured out how to make this the default model for all hosts?

[luk43]

@divansantana

Though have you figured out how to make this the default model for all hosts?

Maybe you can set this in /etc/libvirt/libvirtd.conf or qemu.conf, but I am not sure.
I will test this asap.
Right now I set in the Vagrantfile following:
config.vm.provider :libvirt do |libvirt| libvirt.cpu_model = "YOURMODEL" end

Maybe this an archlinux specific error, because in fedora it seems to work fine.

[divansantana]

@luk43 ah, one can also set it in the Vagrantfile. That will do for now.

Even better would be system wide, though for now the above will work for me - thanks!

If I figure out the other way, I'll post it here.

And yes, also on arch/parabola.

[dmnt3rr0r]

There is always the global Vagrantfile (~/.vagrant.d/Vagrantfile) ... That's what I'm doing for now...

[jschmid1]

For some reasons libvirt can't deduct the host model.

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

and falls back to qemu64 which appears to have the svm cpu flag required.
If you happen to be on a intel-cpu that required flag should be vmx and not svm.
Sounds like a bug in a specific version of libvirt.

2.3.0-610.4
on
openSUSE LEAP 42.2

To get around this you can change the cpu-mode to passthrough as described in the Vagrant README.

cpu_mode - CPU emulation mode. Defaults to 'host-model' if not set. Allowed values: host-model, host-passthrough, custom.

Vagrant.configure("2") do |config|
  config.vm.define :dbserver do |dbserver|
    dbserver.vm.box = "centos64"
    dbserver.vm.provider :libvirt do |domain|
      domain.cpu_mode = 'host-passthrough'
     end
  end

That seems to be the cleanest workaround as the xml configs in /etc/libvirt/qemu/dom.xml will be autogenerated by vagrant.

hth

[psivesely]

I have added

Vagrant.configure("2") do |config|
  config.vm.provider "libvirt" do |lv|
    lv.cpu_mode = 'host-passthrough'
  end
end

to my ~/.vagrant.d/Vagrantfile to do this globally. I think the vagrant-libvirt devs should re-consider their default choice of host-model (at least it appears this is what they are using--it may be a little more complicated than this--haven't poked around quite enough to yet), which the libvirt docs note as being problematic:

Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work. Until these issues are fixed, it's a good idea to avoid using host-model and use custom mode with just the CPU model from host capabilities XML.

--https://libvirt.org/formatdomain.html#elementsCPU

[infernix]

You'll find the reasoning on the exact same page:

The host-model mode is essentially a shortcut to copying host CPU definition from capabilities XML into domain XML. Since the CPU definition is copied just before starting a domain, exactly the same XML can be used on different hosts while still providing the best guest CPU each host supports.

And from the qemu-devel thread you linked:

The qemu64 CPU model contains svm and thus libvirt will always consider
it incompatible with any Intel CPUs (which have vmx instead of svm).

host-model leaves the responsibility with libvirt which should in all cases provide the best CPU that just works; if not, libvirt is at fault for not doing so. The alternative where vagrant-libvirt is selecting a cpu model is only going to introduce complications, and for the few edge cases where it is needed, there are ways to select specific models/flags.

So I don't see a compelling reason to change the default. host-passthrough would be the only sensible alternative, but then that introduces the other problem:

With this mode, the CPU visible to the guest should be exactly the same as the host CPU even in the aspects that libvirt does not understand. Though the downside of this mode is that the guest environment cannot be reproduced on different hardware. Thus, if you hit any bugs, you are on your own. Further details of that CPU can be changed using feature elements.

It's therefore a tradeoff, and i think host-model covers the largest share of use cases.