On Wed, Jan 17, 2007 at 05:35:37PM +0000, Mark McLoughlin wrote: > On Tue, 2007-01-16 at 19:09 +0000, Daniel P. Berrange wrote: > > > > - Probably the only serious problem with that is that libvirt > > > currently will manage Xen guests not created using libvirt. Does it > > > make sense to do that? Will we allow the same with non-Xen? > > > > In the ideal world I'd ignore anything not managed by libvirt, but > > in reality I don't think that's practical. We need to be able to > > interoperate as cleanly as possible with other tools, either provided > > by the HV itself (eg xm) or by other 3rd party vendors. > > Personally, I'd just be a hard-ass about it :-) > > > While my prototype QEMU backend ignores VMs not created by libvirt, > > work going on upstream will make it practical to manage them too. > > I like the way the QEMU backend works right now ... > > I guess one way of looking at it is to ask whether libvirt is: > > a) A common API for accessing various virtualisation management > infrastructures[1] > > or > > b) A common virtualisation management infrastructure > > The Xen support suggests (a), the QEMU support suggests (b). But it's > pretty clear the consensus is that libvirt should avoid being (b) where > it can. > > (a), compared to (b), makes me rather queasy because you have to not > only map from libvirt's model to each hypervisor's model, you also have > to map each hypervisor's model back to libvirt's model. Which, I guess, > suggests that libvirt's model needs to be a superset of all hypervisors' > models, rather than a subset. Turning libvirt into a superset of all HVs is a rather scary concept because it might entail the API getting absolutely enourmous. Not only that, but you'd loose some of the isolation that libvirt gives you from the backend. ie if we added a bunch of APIs that only make sense for Xen, then it becomes much harder to get apps working with the non-Xen backends. So we have actually been trying to keep libvirt closer to a subset, rather than a superset. We are applying some flexibility to that rule though - we're fine adding new APIs that only work on Xen for now - provided they're at least conceptually relevant for other hypervisors. As an example, we have an setMemory API to change a guests memory on the fly, even though Xen is the only HV which currently lets you that. Its reasonable to assume that others will support that in the future possibly through memory hotplug. When doing this we're also making sure we don't expose Xen specific formats - eg for the block device hotplug add / remove, we don't use the Xen 'block device ID number' to add / remove devices, we use the generic device description XML blob. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|