Hi everyone! First of all sorry for such wide distribution, but apparently that's the best way to make sure we cooperate nicely. So please be considerate as this is a cross-post between huge amount of mailing lists. After some discussions with developers from different projects that work with libvirt one cannot but notice some common patterns and workarounds. So I set off to see how can we make all our lives better and our coding more effective (and maybe more fun as well). If all goes well we will create a project that will accommodate most of the defaulting, policies, workarounds and other common algorithms around libvirt domain definitions. And since early design gets you half way, I would like to know your feedback on several key points as well as on the general idea. Also correct me brutally in case I'm wrong. In order to not get confused in the following descriptions, I will refer to this project idea using the name `virtuned`, but there is really no name for it yet (although an abbreviation for "Virtualization Abstraction Definition and Hypervisor Delegation" would suit well, IMHO). Here are some common problems and use cases that virtuned could solve (or help with). Don't take it as something that's impossible to solve on your own, but rather something that could be de-duplicated from multiple projects or "done right" instead of various hack-ish solutions. 1) Default devices/values Libvirt itself must default to whatever values there were before any particular element was introduced due to the fact that it strives to keep the guest ABI stable. That means, for example, that it can't just add -vmcoreinfo option (for KASLR support) or magically add the pvpanic device to all QEMU machines, even though it would be useful, as that would change the guest ABI. For default values this is even more obvious. Let's say someone figures out some "pretty good" default values for various HyperV enlightenment feature tunables. Libvirt can't magically change them, but each one of the projects building on top of it doesn't want to keep that list updated and take care of setting them in every new XML. Some projects don't even expose those to the end user as a knob, while others might. One more thing could be automatically figuring out best values based on libosinfo-provided data. 2) Policies Lot of the time there are parts of the domain definition that need to be added, but nobody really cares about them. Sometimes it's enough to have few templates, another time you might want to have a policy per-scenario and want to combine them in various ways. For example with the data provided by point 1). For example if you want PCI-Express, you need the q35 machine type, but you don't really want to care about the machine type. Or you want to use SPICE, but you don't want to care about adding QXL. What if some of these policies could be specified once (using some DSL for example), and used by virtuned to merge them in a unified and predictable way? 3) Abstracting the XML This is probably just usable for stateless apps, but it might happen that some apps don't really want to care about the XML at all. They just want an abstract view of the domain, possibly add/remove a device and that's it. We could do that as well. I can't really tell how much of a demand there is for it, though. 4) Identifying devices properly In contrast to the previous point, stateful apps might have a problem identifying devices after hotplug. For example, let's say you don't care about the addresses and leave that up to libvirt. You hotplug a device into the domain and dump the new XML of it. Depending on what type of device it was, you might need to identify it based on different values. It could be <target dev=''/> for disks, <mac address=''/> for interfaces etc. For some devices it might not even be possible and you need to remember the addresses of all the previous devices and then parse them just to identify that one device and then throw them away. With new enough libvirt you could use the user aliases for that, but turns out it's not that easy to use them properly anyway. Also the aliases won't help users identify that device inside the guest. <rant> We really should've gone with new attribute for the user alias instead of using an existing one, given how many problems that is causing. </rant> 5) Generating the right XML snippet for device hot-(un)plug This is kind of related to some previous points. When hot-plugging a device and creating an XML snippet for it, you want to keep the defaults from point 1) and policies from 2) in mind. Or something related to the already existing domain which you can describe systematically. And adding something for identification (see previous point). Doing the hot-unplug is easy depending on how much information about that device is saved by your application. The less you save about the device (or show to the user in a GUI, if applicable) the harder it might be to generate an XML that libvirt will accept. Again, some problems with this should be fixed in libvirt, some of them are easy to workaround. But having a common ground that takes care of this should help some projects. Hot-unplug could be implemented just based on the alias. This is something that would fit into libvirt as well. ======================================================================== To mention some pre-existing solutions: - I understand OpenStack has some really sensible and wisely chosen and/or tested default values. - I know KubeVirt has VirtualMachinePresets. That is something closely related to points 1) and 2). Also their abstraction of the XML might be usable for point 3). - There was an effort on creating policy based configuration of libvirt objects called libvirt-designer. This is closely related to points 2) and 3). Unfortunately there was no much going on lately and part of virt-manager repository has currently more features implemented with the same ideas in mind, just not exported for public use. We could utilize some of the above to various extents. Let me know what you think and have a nice day. Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
