[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:
> Gerd Hoffmann writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: 
> groundwork for xen support"):
> > So we are scoring at three options for xen now:
> > 
> >   -xen-domid <nr>  specify xen domain id.
> >   -xen-create      ask qemu to create the domain.
> >   -xen-emulate     force xen emulation mode.
> No, the correct set of options are:
>    -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' ? 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.
>    -xen-domid <nr>   has slightly different meanings in the various use cases

Perhaps best not to overload this then - pass domid to the -attach arg
directly, and have a -xen-create <nr> for the scenario where you want
to specify the domid for a newly created VM

> And if you really think you must have the same executable for the xend
> case:
>    -xen-attach       used by xend; qemu is to support a Xen HVM domain
>                      not to be used from the command line

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>

NB. by 'shell'  I mean the admin manually launching QEMU from the shell

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.

In all cases, the actual hypervisor domain ID should be exposed via the
monitor console.

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.

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.