WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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 
patchset...

Daniel
-- 
|: 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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