cancel
Showing results for 
Search instead for 
Did you mean: 

recovering vx config after migrating storage on HW level

bazi
Level 3

Hi Folks,

We plan to migrate from EMC storage to HDS. The storage is used by RHEL servers with SF 4.1.

Let's say we have 10 EMC LUNs set up in one disk group and volumes spanning multiple disks. We will replicate data of 4 EMC disks on the fabric level to 4 new HDS LUNs. Then unzone the 4 EMC LUNs and zone 4 HDS disks. How to recover from such state? vxreattach will not work since the devices will have the same data (sync'ed block by block from former disks) but with different names in Veritas. I was thinking of using the procedure from troubleshooting  "Recovering an Unstartable Volume with a Disabled Plex in the RECOVER State":

 1. Place the desired plex in the CLEAN state using the following command:

 # vxmend [-g diskgroup] fix clean plex

For example, to place the plex vol01-02 in the CLEAN state:

# vxmend -g mydg fix clean vol01-02

 2. To recover the other plexes in a volume from the CLEAN plex, the volume must be disabled, and the other plexes must be STALE. If necessary, make any other CLEAN or ACTIVE plexes STALE by running the following command on each of these plexes in turn:

 # vxmend [-g diskgroup] fix stale plex

 3. To enable the CLEAN plex and to recover the STALE plexes from it, use the following command:

 # vxvol [-g diskgroup] start volume

For example, to recover volume vol01:

# vxvol -g mydg start vol01

I am wondering if this actually allows Veritas to notice that the data that is missing can be found on different disks.

Any thoughts? Someone maybe went thru similar change? Any suggestions will be much appreciated.

Thanks,

Wojtek

1 ACCEPTED SOLUTION

Accepted Solutions

Gaurav_S
Moderator
Moderator
   VIP    Certified

I would suggest a simple way to this... Zone up the Luns from HDS array & initialize the new disks in veritas... add the new disks into the same diskgroup & mirror the volumes using HDS assigned Luns...

Here would be steps looks like:

-- label the new HDS disks in solaris using format

# vxdisksetup -i <HDS_disk>

# vxdg -g <diskgroup> adddisk HDS01=<HDS_disk>   (you can use any meaningful name for HDS01)

# vxassist -g <diskgroup> mirror <volume> <HDS_disk1> < HDS_disk2>

 

Once mirroring is complete, remove out EMC luns...

# vxtask list  (check sync status)

# vxplex -g <diskgroup> dis <plex_from_EMCdisk>   (detach EMC luns from volume)

# vxedit -g <diskgroup> -rf rm <EMc-plex>

 

 

In the procedure you have mentioned, I am highly doubtful about the recovery since disknames are different.... I don't think volume manager will be able to detact the data.  You will need to do a lot of rebulding to achieve this. The reason why I am saying this is when volume manager is expecting a EMC name of the disk, it will find an HDS name which will produce inconsistencies...

 

Gaurav

View solution in original post

3 REPLIES 3

Gaurav_S
Moderator
Moderator
   VIP    Certified

I would suggest a simple way to this... Zone up the Luns from HDS array & initialize the new disks in veritas... add the new disks into the same diskgroup & mirror the volumes using HDS assigned Luns...

Here would be steps looks like:

-- label the new HDS disks in solaris using format

# vxdisksetup -i <HDS_disk>

# vxdg -g <diskgroup> adddisk HDS01=<HDS_disk>   (you can use any meaningful name for HDS01)

# vxassist -g <diskgroup> mirror <volume> <HDS_disk1> < HDS_disk2>

 

Once mirroring is complete, remove out EMC luns...

# vxtask list  (check sync status)

# vxplex -g <diskgroup> dis <plex_from_EMCdisk>   (detach EMC luns from volume)

# vxedit -g <diskgroup> -rf rm <EMc-plex>

 

 

In the procedure you have mentioned, I am highly doubtful about the recovery since disknames are different.... I don't think volume manager will be able to detact the data.  You will need to do a lot of rebulding to achieve this. The reason why I am saying this is when volume manager is expecting a EMC name of the disk, it will find an HDS name which will produce inconsistencies...

 

Gaurav

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

I agree with Gaurav's method, I prefer to be in control of the migration. Having said that I dont believe VxVM will really care about the disk names, it cares about the configuration that is contained in the private region, which will be the same as before since the disk will be an exact copy. We did almost similar exercise the other day from Symetrix to VMax and there were no issues.

 

But i still prefer the method listed by Gaurav!!

Marianne
Level 6
Partner    VIP    Accredited Certified

Totally agree with advice so far. Have a look at this TN for confirmation:

http://www.symantec.com/business/support/index?page=content&id=TECH66011

how to migrate data one storage array another storage array