From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYIR6-0004bT-D6 for qemu-devel@nongnu.org; Wed, 27 Aug 2008 06:39:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYIR5-0004ak-4g for qemu-devel@nongnu.org; Wed, 27 Aug 2008 06:39:35 -0400 Received: from [199.232.76.173] (port=37413 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYIR3-0004Zt-P7 for qemu-devel@nongnu.org; Wed, 27 Aug 2008 06:39:34 -0400 Received: from mx2.redhat.com ([66.187.237.31]:60517) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KYIR1-0003ca-UZ for qemu-devel@nongnu.org; Wed, 27 Aug 2008 06:39:32 -0400 Message-ID: <48B52E76.6080900@redhat.com> Date: Wed, 27 Aug 2008 12:37:42 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support References: <18612.1557.455011.713070@mariner.uk.xensource.com> <20080826141400.GE19615@redhat.com> <48B413D5.3080203@redhat.com> <20080826144056.GG19615@redhat.com> <48B417E1.6090709@redhat.com> <18612.6399.960344.359943@mariner.uk.xensource.com> <48B51599.7040807@redhat.com> <18613.9249.931147.770220@mariner.uk.xensource.com> <20080827095625.GD25099@redhat.com> <18613.9648.179712.343123@mariner.uk.xensource.com> <20080827102324.GE25099@redhat.com> In-Reply-To: <20080827102324.GE25099@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com, Ian Jackson , qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Wed, Aug 27, 2008 at 11:00:16AM +0100, Ian Jackson wrote: >> Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support"): >>> There's no requirement from libvirt itself - just whatever infrastructure >>> libvirt is using. So just a message about XenD/xm would be sufficient. >> Right, but I just wanted to avoid the situation where a naive user >> sees `not for xm/xend systems' and thinks `that's not me because I'm >> using libvirt'. > > They could be right in that thinking though - if using libvirt's QEMU > backend, instead of XenD backend, then it'd be fine to launch VMs > manually. Only the presence of XenD places constraints on usage. What constrains btw? I'd expect with libvirt managing domains via qemu -xen-create and xend managing domains via -xen-attach basically run into the same class of problems if the user starts booting domains manually. The most obvious issue would be is that domain IDs are in use by the user-started domains which the management stack thinks are unused and thus might be allocated for new domains. Likewise, both management stacks will find domains in xenstore they don't know anything about. So I don't see a fundamental difference between libvirt and xend here. cheers, Gerd