Bug 1462711 - cannot start VMs after upgrade from Fedora 25 to 26 Beta
Summary: cannot start VMs after upgrade from Fedora 25 to 26 Beta
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-boxes
Version: 26
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-19 11:42 UTC by Mark Chandler
Modified: 2017-07-11 22:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-11 22:43:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mark Chandler 2017-06-19 11:42:27 UTC
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.

Comment 1 Mark Chandler 2017-06-23 14:59:34 UTC
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

Comment 2 Mark Chandler 2017-06-23 15:06:47 UTC
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 13:02:39 UTC
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

Comment 4 Mark Chandler 2017-07-11 22:43:00 UTC
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.


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