Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> I think the key issue is that in domain configs, you want to specify the
> source of the vbd in some high-level name and have the control tools do
> the necessary to map it to a local device and then export it. This
> already happens with file: disk paths. We just need something similar
> for iscsi.

To clarify for anyone who hasn't looked into this code, funky (anything that 
is not "phy:") block devices are handled by Xend calling external programs 
(e.g. scripts) with a particular parameter format.  If you specify a VBD 
source device as "file:/my/file" then the following happens (roughly):

Xend looks in its config for an item called "block-file".  In the default 
config (tools/examples/xend-config.sxp) the value of this item is also 
"block-file", which is the name of the script in /etc/xen/scripts.  It then 
calls this script like this:

/etc/xen/scripts/block-file bind /my/file

The script is required to bind /my/file to a loop device, the name of which it 
outputs (e.g. "/dev/loop0") to stdout.  When the domain is destroyed, Xend 
will call:

/etc/xen/scripts/block-file unbind /dev/loop0

Likewise specifying a block device "enbd:servername:ctlport" causes a call to 
"/etc/xen/scripts/block-enbd bind servername ctlport" and a subsequent 
"/etc/xen/scripts/block-enbd unbind /dev/enbd_node".

For iSCSI you'd define a syntax like "iscsi:target:lun", write a script to run 
iscsiadm (if you're using OpeniSCSI) and stick it in the config.  You could 
probably do a similar thing to deal with your SAN devices.

Thoughts anyone?  It'd be very desirable to have more block scripts in the 
distribution.  If anyone comes up with some, I don't think there'd be any 
problem with them going into the -testing tree.

Cheers,
Mark

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