cross-posting to the right list, by mistake a wrong ovirt list was used originally
> Begin forwarded message: > > From: Martin Kletzander <[email protected]> > Subject: [kubevirt-dev] Project for profiles and defaults for libvirt domains > Date: 20 March 2018 at 15:20:31 CET > To: [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected] > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "kubevirt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23007%40wheatley. > For more options, visit https://groups.google.com/d/optout.
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
