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] Guest boot loader support [1/2]

> > You could work round this currently using the block config scripts.  I.e.
> > similar to the file: syntax now, you could easily hack up nbd:, iscsi:,
> > etc. Then network block devices can be connected up at create / migrate /
> > restore time, without relying on a particular device node.
>
> Thanks. I'm not really looking for a work around though :) I think
> this is an issue that we should look at in more depth.

Well for network storage that need configuration I'd recommend this as the way 
to go, anyway.  For local block devices, I guess things are a bit less 
clearcut but I think this should be workable too.

> My concern is for SAN attached devices primarily.  These will
> show up as scsi devices with /dev/sdXX names (barring custom
> udev configs).

OK. (as a side note, you could presumably set up udev to name the nodes 
consistently?)

> BTW, how would you do this with iSCSI? iSCSI target LUNs show
> up as scsi devices and get block device names. It'll have the same
> issues as FC SAN.

Is there no way of configuring which node an iSCSI lun gets bound to?  How 
would you (manually) figure out which it is bound to in order to configure 
the domain?  Could you not script that procedure?

If you can script the procedure for (maybe connecting to a server) and then 
figuring out what node the device is connected to, Xend will call your script 
and sort things out automatically.  It's the most straightforward way to do 
this in the 2.x releases, although things might be different in 3.0 depending 
on how much of the toolchain is rewritten.

> > This can be done by writing a shell script to bind the device to a node
> > and adding a config parameter to Xend.
> >
> > I'd imagine we can rely on actual physical device numbers generally
> > staying the same but this could be fixed by a similar mechanism.
>
> What is a physical device number in this context? The name it
> ends up with is often detection order dependent. /dev/sdb has little
> relation to physical device numbers. Also, with the better support
> for hotplug in 2.6 devices can come and go.

Oops, I really meant node rather than number.  

Cheers,
Mark

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