If I change "cX" number on VxVM disks do I need to do deport/import?

[Stuart Abramson]

We are moving some disks around between EMC disks. When we do this, the "cX" number changes.

On LVM disk, we need to do a vgexport/vgimport when we do this, because on reboot, the OS can't find the old disks, which are gone.

If we have VxVM disks, of which we have a few servers, do I need to go through the "deport/import" sequence? I have heard that VxVM can find the disks even if the "cX" number changes.

[RAC_1]

Do know about VxVM, but with LVM you can do as follows.

Note down the disks associated with vgs. (If you have already chnaged the Cxs, then you may look at /etc/lvmconf/*.conf files to know what were the old disk names)

Once you change the Cx, then you can do vgexport vgxx
mkdir /dev/vgxx
mknod /dev/vgxx/group c64 0x0c0000
(Use the correct minor number)
vgimport /dev/vgxx /dev/dsk/cxdxtx.
Do it for all disk, for which Cx has changed.

Anil

[Steve Post]

The cX number is the device instance number.
You can have the SAME cX numbers that you had before. To do that you need to read:
doc# KBRC0004879
"How to change instance number of ext_bus and dev files???" for hpux11.x and 10.x.


Ok, you don't want to?
When you run vgexport, use the -s "sharable" option. Hopefully you have this option. When you run
"vgexport -s -m vgmine.map -p /dev/vgmine"
You end up making a map file called "vgmine.map". Look at the file, you will see it has a line on top of the file like: "VGID 2323980395323532c59"

Then when you really export the volume group, you can re-import it with this map file. The VGID line somehow links the volume group to the disks that belong to the volume group regardless of what the disk device has been changed to.

Last March I had a disaster where my EMC disks were fine, but my ignite tape and bootable disks all died. I was able to reinstall hpux from cdrom, but I wanted the devices to be EXACTLY the same. The krc doc worked like a champ. This made life easier for me. Because I have about 90 disks, spread out on 3 servers, with 10 different scsi channels. (90x10=900 device names. ouch).

let me know if you need more info.
steve

[Doug Kratky]

You should do a "vxdg deport" of the disk group before you start moving the disks. After moving the disks, you'll need to do the ioscan and insf, then a "vxdg import". The advantage of VxVM is that it will find the right disks. You won't have to worry about specifying disks, a mapfile w/ a vgid, etc.

[Stuart Abramson]

Let me rephrase my question for clarity:

Do I NEED to go through the "deport/import" sequence (which I know how to do), when I move VxVM physical volumes from one EMC FA port to another, which changes the "cX" numbers?

Am I REQUIRED to "deport/import"?

I have heard that VxVM can find the Data Groups even if the "cX" numbers have changed.

If VxVM finds the Data Groups on the new "cX" numbers, then, of course, there is no reason to use "ioinit" to reconstruct the old "cX" numbers.

vgexport/vgimport (which I know how to do) aren't VxVM commands and aren't appropriate in this case.

[Doug Kratky]

Yes, you have to go through the deport/import process. You can't move the disks while the disk group is up. VxVM won't figure out the changes on the fly.

[Spike Burkhardt]

Stuart,

I have never dynamically changed where disks are so I can't say what the procedure would be given that parameter. On Solaris I have moved VxVM disks where the cX has changed. As background, Veritas writes DM name, DG info... to the private region on the disk. As long as your not moving the disk to a different disk group you should be ok with this. The procedure for that is:

1. bring the system down
2. move the disk
3. bring the machine back up
4. at this point VxVM will scan all disks the OS sees and read the private region. If it is a VM disk, then it will put the disk in the named DG with the DM name. Essentially it will ignore the fact that the device name is different.
5. if you do a 'vxdisk list' I believe you'll find the disk with the new cX and the old cX will have some kind of error in the far right column.
6. you should be ready to go!

Please let me know if this works or doesn't work!

spike

[Stuart Abramson]

Spike, thanks for your answer. I was hoping that someone in the HP-UX VxVM world could tell me precisely that HP-UX acts the same as Solaris in this regard.

Doug, in the Solaris world you don't need to do the deport/import, because Solaris VxVM is so smart that he scans the headers and recovers the DG without you having to do anything (that's what Spike just said..). I was hoping that HP-UX VxVM would do the same thing. Thanks also for your answer.