Re: [Xen-devel] [PATCH] Guest boot loader support [1/2]

[Kip Macy <kip.macy@xxxxxxxxx>]

> > 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.
> 

I don't think this is necessarily a "workaround". On filers (and
presumably everyone else's boxes) iSCSI and FCP LUNs have full path
names. The device number is purely a function of the local machine.
Adding some logic to xend so that it thinks in terms of LUNs instead
of device nodes would be highly useful to some of us.

> My concern is for SAN attached devices primarily.  These will
> show up as scsi devices with /dev/sdXX names (barring custom
> udev configs).
> 
> I suppose though that if xen doesn't care about the actual names. Then
> making a link in /dev/ could work. Maybe this is not really an issue after
> all.  e.g. /dev/my_domU_1_disk -> /dev/sdb. Then as long as something
> on the other end can tell where the disk showed up it can make the
> appropriate link -- /dev/my_domU_1_disk -> /dev/sdq.

I have a script that takes as an argument the number of LUNs, the size
of the LUNs, and the name of the VM. These LUNs are all mapped in a
probe and creation dependent order. I have a script that iterates
through all the scsi generic devices (passthrough), sends them an
inquiry - if they're LUNs it sends the device a vendor specific mode
page to get the full pathname. The pathname contains the VM the LUN
belongs to allowing the script to create a device node corresponding
to the sd<n> device in /dev/vm/<vmname>. I've added the following
snippet for mapping the LUNs in at VM creation time:

globstr = "/dev/vm/%s/*"%name

disknamelist = glob.glob(globstr)
count = 1
for diskname in disknamelist:
    disk.append('phy:%s,loop%s,w'%(diskname,count))
    count += 1


I'm not entirely thrilled with SAN management in this model. If I
delete LUNs on the server all the mappings get shifted down due to the
1-dimensional nature of the device node namespace.

> 
> 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.

Yep. There are some open issues here. major / minor numbers that are a
function of probe order are clumsy at best.


              -Kip

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