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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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