Daniel P. Berrange wrote:
On Tue, Jul 29, 2008 at 08:32:11AM -0500, Anthony Liguori wrote:
Why wouldn't the Xen backends be added by appropriate -net or -drive
options? For instance, qemu -drive file=foo.img,if=xen -net nic,model=xen
That would work for certain setup tasks, but not all. In Xen's branch
of QEMU, the machine init function has to set various hypervisor
parameters which aren't directly associated with QEMU command line
args, and initialize things like the map-cache for > 4GB guest support.
map-cache is one of those things I don't expect to ever get merged.
In the Xennite work I had further stuff going on there too - more general
initialization of Xenstore parameters - eg stuffing the name & uuid from
QEMU's argv into right place in xenstore.
Ideally, I'd like to see Xen/KVM integration look like this:
1) Xen support is detected in configure (libxc et al) and conditionally
enabled.
2) When running on bare metal, detect whether KVM acceleration is
available, also detect if kqemu acceleration is available
3) When running under Xen, detect that Xen is available, and create a
full virt domain
4) If a user specifies a type=xen device, it should Just Work provided
you are in a Xen environment (erroring appropriately)
5) A user can explicitly specify -M xenpv. If running under Xen, this
would create a Xen PV guest. If running on bare metal, Xenner would be
used to present a Xen shim layer. This should work with KVM
acceleration or without KVM acceleration. Bonus points if it works with
kqemu too.
For 1-4, the user experience should not be different at all. This of
course doesn't mean that users would be forced to interact directly with
QEMU or that QEMU cannot be running within a stub domain. It would be
good if these things could be automatically detected though.
Regards,
Anthony Liguori
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home