[ovirt-devel] Fwd: Project for profiles and defaults for libvirt domains

Thu Mar 22 13:45:11 UTC 2018

cross-posting to the right list, by mistake a wrong ovirt list was used originally

> Begin forwarded message:
> 
> From: Martin Kletzander <mkletzan at redhat.com>
> Subject: [kubevirt-dev] Project for profiles and defaults for libvirt domains
> Date: 20 March 2018 at 15:20:31 CET
> To: libvir-list at redhat.com, openstack-dev at lists.openstack.org, ovirt-devel at redhat.com, kubevirt-dev at googlegroups.com, virt-tools-list at redhat.com, cockpit-devel at lists.fedorahosted.org
> 
> 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 kubevirt-dev+unsubscribe at googlegroups.com.
> To post to this group, send email to kubevirt-dev at googlegroups.com.
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180322/69410189/attachment.html>