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

Thu Nov 1 06:30:01 UTC 2012

Thank you Herbert for reply.

We do support recovery of one client on other client by doing dissimilar
disk mapping from one client to other.
For example,  for this, what we do in our product is:-
Case 1:
If I have a guest OS (say GA) on a Xenserver  (sayXA). I have 2 disks on GA
having host:Id:channel:lun string in /proc/scsi/scsi is as :-
2:0:0:0 and 4.0.1.0 where disks say /dev/sda belongs to 2:0:0:0 and
/dev/sdb belongs to 4:0:1:0.
Now, if i have another Xenserver (say XB) with a guest OS on it (say GB),
then according to my project, I can be to restore GA client on GB, where I
can directly map both the disks on GA with disks on GB and do the restore.
Of course, it is possible only if :-
1. GB also have 2 or more disks.
2. the disks in GB* MUST* be having exactly same host:id:chaanel:lun as
that of disks in GA. That means, disks in GB have 2:0:0:0 and 4:0:1:0 disk
locations in its /proc/scsi/scsi.
3. disk size in GB is greater than or equal to disk size in GA.

We already have this mechanism working for  physical as well as virtual
clients having *scsi disks*.
But, for /dev/xvdX type of disks which do not have host:id:channel:lun at
all, I need some similar mechanism so that I could map disk locations
across the clients and restore systems.

I understand that,  there is a  unique string for /dev/xvdX disks i.e.
"vbd-XXX". Though it remains same for multiple disks within a system, it is
different for multiple clients on multiple Xenservers according to their
settings.

So, Can you tell me a way out to map disks on different systems?

Regards,
Neo

On Mon, Oct 29, 2012 at 8:42 PM, Herbert van den Bergh <
herbert.van.den.bergh at oracle.com> wrote:

>
> The hardware mapping is not going to be deterministic between servers.  So
> you need to rely on some unique identifier stored in the contents of the
> virtual disks.  Which one you can use depends on how you backup and restore
> your virtual disks.  Where does your DR restore run?  In domU or in dom0?
> And how exactly do you backup and restore the virtual disks?
>
> Thanks,
> Herbert.
>
>
> On 10/29/12 12:19 AM, neo3 matrix wrote:
>
> Thank you John and Grzegorz  for your quick replies.
> Sorry for late reply (as I was not in town).
>
>  Basically, I am working on a Disaster Recovery software whose disk logic
> is totally dependent on disk mapping .
>
>  Even in my project, I should be able to map a disk from one OS on
> Xenserver to other OS on other Xenserver.
>
>  So, as John suggested,
> >>> "The good news with Xen disks is that they really do have
> deterministic slots.   The virtual disk in slot xvdb will >>> always be
> xvdb (the "vbd-NNN" numbers simply refer to event channels."
> Here, I can't use vbd-XXX names as they differ from one guest OS to other
> and one Xenserver to other.
> Also, changing the Xenserver setting in VM definition file is in
> customer's hand which I cannot control.
>
>  I can't try UUID as well for disk mapping  because the problem is during
> disaster recovery process we used to repartition disks and due to that UUID
> of disk and partitions gets changed.
>
>  So, to map disks from one xenserver to other, I need some mapping
> mechanism like host:channel:id:lun
> OR
> the way "lscsci" command gives output which is similar in other Xenserver
> as well and I can be able to map disks.
>
>  Can you please help me out in the same?
>
>  Thank you for your valuable suggestions.
>
>  Regards,
> Neo
>
>
>
>
> On Fri, Oct 19, 2012 at 1:08 PM, John Haxby <john.haxby at gmail.com> wrote:
>
>>
>>
>>  On 19 October 2012 07:32, neo3 matrix <neo3matrix at gmail.com> wrote:
>>
>>> 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.
>>>
>>>
>>
>> Oooh.   Complicated question.
>>
>> To start with, those SCSI-type disk identifiers are not as deterministic
>> as you might hope.  "Host=2" merely refers to the SCSI controller that was
>> discovered at position number 2.   These days, discovery order counts for
>> nothing: devices are discovered and initialised concurrently, more or less,
>> so while you might get devices discovered in the "right" order almost all
>> the time, you might find that powering on a machine on a particularly cold
>> morning changes the order in which things are discovered.   Even worse, if
>> what used to be /dev/sdb goes AWOL then you're not left with a hole in the
>> sequence, everything from what used to be /dev/sdc onwards gets renamed.
>>
>> The good news with Xen disks is that they really do have deterministic
>> slots.   The virtual disk in slot xvdb will always be xvdb (the "vbd-NNN"
>> numbers simply refer to event channels, they aren't random but they might
>> as well be).  You would need to edit the VM definition in the host to
>> change the virtual disks.
>>
>> Even more good news: you don't need to use the /dev/sdX, /dev/xvdX, etc
>> names at all.
>>
>> If you look in /dev/disk you'll find several directories.  The one you're
>> probably most interested in is /dev/disk/by-uuid: entries in /etc/fstab
>> should be using the UUID= format to identify things that aren't logical
>> volumes (logical volumes are named within their volume group and the
>> physical volumes that make up a volume group aren't tied to specific
>> devices although they do have specific UUIDs).
>>
>> Running "blkid" (as root) is quite useful as well.
>>
>> jch
>>
>> _______________________________________________
>> rhelv6-list mailing list
>> rhelv6-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>>
>
>
>
> _______________________________________________
> rhelv6-list mailing listrhelv6-list at redhat.comhttps://www.redhat.com/mailman/listinfo/rhelv6-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20121101/6c50b9b9/attachment.htm>