On Tue, 2007-01-16 at 19:09 +0000, Daniel P. Berrange wrote:
This reminds me of something I've not explicitly said elsewhere.
While
libvirt API may support multiple difference hypervisors, I'm rather
expecting that the common case usage will be that any single host will
only ever use one particular hypervisor. ie, a host will be providing
Xen, or QEMU+KVM or VMWare or XXX - I think its reasonable to expect
that people won't run both Xen and QEMU+KVM on the same host.
So, one does not neccessarily have to expose the type of guest to the
end user - one could say 'give me the hypervisor connection for this host'
and it would auto-detect what hypervisor is available for that host.
e.g. a user might have the following options:
1) Run virt-manager, enter the root password, manage Xen guests
2) Run virt-manager, choose "run unprivileged", manage QEMU guests
3) Run virt-manager on the command line as root with --qemu
If that *is* the only way we'd expose QEMU support, then libvirt's API
is just fine in this respect.
I had assumed we'd have "run under Xen" and "run under QEMU" in
the
"create new guest" dialog. But that's a stupid question to ask
someone ... one should not need to care what type of VM it is.
So, hurrah! virt-manager will be sane in this respect and only the
not-so-sane app authors will get pissed with libvirt about this :-)
Cheers,
Mark.