Updated running system from F26 to F28 # rpm -qf /usr/sbin/libvirtd libvirt-daemon-4.1.0-2.fc28.x86_64 # virsh start VARLINKTEST error: Failed to start domain VARLINKTEST error: operation failed: guest CPU doesn't match specification: missing features: monitor,rdtscp,svm # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 16 Model: 5 Model name: AMD Athlon(tm) II X4 605e Processor Stepping: 3 CPU MHz: 800.000 CPU max MHz: 2300,0000 CPU min MHz: 800,0000 BogoMIPS: 4590.23 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K NUMA node0 CPU(s): 0-3 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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save # virsh capabilities |fgrep 'feature name' <feature name='vme'/> <feature name='ht'/> <feature name='mmxext'/> <feature name='fxsr_opt'/> <feature name='pdpe1gb'/> <feature name='3dnowext'/> <feature name='3dnow'/> <feature name='cmp_legacy'/> <feature name='extapic'/> <feature name='cr8legacy'/> <feature name='3dnowprefetch'/> <feature name='osvw'/> <feature name='ibs'/> <feature name='skinit'/> <feature name='wdt'/> <feature name='invtsc'/> # virsh domcapabilities |fgrep 'feature policy' <feature policy='require' name='vme'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='tsc-deadline'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='arat'/> <feature policy='require' name='mmxext'/> <feature policy='require' name='fxsr_opt'/> <feature policy='require' name='pdpe1gb'/> <feature policy='require' name='3dnowext'/> <feature policy='require' name='3dnow'/> <feature policy='require' name='cmp_legacy'/> <feature policy='require' name='cr8legacy'/> <feature policy='require' name='3dnowprefetch'/> <feature policy='require' name='osvw'/> <feature policy='require' name='invtsc'/> <feature policy='disable' name='monitor'/> # virsh dumpxml VARLINKTEST […] <cpu mode='host-model' check='partial'> <model fallback='allow'/> </cpu> […]
(In reply to Harald Hoyer from comment #0) > Updated running system from F26 to F28 Can you confirm that you rebooted the host after doing this live update ? > # virsh capabilities |fgrep 'feature name' > # virsh domcapabilities |fgrep 'feature policy' Can you attach the full output of those two virsh commands without filtering, as only showing the feature names has lost key data - the base model name in particular.
(In reply to Daniel Berrange from comment #1) > (In reply to Harald Hoyer from comment #0) > > Updated running system from F26 to F28 > > Can you confirm that you rebooted the host after doing this live update ? > yes # uname -r 4.16.13-300.fc28.x86_64
Created attachment 1447882 [details] virsh domcapabilities
Created attachment 1447884 [details] virsh capabilities
This is very strange - guest XML has "host-model" which should obviously be compatible with the host by design. Both the general capabilities and dom capabilities report Opteron_G3 as the host model, and this includes the monitor, svm and rdtscp features. dom capabilities does note, however, that monitor must be disabled, but libvirt should do that automatically AFAIK.
and now? anything to try?
This is very strange because this error is supposed to only be reported when check='full' attribute is set in the <cpu> element in domain XML, which is clearly not your case. Could you attach the QEMU log from /var/log/libvirt/qemu/VARLINKTEST.log? Was that domain managed-saved before upgrading Fedora? In other words, what is the output of "virsh dominfo VARLINKTEST"? If it says "Managed save: yes", could you also attach the output of "virsh managedsave-dumpxml VARLINKTEST"?
# cat /var/log/libvirt/qemu/VARLINKTEST.log 2018-06-06 07:38:53.204+0000: starting up libvirt version: 4.1.0, package: 2.fc28 (Fedora Project, 2018-03-21-10:50:33, buildvm-19.phx2.fedoraproject.org), qemu version: 2.11.1(qemu-2.11.1-2.fc28), hostname: hoyer.xyz LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name guest=VARLINKTEST,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-VARLINKTEST/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Opteron_G3,vme=on,x2apic=on,hypervisor=on -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 0ba13309-5624-4c82-930e-0e4e1624aad5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-VARLINKTEST/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/varlink.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2a:73:c7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-VARLINKTEST/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on 2018-06-06T07:38:53.391425Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) 2018-06-06 07:38:53.524+0000: shutting down, reason=failed 2018-06-06T07:38:53.527894Z qemu-system-x86_64: terminating on signal 15 from pid 6512 (<unknown process>) # virsh dominfo VARLINKTEST Id: - Name: VARLINKTEST UUID: 0ba13309-5624-4c82-930e-0e4e1624aad5 OS Type: hvm State: shut off CPU(s): 1 Max memory: 1048576 KiB Used memory: 1048576 KiB Persistent: yes Autostart: enable Managed save: yes Security model: selinux Security DOI: 0 # virsh managedsave-dumpxml VARLINKTEST <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>Opteron_G3</model> <feature policy='require' name='vme'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='hypervisor'/> </cpu>
# virsh managedsave-remove VARLINKTEST fixed the issue! :) Thanks!
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Sounds like the issue was fixed/worked around, so closing