On Tue, Jan 16, 2007 at 11:24:52PM +0000, Daniel P. Berrange wrote: > On Tue, Jan 16, 2007 at 05:16:54PM -0500, Aron Griffis wrote: > > Daniel P. Berrange wrote: [Tue Jan 16 2007, 04:54:49PM EST] > > > > > 3. The way I think you re suggesting - a libvirt server on every remote > > > > > host which calls into the regular libvirt internal driver model to > > > > > proxy remote calls. So even if the hypervisor in question provides a > > > > > remote network management API, we will always use the local API and > > > > > do *all* remote networking via the libvirt server > > > > > > > > > > http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-2.png > > > > > > > > ...and this requires each managed host to have libvirt(d). > > > > > > > > This is considered a reasonable requirement? > > > > > > Personally it doesn't worry me too much - by all means though, I'm open to > > > arguments against it too..... > > > > > > The way I currently look at the problem, needing to deploy a small > > > C based management daemon (merely linked to an SSL library for > > > secure comms) isn't very onerous in comparison to the enourmous pile > > > of python code Xen already requires. For non-Xen backends we'll > > > definitely need a daemon of some form, since QEMU / KVM / UML / etc > > > don't have any management daemon at all. For administrators there's > > > a certain benefit to only having to worry about opening up one > > > daemon to the public network regardless of which virt system in use. > > > > What's the gap (if any) between libvirtd and xend capabilities? i.e. > > could libvirtd eventually allow dom0 to omit the python-based xen mgmt > > stack to shrink dom0 to a significantly thinner OS instance? > > By far the most significant thing XenD does for us is the initial guest > creation work. Constructing the page tables, populating xenstore, setting > up the virtual device backends, etc. There's no reason this could not > be replicated in a libvirtd - the real low level bits are isolated in > libxc - but I think it'd be really quite alot of work. Then there's bunch of > other bits like save/restore & migration to dela with. So possible, but > not anywhere on the short-medium development term radar. I agree though > in principle it would be nice to slim down the dom0 management stack, > preferably being able to eliminate the python runtime altogether. The isolation is at the licence level too, libxc is GPL'ed not LGPL'ed and it seems trying to change the licence now would be very hard. By exporting an RPC API the Xend daemon allows to access the low level. Now if libvirt were always to use a daemon linking to libxc then we would be in a similar situation without needing xend for those. Not that I suggest to push for it from a technical point of view but this is another aspect of the relationship between the different pieces of code. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
