Hi,
Rumor has it that on Fri, Apr 15, 2005 at 12:24:17AM +0100 Mark Williamson said:
> > 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".
>
This is actually making the connection the nbd server though right?
> 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.
>
Is iscsiadm used here to instantiate this target and lun or would it be
already scanned in? I was under the impression iscsi gets scanned like any
other scsi host.
> 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.
Thanks for the write-up. I've not used nor looked at how the file
backed vbds work.
I think a script callout something like this would work. Why not just make
it a scsi call out? I don't think there is a need to make it different for
iscsi. scsi will cover all of those types of LUs; iscsi, SAN, local scsi,
sata, etc. Assuming the device is already present some sort of uuid may be
a better choice as a parameter. The target and lun on one machine may also
not be the same as on another.
Maybe something like "scsi_id:WWN"? This could call a generic scsi script that
used the scsi_id tool to find a where the matching device is current located.
This is 2.6 dom0 specific of course.
Specifying (host channel target and lun) could be sufficient if the scripting
had some sort or remapping ability. Then something with a more global view could
make sure the mapping is setup right. But then it might be simpler to use
specially named files links to point to the right device...
Phil
>
> Cheers,
> Mark
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
Philip R. Auld, Ph.D. Egenera, Inc.
Software Architect 165 Forest St.
(508) 858-2628 Marlboro, MA 01752
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home