On Wed, Aug 27, 2008 at 12:37:42PM +0200, Gerd Hoffmann wrote:
> 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?
If you start an Xen guest directly with QEMU, that'll be seen by XenD
and bad things will start to happen. At best, XenD will tear down your
manually created domain if it sees it before you write enough info
into xenstore.
> 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.
In the context of the QEMU driver in libvirt, we don't currently care what
the actual Xen hypervisor domain ID is - we make up our own domain ID
space, and have no need for it to map to hypervisor IDs. Thus, externally
created QEMU instances can use the HV too and won't clash. In fact libvirt
won't even care if the VM is using the HV or not - it is just another QEMU
process - all the xenstore/xen HV interaction is self contained inside
QEMU. 
In the context of the Xen driver in libvirt, we're going via XenD and
don't create VMs manually.
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