[rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver?

[neo3 matrix]

Hi all,

I have installed RHEL6 as guest OS on Citrix Xen Server. After installation
of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of traditional
convention like /dev/sda, /dev/sdb on guest OS.

Generally, on physical machines, in /proc/scsi/scsi file, we get a unique
entry for every disk connected to the system. For e.g. string
"scsi02:00:00:01" indicates that this disk is connected to the machine via
Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely
identify each and every disk in scenarios where many times after reboot OR
in SAN boot cases OR in some Disaster Recovery procedures, disk names might
change from say /dev/sda to /dev/sdb after reboot. But, this
Host:Channel:ID:Lun combination remains same for every disk and I can
uniquely identify the disks though their /dev/sd* names have changed.

For my project, on Citrix Xenserver, I need to know the unique disk
location for such Xen guest OS devices by which I can easily identify disks
across the reboots for the above mentioned cases.

So, I have couple of questions on this front. Please help me out or guide
me for the same.

1. As /proc/scsi/scsi don't have such entry for /dev/xvdX type disks, do we
have similar mechanism in Citrix XenServer to identify our guest OS disks
uniquely?

2. This question is rather a continuation of previous one. While searching
answer for above question, I found that for every /dev/xvdX disk, a unique
device entry is present in /sys/block/xvdX/ directory in the format
"vbd-XXX", for example, vbd-768, vbd-832, etc. Here, vbd stands for Virtual
Block Device.

But what is the significant of the numbers 768, 832 ,etc.? How these are
generated? Are they indicating something like Host:Channel:Id:Lun? Can I
trust these numbers to distinctly identify my disks? Are these numbers
differ from one guest OS to other OR depend on Xenserver configuration?

Please suggest me some answer/guideline on this front.


Regards,
Neo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20121019/b680bff3/attachment.htm>