From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXzJQ-0006ov-3I for qemu-devel@nongnu.org; Tue, 26 Aug 2008 10:14:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXzJP-0006oc-GY for qemu-devel@nongnu.org; Tue, 26 Aug 2008 10:14:23 -0400 Received: from [199.232.76.173] (port=40334 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXzJP-0006oV-C4 for qemu-devel@nongnu.org; Tue, 26 Aug 2008 10:14:23 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55027) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXzJO-000569-PI for qemu-devel@nongnu.org; Tue, 26 Aug 2008 10:14:23 -0400 Date: Tue, 26 Aug 2008 15:14:01 +0100 From: "Daniel P. Berrange" Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support Message-ID: <20080826141400.GE19615@redhat.com> References: <1219336054-15919-1-git-send-email-kraxel@redhat.com> <18611.56211.660082.627144@mariner.uk.xensource.com> <20080826125742.GB19615@redhat.com> <48B40306.2080104@redhat.com> <20080826132309.GC19615@redhat.com> <18612.1557.455011.713070@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18612.1557.455011.713070@mariner.uk.xensource.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: xen-devel@lists.xensource.com, Gerd Hoffmann , qemu-devel@nongnu.org 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 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 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 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 On Xen HV + shell : No special args On Xen HV + libvirtd : -xen-create On Xen HV + XenD : -xen-attach 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 use case in its working. 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 :|