On Wed, Jan 17, 2007 at 05:20:17PM +0000, Mark McLoughlin wrote: > 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 BTW this option is evil and I intend to kill it off as soon as possible. We only have it currently because there is no secure way to manage Xen from an unprivileged context. Soon it will be possible to manage Xen as an unprivileged user whether local or remote using virt-manager. > 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. Not entirely sure how I'll integrate it in virt-manager. For dev/testing purposes I just did a lame hack to the initial connect dialog to choose Xen vs QEMU, but I don't want that long term, because really users shouldn't have to make that kind of decision themselves. > 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. The only change to the 'create new guest' wizard thus far is the ability to select CPU architecture (since QEMU allows sparc, mips, x86, ppc etc). > 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 :-) I certainly hope it will be sane :-) Regards, 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 -=|