Red Hat Bugzilla – Bug 1462711
cannot start VMs after upgrade from Fedora 25 to 26 Beta
Last modified: 2017-07-11 18:43:00 EDT
Description of problem:
VMs created through gnome-boxes in Fedora 25 and previously working, now cannot be started from the Boxes app after upgrading to Fedora 26beta.
Steps to Reproduce:
1. Open gnome-boxes
2. Right-click on VM
3. Select "Open in a New Window"
VM doesn't start. Error message is "Failed to start 'VM'".
Running gnome-boxes from the command line and starting a VM gives the following warning:
"(gnome-boxes:13607): Boxes-WARNING **: machine.vala:611: Failed to start <VM>: Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor, svm
virsh list --all, doesn't show anything
libvirtd is up and running
I can still see what I think are the VMs in ~/.local/share/gnome-boxes/images. But the names are not right. They're "fedora25-wor" and "fedora25-wor-2".
In ~/.config/gnome-boxes/sources/'QEMU Session', I can see the definitions for the VMs with the correct names
.config/libvirt/storage/gnome-boxes.xml has a definition for the images directoy above.
THe .config/libvirt/qemu directory has xml files for both VMs, with the correct titles and the names of the images above.
Looks like a qemu problem as per this forum post
F26 uses qemu-2.9.0-1.fc26
F25 uses qemu-2.7.1-6.fc25
Seems as though Ryzen isn't well supported in qemu 2.9.0.
My system is using a Ryzen CPU.
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD Ryzen 7 1800X Eight-Core Processor
stepping : 1
microcode : 0x800111c
cpu MHz : 2200.000
cache size : 512 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca
bugs : fxsave_leak sysret_ss_attrs null_seg
bogomips : 7199.81
TLB size : 2560 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro  
I've managed to work around the problem by editing the vm config and adding two "feature policy" entries in the CPU definition. I used "virsh edit <vm>" to do this.
The new entries can be seen in the following extract from the config:
<cpu mode='custom' match='exact' check='partial'>
<topology sockets='1' cores='8' threads='2'/>
<feature policy='disable' name='svm'/>
<feature policy='disable' name='monitor'/>
This allows the VM to start, but I'm not sure if there are any other consequences of running the config like this.
I found this hint from here: https://github.com/vagrant-libvirt/vagrant-libvirt/issues/667
This problem appears to be worked-around in the latest qemu packages. From the changelog of qemu:
* Tue Jul 04 2017 Adam Williamson <firstname.lastname@example.org> - 2:2.9.0-1.fc26.1
- Disable some qmp commands to work around an issue with libvirt 3.2
With this upgrade, I was able to start a new VM.
Also, after removing the "feature policy" entries, old VMs started again.