Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for 
booting PV domains from NetBSD using raw files as disks"):
> I think you've explained the scheme you have in mind for deprecating
> hotplug scripts before but could you remind me (and for the lists
> benefit)? Is it simply a case of shelling out to the vbd's configured
> "script=" at the right points on attach and detach?

Yes.

The other elements of the block hotplug scripts don't do anything any
more on Linux I think, and currently libxl does not cope with script=
being set, so from a Linux pov this is a new feature for libxl.

> Would we then need special handling to turn "file:<X>" into
> "phy:<X>,script=block-loop"?

I think this should be done behind the scenes.  The backend-specific
code in libxl should call some kind of "invoke this script" function
which would also be used for explicit "script=".

On NetBSD, how do "more exciting" script= things work ?  Eg, iscsi or
nbd.  On Linux the idea is that the hotplug script sets up your nbd
which causes a real block device to appear, and that block device is
used by blkback.

> I seem to remember something about setting up a faked out backend area
> for each backend and running the scripts against that instead of the
> real one.

We would need to do that to support (eg) pygrub over nbd.

> There was a subtle difference between NetBSD's and Linux's handling of
> these with xend. On Linux xend used to setup and manage the loopback
> device and create a simple phy backend referencing it. On NetBSD xend
> just sets up a file or phy backend as appropriate and the scripts which
> run out of xenbackendd take care of setting up the loopback as necessary
> and filing in the real device in xenstore. On teardown the loopback
> device needs to be cleaned up (and this is what currently fails).

I'm not a fan of these approaches with a separate daemon.  We should
avoid that if we can as it produces a lot of complication.

Ian.

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