This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

On Tue, Aug 26, 2008 at 02:24:10PM +0100, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] 
> xen: groundwork for xen support"):
> > This particular check is doing two different jobs in one go. I think 
> > they need to be dealt with separately.
> > 
> >  - Check to see if running on Xen or not. This is a similar idea to
> >    to pv_ops where we have one kernel binary, and probe at runtime
> >    to decide whether to run in KVM, Xen, VMWare or bare metal mode.
> I don't think this is correct for the Xen case.  Certainly it is not
> correct for a qemu invoked by the Xen management tools, and it is also
> not correct for a qemu invoked by hand on a system which already has
> xend etc.
> If you're trying to run qemu under Xen but standalone without xend
> then you're going to have to tell qemu that that's what you want.
> Otherwise if you try to run the same qemu under Xen but _with_ xend,
> qemu in dom0 will create a domain bypassing xend and cause all sorts
> of trouble.

Yes, mixing manually created VMs & XenD managed VMs is not a use case
I was thinking we should try to address. The core use case for creating
VMs on the Xen hypervisor, is that you want to avoid the python stack,
and thus you aren't likely to have XenD around anyway. 

|: 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

<Prev in Thread] Current Thread [Next in Thread>