This bug was initially created as a copy of Bug #1659133 I am copying this bug because: libvirt needs to provide an API for querying deprecation information. Now that we are introducing deprecation information on machine-types and devices on QEMU, we need to provide an API for management software to query this information. This BZ is about the ability to report info on deprecated machine-types to the upper layers.
*** Bug 1659135 has been marked as a duplicate of this bug. ***
Impl propose upstream https://www.redhat.com/archives/libvir-list/2021-January/msg00988.html
v2: https://listman.redhat.com/archives/libvir-list/2021-February/msg00591.html
Merged upstream as: 46783e6307 tools: report messages for 'dominfo' command 970a59d746 qemu: implement virDomainGetMessages API 07308b9789 remote: add RPC support for the virDomainGetMessages API c80911f2de src: define virDomainGetMessages API 17f001c451 qemu: record deprecation messages against the domain 842900dc1e conf: record deprecation messages against the domain c32f172d12 qemu: wire up support for maximum CPU model 9c89cc5d6f qemu: probe for "-cpu max" support 7c1653f63a cpu: wire up support for maximum CPU mode 09cbd460fb conf: add reporting of "maximum" CPU mode in domain caps d153c101d2 conf: define a new "maximum" CPU mode 6a40c01ed0 qemu: taint the VM if it is using a deprecated machine type c212eb6c7f qemu: taint the VM if it is using a deprecated CPU model 30626ed15b qemu: add ability to associate a string message with taint warning 2273065746 conf: introduce new taint flag for deprecated configuration 1e260cc449 qemu: report whether a machine type is deprecated in capabilities 5138a09260 qemu: report whether a CPU model is deprecated in dom capabilities v7.0.0-440-g46783e6307
Test with: libvirt-client-7.3.0-1.module+el8.5.0+11004+f4810536.x86_64 qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d.x86_64 Steps: 1. start vm with deprecated config(e.g. deprecated cpu model), check dominfo 2. execute unexpected operation, e.g. "qemu-monitor-command" and "qemu-agent-command", check dominfo 3. restart libvirtd, check dominfo 4. save vm, check dominfo, restore vm, check dominfo 5. shutdown vm by agent(or inside vm), check dominfo 6. start and destroy vm, check dominfo 7. check deprecated machine type info in "virsh capabilities", no output(same as the info got by "virsh qemu-monitor-command vm '{"execute":"query-machines"}'") 8. check deprecated cpu model info in "virsh domcapabilities", blocked by Bug 1961558 - virsh domcapabilities fails with the error: internal error: unknown feature amd-sev-es Output example when vm is running: # virsh dominfo avocado-vt-vm1 Id: 5 Name: avocado-vt-vm1 UUID: fa26e276-1bb1-47eb-be0e-57e8bb8cf0d9 OS Type: hvm State: running ...... Messages: tainted: custom monitor control commands issued tainted: custom guest agent control commands issued tainted: use of deprecated configuration settings deprecated configuration: CPU model 'Icelake-Client-noTSX' There is one issue during test, message "tainted: custom monitor control commands issued" disappeared after restarting libvirtd, is this work as design?
Taint messages should be preserved if libvirtd restarts. Please file a new bug for it.
Filed a new bug to track the issue mentioned in comment 15: Bug 1965589 - Taint message generated during vm running is not preserved during libvirtd restart
Test with libvirt-7.4.0-1.module+el8.5.0+11218+83343022.x86_64 Check deprecated cpu models by "virsh domcapabilities": [root@fjin-8-5 cloud-user]# virsh domcapabilities|grep depre -a5 <model usable='yes'>Nehalem</model> <model usable='yes'>IvyBridge-IBRS</model> <model usable='yes'>IvyBridge</model> <model usable='no'>Icelake-Server-noTSX</model> <model usable='no'>Icelake-Server</model> <model usable='no' deprecated='yes'>Icelake-Client-noTSX</model> <model usable='no' deprecated='yes'>Icelake-Client</model> <model usable='yes'>Haswell-noTSX-IBRS</model> <model usable='yes'>Haswell-noTSX</model> <model usable='yes'>Haswell-IBRS</model> <model usable='yes'>Haswell</model> <model usable='no'>EPYC-Rome</model>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4684