Re: [libvirt] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

On 22 Mar 2018, at 10:37, Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: On Thu, Mar 22, 2018 at 09:40:40AM +0100, Pavel Hrdina wrote: > On Tue, Mar 20, 2018 at 03:10:12PM +0000, Daniel P. Berrangé wrote: >>> - I understand OpenStack has some really sensible and wisely chosen >>> and/or tested default values. >> >> In terms of default devices and OS specific choices, OpenStack's >> decisions have been largely inspired by previous work in oVirt >> and / or virt-manager. So there's obviously overlap in the >> conceptual area, but there's also plenty that is very specific >> to OpenStack - untangling the two extract the common bits from >> the app specific bits is hard. > > This would be handled by the application specific policies. The > virtuned will have some reasonable defaults that are known to work in > most cases and suits the majority of users, but it's clear that > sometimes you need some specific defaults and you would provide them > via the application policy. > > For example, to create a XML for windows guest the virtuned would not > probably select virtio devices because there are no drivers for them > in the standard windows installation, however, some management > application may have customized preinstalled disk images or customized > ISO images or it may be able to provide the drivers any other way, so > they would specify in the application policy that for windows guest > virtuned should use virtio as a default device model. As soon as we talk about configuring hardware specific to a guest OS, then that is in scope of existing libosinfo project, not something we should create a new project for. > This is probably the hardest part of creating higher level API on top > of libvirt, not every project may be willing to rewrite their existing > code. On the other hand, I know that for example Cockpit would benefit > from the virtuned providing this functionality via REST API. > > It's a chicken and egg problem, but if we can gather input from all the > existing projects that have their own implementation and figure out how > to make virtuned usable for all of them they might consider to start > using it. I don't doubt that Cockpit would like like, but based on previous efforts we've made I'm sceptical that anything beyond Cockpit would use any new API.

Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- 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(a)googlegroups.com. To post to this group, send email to kubevirt-dev(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/20180322093722.GB3583%40re.... For more options, visit https://groups.google.com/d/optout.