We provide OS upgrade from RHEL4.8 to RHEL5.6 for 20 boxes. We completely uninstall Veritas Storage Foundation version 5 MP3 before the upgrade (/opt/VRTS/uninstallsf) and after that we install version 5 MP4-RP1-HF1.
The scenario is:
0\ double backup vx configuration #vxconfigbackup and # vxconfigbackup -l <somewhere>
1\ unroot boot disk
2\ deport all disk groups
3\ uninstall VxSF
4\ upgrade OS
5\ install VxSF
6\ import disk groups
7\ encapsulate boot disk
The steps 0-5 go without problem. When importing disk groups 2 strange things happen:
- EVERYTIME all disks appear with flag "clone". It's solved byt "vxdisk set" command
- very often one particular group cannot be imported because "the disk group has no valid configuration copies". Everytime it is only the disk group which has been often extended by adding new LUNs in the past. We were able to solve this issue by vxconfigrestore procedure, but in one case we lost one disk from the diskgroup (disk invalid) and had to restore from backup.
I suppose the deinstallation/installation proccess should go smoothly with no problem.
Please, if you have any advice or comments to the upgrade process order, let me know
during uninstall procedure, I reckon somewhere in / directory, vx config will be backed up (directory name is in capital letters however don't remember the exact name)
For first issue when all disks are getting flagged as "clone", I understand that vxvm assumes original disks already exists & all disks after installation are named as clone (UDID or disk ID or DGID getting changed though), I would assume to delete/move the original config backup under / & retry the procedure..
For second issue, did u ensure that vxconfigbackupd was running while disks were added, reason I am asking because vxconfigbackupd is suppose to backup DG config everytime the config changes, in the case when u lost one of the disk, did vx config backup shown the newly added disk ?
We ran into this problem and found the following process works for us:
1) Flush 'vxdg flush xx', unmount volumes and deport disk group from system
2) Unmap luns from system
3) Remove old vxvm entries
vxddladm stop eventsource
mv /etc/vx/disk.info /etc/vx/disk.info.old
mv /etc/vx/array.info /etc/vx/array.info.old
rm /dev/vx/dmp/*;rm /dev/vx/rdmp/*
4) Reboot system (reconfiguration reboot if possible to clear out any stale links to the unmapped luns)
5) Apply software patches, reboot
6) When system is in normal multiuser mode, remap luns and import dgs
Its tedious unmapping the luns yes but considering the possibility of data corruption it out weighs the risks