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] [PATCH 2 of 2] libxl: add support for booting PV domains

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