Re: [libvirt PATCH 00/16] expose tainting and deprecations in public API

On a Friday in 2021, Daniel P. Berrangé wrote: > Libvirt has a notion of "tainting" which we use to mark a guest which > has some undesirable configuration or behaviour from libvirt's POV. > This ends up in the libvirtd logs and in the per-VM log file, but is > not exposed to management applications directly. > > QMP has the ability to report whether a CPU or machine type is > deprecated. > > QEMU itself prints warnings to stderr which end up in the per VM log: > > 2021-01-22T12:22:53.566239Z qemu-system-x86_64: Machine type 'pc-1.3' is depr= > ecated: use a newer machine type instead > 2021-01-22T12:22:53.566613Z qemu-system-x86_64: warning: CPU model Icelake-Cl= > ient-x86_64-cpu is deprecated -- use Icelake-Server instead > > We can use the deprecation info from QMP to add tainting to the > domain too. This will appear in the pre-VM log file again: > > 2021-01-22 12:22:53.492+0000: Domain id=3D2 is tainted: deprecated-configurat= > ion (machine type 'pc-1.3') > 2021-01-22 12:22:53.492+0000: Domain id=3D2 is tainted: deprecated-configurat= > ion (CPU model 'Icelake-Client') > > and more usefully in the libvirtd log > > 2021-01-22 13:18:09.619+0000: 3299849: warning : > qemuDomainObjTaintMsg:6208 : > Domain id=3D3 name=3D'demo' uuid=3Deadf8ef0-bf14-4c5f-9708-4a19bacf9e81 > is tainted: deprecated-configuration (machine type 'pc-1.3') > > 2021-01-22 13:18:09.619+0000: 3299849: warning : > qemuDomainObjTaintMsg:6208 : > Domain id=3D3 name=3D'demo' uuid=3Deadf8ef0-bf14-4c5f-9708-4a19bacf9e81 > is tainted: deprecated-configuration (CPU model 'Icelake-Client') > > This series goes further and also exposes the deprecation info in the > capabilities (machine types) or domain capabilities (CPU) XML. This > lets mgmt apps avoid using the feature upfront if desired. > > Finally both deprecation messages and tainting flags are exposed in > new public APIs, and wired into virsh > > $ virsh dominfo demo > Id: 3 > Name: demo > UUID: eadf8ef0-bf14-4c5f-9708-4a19bacf9e81 > OS Type: hvm > State: running > CPU(s): 2 > CPU time: 1.3s > Max memory: 1536000 KiB > Used memory: 1536000 KiB > Persistent: yes > Autostart: disable > Managed save: no > Security model: selinux > Security DOI: 0 > Security label: unconfined_u:unconfined_r:svirt_t:s0:c578,c807 (permissive) > Tainting: custom-monitor > deprecated-config > Deprecations: CPU model 'Icelake-Client' > machine type 'pc-1.3' > > The deprecations API is simple, just returning a list of free form > opaque strings, which are eeffectively warning messages. > > I'm not entirely convinced by tainting API though. I didn't especially > want to expose the virDomainTaintFlags enum in the public API since it > feels like the enum flags are (almost) all QEMU driver specific. I thus > took the approach of having an API return opaque strings which are > declared to be hypervisor specific. > > I'm worried though that mgmt apps will none the less simply match on > the strings to detect things, at which point we might as well just use > an enum after all. > Depending on the app, there might be no need to even call GetTainting in the first place - the app already has the power not to use any of the tainted features, with the exception of the newly-added deprecated-config, which can happen after migration to a newer QEMU. So they can just query for deprecations directly.

Also, with the deprecations being an opaque string, can the apps take any different action than just passing them to the user? It seems to me the APIs are better for humans and the XML in capabilities is better for apps, but I've never really written one.

Reviewed-by: Ján Tomko <jtomko(a)redhat.com&gt;