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

[Gerd Hoffmann]

Daniel P. Berrange wrote:
>>> 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.

Didn't saw that happen.

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

They should be identical as that would be less confusing to the user.
Having two ID spaces, both called domain ID, is a very bad idea IMHO.

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

Yep.  But even in that case it would be good if libvirt and the guest os
have the same idea about what the domain ID is.

cheers,
  Gerd