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.
But fair enough, I just got excited ... libvirt is (a), not (b), and I
have to deal with that :-)
Cheers,
Mark.
[1] - By "virtualisation management infrastructure", I mean e.g.
whatever knows what guests exist (active or not) and can start and stop
them.