Re: [Xen-devel] Hotplugged devices in Xen 4.5 and domain reboot

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Dec 01, 2015 at 04:58:55PM +0200, Iurii Mykhalskyi wrote:
> Our real usb mass-storage device are located at driver domain (DomD). So we
> setup second block-device backend there.
> 
> To hotplug usb mass-storage from DomD we use follow command:
> 
> xl block-attach domU_id phy:/bla-bla,xvda10,w,backend="DomD"
> 

What happens if you run this in Dom0? I guess DomD doesn't respond to
the request?

> There was no support of attaching block-device in runtime from domain other
> to Domain-0, so we have made some hacks to allow call block-attach command
> from non-dom0 privileged domain.

So this is a special use case. This is the first time I know people
actually run xl block-attach in driver domain.

> One of patches was - don't update
> /var/lib/xen/userdata-d.$DOMID-$UUID.libxl-json during execution of this
> command (because this log located on dom0 rootfs and we don't have any
> access to it from DomD). So, there is no different in configs before and
> after hotplug.
> 

The state of $DOMID is recorded in libxl-json file. No wonder you lose
all state.

But even if you write those states, they are going to be inside driver
domain.  There is no way at the moment to synthesise the state inside
Dom0 and DomD into one. There is also difficulty in how you can split
the synthesised and dispatch the states to multiple entities again when
rebuilding a domain.

So I think having multiple entities managing state of one single domain
is bad. I think the proper way of making it work is to make hotplug
device from domain other than Dom0 work.

There is a daemon "xl devd" in driver domain. We might be able to teach
it to response to Dom0 toostack request. I'm a bit surprised if it
doesn't do that already. Did you forget to start that daemon?

Roger, Ian and Ian, any thought?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel