<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">cross-posting to the right list, by mistake a wrong ovirt list was used originally<div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Martin Kletzander <<a href="mailto:mkletzan@redhat.com" class="">mkletzan@redhat.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">[kubevirt-dev] Project for profiles and defaults for libvirt domains</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">20 March 2018 at 15:20:31 CET<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><a href="mailto:libvir-list@redhat.com" class="">libvir-list@redhat.com</a>, <a href="mailto:openstack-dev@lists.openstack.org" class="">openstack-dev@lists.openstack.org</a>, <a href="mailto:ovirt-devel@redhat.com" class="">ovirt-devel@redhat.com</a>, <a href="mailto:kubevirt-dev@googlegroups.com" class="">kubevirt-dev@googlegroups.com</a>, <a href="mailto:virt-tools-list@redhat.com" class="">virt-tools-list@redhat.com</a>, <a href="mailto:cockpit-devel@lists.fedorahosted.org" class="">cockpit-devel@lists.fedorahosted.org</a><br class=""></span></div><br class=""><div class=""><div class="">Hi everyone!<br class=""><br class="">First of all sorry for such wide distribution, but apparently that's the<br class="">best way to make sure we cooperate nicely. So please be considerate as<br class="">this is a cross-post between huge amount of mailing lists.<br class=""><br class="">After some discussions with developers from different projects that work<br class="">with libvirt one cannot but notice some common patterns and workarounds.<br class="">So I set off to see how can we make all our lives better and our coding<br class="">more effective (and maybe more fun as well). If all goes well we will<br class="">create a project that will accommodate most of the defaulting, policies,<br class="">workarounds and other common algorithms around libvirt domain<br class="">definitions. And since early design gets you half way, I would like to<br class="">know your feedback on several key points as well as on the general idea.<br class="">Also correct me brutally in case I'm wrong.<br class=""><br class="">In order to not get confused in the following descriptions, I will refer<br class="">to this project idea using the name `virtuned`, but there is really no<br class="">name for it yet (although an abbreviation for "Virtualization<br class="">Abstraction Definition and Hypervisor Delegation" would suit well,<br class="">IMHO).<br class=""><br class="">Here are some common problems and use cases that virtuned could solve<br class="">(or help with). Don't take it as something that's impossible to solve<br class="">on your own, but rather something that could be de-duplicated from<br class="">multiple projects or "done right" instead of various hack-ish solutions.<br class=""><br class="">1) Default devices/values<br class=""><br class="">Libvirt itself must default to whatever values there were before any<br class="">particular element was introduced due to the fact that it strives to<br class="">keep the guest ABI stable. That means, for example, that it can't just<br class="">add -vmcoreinfo option (for KASLR support) or magically add the pvpanic<br class="">device to all QEMU machines, even though it would be useful, as that<br class="">would change the guest ABI.<br class=""><br class="">For default values this is even more obvious. Let's say someone figures<br class="">out some "pretty good" default values for various HyperV enlightenment<br class="">feature tunables. Libvirt can't magically change them, but each one of<br class="">the projects building on top of it doesn't want to keep that list<br class="">updated and take care of setting them in every new XML. Some projects<br class="">don't even expose those to the end user as a knob, while others might.<br class=""><br class="">One more thing could be automatically figuring out best values based on<br class="">libosinfo-provided data.<br class=""><br class="">2) Policies<br class=""><br class="">Lot of the time there are parts of the domain definition that need to be<br class="">added, but nobody really cares about them. Sometimes it's enough to<br class="">have few templates, another time you might want to have a policy<br class="">per-scenario and want to combine them in various ways. For example with<br class="">the data provided by point 1).<br class=""><br class="">For example if you want PCI-Express, you need the q35 machine type, but<br class="">you don't really want to care about the machine type. Or you want to<br class="">use SPICE, but you don't want to care about adding QXL.<br class=""><br class="">What if some of these policies could be specified once (using some DSL<br class="">for example), and used by virtuned to merge them in a unified and<br class="">predictable way?<br class=""><br class="">3) Abstracting the XML<br class=""><br class="">This is probably just usable for stateless apps, but it might happen<br class="">that some apps don't really want to care about the XML at all. They<br class="">just want an abstract view of the domain, possibly add/remove a device<br class="">and that's it. We could do that as well. I can't really tell how much<br class="">of a demand there is for it, though.<br class=""><br class="">4) Identifying devices properly<br class=""><br class="">In contrast to the previous point, stateful apps might have a problem<br class="">identifying devices after hotplug. For example, let's say you don't<br class="">care about the addresses and leave that up to libvirt. You hotplug a<br class="">device into the domain and dump the new XML of it. Depending on what<br class="">type of device it was, you might need to identify it based on different<br class="">values. It could be <target dev=''/> for disks, <mac address=''/> for<br class="">interfaces etc. For some devices it might not even be possible and you<br class="">need to remember the addresses of all the previous devices and then<br class="">parse them just to identify that one device and then throw them away.<br class=""><br class="">With new enough libvirt you could use the user aliases for that, but<br class="">turns out it's not that easy to use them properly anyway. Also the<br class="">aliases won't help users identify that device inside the guest.<br class=""><br class=""><rant><br class="">We really should've gone with new attribute for the user alias instead<br class="">of using an existing one, given how many problems that is causing.<br class=""></rant><br class=""><br class="">5) Generating the right XML snippet for device hot-(un)plug<br class=""><br class="">This is kind of related to some previous points.<br class=""><br class="">When hot-plugging a device and creating an XML snippet for it, you want<br class="">to keep the defaults from point 1) and policies from 2) in mind. Or<br class="">something related to the already existing domain which you can describe<br class="">systematically. And adding something for identification (see previous<br class="">point).<br class=""><br class="">Doing the hot-unplug is easy depending on how much information about<br class="">that device is saved by your application. The less you save about the<br class="">device (or show to the user in a GUI, if applicable) the harder it might<br class="">be to generate an XML that libvirt will accept. Again, some problems<br class="">with this should be fixed in libvirt, some of them are easy to<br class="">workaround. But having a common ground that takes care of this should<br class="">help some projects.<br class=""><br class="">Hot-unplug could be implemented just based on the alias. This is<br class="">something that would fit into libvirt as well.<br class=""><br class="">========================================================================<br class=""><br class="">To mention some pre-existing solutions:<br class=""><br class="">- I understand OpenStack has some really sensible and wisely chosen<br class=""> and/or tested default values.<br class=""><br class="">- I know KubeVirt has VirtualMachinePresets. That is something closely<br class=""> related to points 1) and 2). Also their abstraction of the XML might<br class=""> be usable for point 3).<br class=""><br class="">- There was an effort on creating policy based configuration of libvirt<br class=""> objects called libvirt-designer. This is closely related to points 2)<br class=""> and 3). Unfortunately there was no much going on lately and part of<br class=""> virt-manager repository has currently more features implemented with<br class=""> the same ideas in mind, just not exported for public use.<br class=""><br class="">We could utilize some of the above to various extents.<br class=""><br class="">Let me know what you think and have a nice day.<br class="">Martin<br class=""><br class="">-- <br class="">You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.<br class="">To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:kubevirt-dev+unsubscribe@googlegroups.com" class="">kubevirt-dev+unsubscribe@googlegroups.com</a>.<br class="">To post to this group, send email to <a href="mailto:kubevirt-dev@googlegroups.com" class="">kubevirt-dev@googlegroups.com</a>.<br class="">To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23007%40wheatley" class="">https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23007%40wheatley</a>.<br class="">For more options, visit <a href="https://groups.google.com/d/optout" class="">https://groups.google.com/d/optout</a>.<br class=""></div></div></blockquote></div><br class=""></div></body></html>