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)
  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.
  5. Rebuild the volume mapping form the saved file
  6. Start the volume
    7. >

    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_infoused to save information
    2.remove_from_DGremove volumes from the diskgroup
    3.make_new_DGBuilds the volumes up again in the new DG
    RUNMEDocumentation, sorry, it's in norwegian
    count_configscounts which disks have VxVM config copies
    remove_diskused by remove_from_DG
    remove_volumeused 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....)
    #3.make_new_DG

    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!)
    #sh
    #SLICE=c0t0d0s7
    #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:
    #SLICE=c0t0d0s7
    #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