Wednesday, June 29, 2005

How to move disks between VxVM diskgroups

How to move disks between VxVM diskgroups

by Tony Griffiths

This is not easily done. However you may be able to move a volume from
one diskgroup to another, beware, some people have messed this up.
Here are the basic steps

Lets say you have two diskgroups sourcedg and targetdg. The sourcedg
has a volume data1 that you want in targetdg. data1 is a simple volume
with a subdisk on disk01, c1t0d0

1. backup the data in volume data1 in case this goes wrong.
2. Save the VM configuration for that particular volume (don't
store the file in the volume)
* vxprint -g sourcedg -hmQq data1 > /data.file
* vxdisk list > /vxdisk.file (save the disk name/device mappings)
3. Unmount, stop and remove the volume data1, yes thats right
remove it! (removing a volume does not actually destroy the data on
the disks, it simply deletes the mappings of the volume/plex/subdisk)
4. Remove the disks that the data1 resided on, and add them to the
new diskgroup with the same DM name.
* vxdg -g sourcedg rmdisk disk01
* vxdg -g targetdg adddisk disk01=c1t0d0
5. Rebuild the volume mapping form the saved file
* vxmake -g targetdg -d /data.file
6. Start the volume
* vxvol start data01

The above example is very simple as the volume sat on only one
disk. If that disk was used by other volumes that are not to be moved
to the newdg , then we have a problem. You can only move the disk out
of a DG, when all the subdisks are gone.
I always advise people to test this before REALLY trying it.
using ESMvxbu.bin by Espen Martinsen

After installing ESMvxbu.bin, you get some good scripts below
/usr/vx/utils The intension of these scripts is to assist in moving
selected volumes from one diskgroup to another (or a new one).

Package contents
1.save_info used to save information
2.remove_from_DG remove volumes from the diskgroup
3.make_new_DG Builds the volumes up again in the new DG
RUNME Documentation, sorry, it's in norwegian
count_configs counts which disks have VxVM config copies
remove_disk used by remove_from_DG
remove_volume used by remove_from_DG

OK, this is what you do: First: Be sure to save your entire
config as it is:
#/usr/vx/Save_All_DG /usr/vx

Then on with the job:
#cd /usr/vx/utils
#./1.save_info volume volume volume .......
#./2.remove_from_DG volume volume volume .......
(Continue to run this script until it sucseeds, It might fail,
and tell you to do something, like umount a filesystem etc....)

Now everything should be fine again, you can now edit
/etc/vfstab, to switch diskgroup, and remount the filesystems or start
some databases...

remember one thing; you can't empty the entire "rootdg" you
should have something in it. I usually have what I call a "minimal
rootdg"**; which only consist of a simple slice, usually 20Mb on slice
7 on the root-disk.

On an existing system, do like this: (make sure you have the slice!)
#vxdctl add disk $SLICE type=simple
#vxdisk -f init $SLICE type=simple
#vxdg adddisk $SLICE

With a fresh install of VxVM, just do like this after the pkgadd of vxvm:
#vxconfigd -m disable
#vxdctl init
#vxdg init rootdg
#vxdctl add disk $SLICE type=simple
#vxdisk -f init $SLICE type=simple
#vxdg adddisk $SLICE
#vxdctl enable
#vxdctl initdmp
#rm /etc/vx/reconfig.d/state.d/install-db

(No need for rebooting at all....)

I really hope you can use some of this, send me an email if you liked it!
** [Ed: caveat: If you use a simple slice for rootdg, and that
disk or slice fails, there will be no rootdg, and none of your volumes
will work anymore. VxVM requires there to be a rootdg. Also, Sun nor
Veritas will support this configuration. They recommend a mirror of
rootdg for this (among other) reasons. However, many people choose to
do this anyway.]

Remarks on caveat:

What we are doing here is this:

A lot of places, we don't want to mirror the bootdisk. Reason:
When the original bootdisk have failed and has been fixed, then both
rootdisk an rootmir are initialized, not encaptulated. This makes it
difficult for the technicians that switch disks. It's also difficult
if you by some other reason needs the "original" partitioning.

Typically we do this where there is one of this conditions:
1. There is a cluster/HA that takes the services to another machine
2. The system can allow 10 minutes downtime.

We have a script that "clones" the bootdisk instead of mirroring
it. This script sed's through all vfstab etc (also /etc/vx/volboot) (
contact me for further information.)

OK, now if the "rootdisk" dies, the machine will crash (of course)
But it will reboot immediatly on the secondary disk.

Where we have machines standing alone, which won't tolerate any
downtime, we often use DiskSuite to mirror bootdisks/rootdg


Post a Comment

<< Home