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. gnome-boxes-3.24.0-3.fc26.x86_64 How reproducible: Always Steps to Reproduce: 1. Open gnome-boxes 2. Right-click on VM 3. Select "Open in a New Window" Actual results: VM doesn't start. Error message is "Failed to start 'VM'". Expected results: VM starts Additional info: 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 https://forum.manjaro.org/t/virtual-machines-in-gnome-boxes-wont-start/24312 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 [13] [14]
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'> <model fallback='allow'>Opteron_G3</model> <topology sockets='1' cores='8' threads='2'/> <feature policy='disable' name='svm'/> <feature policy='disable' name='monitor'/> </cpu> 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 <awilliam> - 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.