> On 22 Mar 2018, at 10:37, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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. We have an opportunity to make kubevirt right, too. Sure, the project is halfway through with own presets and custom code (just repeating oVirt and Openstack), but it’s not too late to change things there, and a remote API fits well > > 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@xxxxxxxxxxxxxxxx. > To post to this group, send email to kubevirt-dev@xxxxxxxxxxxxxxxx. > To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/20180322093722.GB3583%40redhat.com. > For more options, visit https://groups.google.com/d/optout. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
