Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: 
groundwork for xen support"):
> On Tue, Aug 26, 2008 at 02:33:09PM +0100, Ian Jackson wrote:
> >    -xen-bare         no xend on this system, qemu should create a Xen domain
> >                      without this, Xen machine types use emulated
> >                      Xen functionality
> 
> I'm not sure I understand what you mean here ?  Are you suggesting this
> for the 'Xen hypervisor present, standalone mode - ie no XenD' ?

Yes.

>  If so I think that's not right - for standalone mode we shouldn't
> require any special args for the admin. We should only require
> additional args for cases where management tools like XenD or
> libvirt are invoking QEMU.

The usual case for a Xen installation is that xend is running.  In
that situation, it is wrong for qemu to create a domain directly.
That will interfere with xend's management of the whole system.

So that means that it is not right to detect that we are running under
Xen and if so create a domain by default.  That should only be done if
the person invoking qemu knows that there is no xend and therefore
that creating the domain directly is sensible.

> I'll try to enumerate the scenarios here...
> 
>  On KVM, using Xenner + shell        : No special args
>  On KVM, using Xenner + libvirtd     : -xen-create <domid> 
>  On Xen HV + shell     : No special args
>  On Xen HV + libvirtd  : -xen-create <domid>
>  On Xen HV + XenD      : -xen-attach <domid>

You've missed out entirely software emulation of a Xen environment.
AIUI this is pretty mucbh Xenner without KVM.

And see my comments above about running under Xen.  The Xen hypervisor
is not a system facility which user processes are expected to make use
of without negotiating with the prevailing Xen management stack.  This
is unlike KVM, where all KVM's callers can be oblivious to each other.

If you run qemu to invoke a Xen domU image it should not disturb any
existing actual Xen installation, and the behaviour and outcome should
not depend on whether the whole lot is running under a real Xen (with
xend et al).  It is fine to use KVM if available because that's just a
performance improvement.

This is because the way to start a Xen domU, as stated in the Xen
documentation etc., is via the Xen management tools.  If a user tries
to do it via qemu then they are either making a mistake, or intending
to run an emulated Xen environment.  (Note that they may be running
qemu on a Xen domU in which case creating a domain isn't even
possible.)

If we make qemu actually create a guest by direct hypercalls, the Xen
management stack will be disrupted ...

> If neither -xen-create or -xen-attach is given, then it will create a
> new domain from scratch & auto-allocate a domid. Passing both the
> -xen-create and -xen-attach args is forbidden / nonsensical.

... so this behaviour should not be the default.

> Ian, did I miss any of the use cases you want addressed  ? I'm leaving
> mini-os out of this now, since as you say, its impossible to have one
> binary deal with it, but I'll assume its similar to -xen-attach <domid>
> use case in its working.

Fairly similar.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel