[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 _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
