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.