Bug 1462711 - cannot start VMs after upgrade from Fedora 25 to 26 Beta
cannot start VMs after upgrade from Fedora 25 to 26 Beta
Product: Fedora
Classification: Fedora
Component: gnome-boxes (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Christophe Fergeau
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-06-19 07:42 EDT by Mark Chandler
Modified: 2017-07-11 18:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-11 18:43:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Chandler 2017-06-19 07:42:27 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.


How reproducible:

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.
Comment 1 Mark Chandler 2017-06-23 10:59:34 EDT
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
Comment 2 Mark Chandler 2017-06-23 11:06:47 EDT
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]
Comment 3 Mark Chandler 2017-06-26 09:02:39 EDT
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'/>

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
Comment 4 Mark Chandler 2017-07-11 18:43:00 EDT
This problem appears to be worked-around in the latest qemu packages. From the changelog of qemu:
* Tue Jul 04 2017 Adam Williamson <awilliam@redhat.com> - 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.

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