[Following move of libvir-list to new location]
On 11/15/23 09:26, Dan Kenigsberg wrote:
Thanks, Michal, for this overture. I think libvirt and its people
have a
lot of knowledge about working-yet-not-recommended configurations that
can be beneficial to higher-level management systems such as KubeVirt.
Indeed. But writing checks for such configurations should be trivial
enough, now that they can be written in Lua. But individual checks are
technicality, those can and will be extended once we know current (API)
design works for KubeVirt.
How do you envisage it to be used by KubeVirt?
Do you think virt-launcher can call it before it is calling
virCreateXML()? If so, would it make sense to bubble up its warnings as
VM.status conditions?
Yes, that's my idea. Once KubeVirt constructed domain XML, it can feed
it to virt-lint tool. From that it'll receive bunch of warnings (or none
if domain XML is okay) which could be then forwarded to the UI for users
to resolve. Or ignore and continue starting up the guest (for instance,
one of currently implemented checks is for enough of free PCIe root
ports for future hotplug - it's up to user to tell if they will ever
want hotplug).
BTW, I think it may be valuable to add a machine-accessible code for
each warning, on top of the English language text.
Good point. That way we can save user's preference on ignoring some
warnings. Or have KubeVirt fix some of the warnings automagically.
Anyway, my knowledge of KubeVirt internals is not intimate enough to
even attempt to integrate this. If anybody from KubeVirt developers is
willing to offer a helping hand, I'd appreciate it.
Michal