[Top][All Lists]

[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 s

From: Daniel P. Berrange
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support
Date: Tue, 26 Aug 2008 16:09:25 +0100
User-agent: Mutt/1.4.1i

On Tue, Aug 26, 2008 at 04:05:01PM +0100, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] 
> xen: groundwork for xen support"):
> > 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 ...

Ok, in that case dis-regard my sugestion of '-no-xen' in the other mail
I just sent. Clearly the negative style args won't work in the xen case,
and we have to go for a positive switch - maybe it really is worth doing
an explicit  '-accelerator none|kvm|xen|kqemu'  right away for this 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]