Rename VG?

[Adam Walker]

Is it possible to rename a volume group? I just finished doing a
clone on a box and when I imported the 20 volume groups it has made
them hard to identify.

Adam

[kal]

Adam Walker wrote:

vary them off, export them and re-import the VG with a different name
importvg -y NEWvgname hdisk#

[Simon Marchese]

exportvg <old name> then importvg -y<new name> hdisk<number> should do
it - but you should be able to rename without having to import, it's
just I can't remember whether you can do it in one command or many right
now.

[Clive Sparkes]

recreatevg perhaps? There's no man page for it but the usage output for
it is:
Usage: recreatevg [ -y VGname ] [ -p ] [ -f ] [ -Y lv_prefix |-l
LvNameFile ] [ -L label_prefix ] [ -n] PVname...
Recreates a volume group that is already existing on the specified set
of disks.

So if the VG is varied off and (for example) hdisk4 is in that VG then:
recreatevg -y newname hdisk4

note, it's a shell script so you can check the source code yourself.

Regards,
Clive

[Urban A. Haas]

I really would do the export/import to rename a vg.

Recreate vg is great, but it changes some things (PVIDs, VGID, LVIDs,
logical volume names and filesystem names by default flags) and I wouldn't
want to run something as destructive.

export/import is relatively harmless and people have been using it for this
purpose for years.

My $0.02 worth.

Urban

"Clive Sparkes" <cyb...@my-deja.com> wrote in message
news:3BF23668...@my-deja.com...

[Matthew Landt]

Clive Sparkes wrote:
>
> recreatevg perhaps? There's no man page for it but the usage output for
> it is:
> Usage: recreatevg [ -y VGname ] [ -p ] [ -f ] [ -Y lv_prefix |-l
> LvNameFile ] [ -L label_prefix ] [ -n] PVname...
> Recreates a volume group that is already existing on the specified set
> of disks.
>
> So if the VG is varied off and (for example) hdisk4 is in that VG then:
> recreatevg -y newname hdisk4
>
> note, it's a shell script so you can check the source code yourself.
>
> Regards,
> Clive

Recreatevg is to bring a duplicate copy of a VG online as another VG
name. This will change the PVID, could change LV and filesystem names.

Recreatevg REQUIRES there be NO ODM VG information associated with it.
So to run this command you must either A) change the PVID of the disk
(which is BAD BAD BAD if you are using it at the time), or B) export
the VG first. Since you need to export the VG to use either of these
commands, it is much easier/cleaner to just import again with a new
VG name. Recreatevg was intended to bring up 2 copies of one VG
simultaneously on one server, not just to rename it.

- Matt
--
_______________________________________________________________________
Matthew Landt - AIX and HACMP Cert. Specialist - la...@austin.ibm.com
IBM High Speed Interconnect - Fibre Channel I/O Dev/Test/Support
<< Comments, views, and opinions are mine alone, not IBM's. >>

[Clive Sparkes]

Matthew & Urban,

Thanks for the info, I must confess I've only ever used recreatevg to
fix problems on VGs located on vpath after a SAN glitch.

Regards,
Clive

[Jose Pina Coelho]

Don't. :-)

recreatevg is used to import a bitwise copy of a volumegroup. It was
introduced on AIX 4.3.3
and documented on AIX 5.

say you have a vg (vg01) on hdisk1 & 2 with fs's /alfa/1 & /alfa/2 and
raw lv's alfa01 & alfa02:

Turn off the VG
# varyoffvg vg01

Copy the physical volumes
# dd if=/dev/rhdisk1 of=/dev/rhdisk3
# dd if=/dev/rhdisk2 of=/dev/rhdisk4

At this point you have two sets of identical disks. So you have two
pairs of disks withe the same PVID. Since the OS uses the PVID to
identify the disks, you have a problem.
However, on the ODM, the PVIDs are still the original ones.

You can vary on the "original" VG by just saying
# varyonvg vg01

But at this point you're still "vulnerable". AIX will re-read the
pvid's into the odm
if it reboots.

Now, you recreate a VG on the new disks:
# recreatevg -y copy01 -Y C -L /copy

The command will:
- Give new PVID's to the disks to avoid any collisions with the previous
PVIDs
- Give a new VGID to the VG to avoid collisions with the previous VG.
- Prepend the argument of the 'Y' flag to the LV's, to avoid naming
collisions, while at the same time giving you predictable names (quite
important for RAW lv's.
- Prepend the argument of the 'L' flag to all filesystem mount points.

So now you have the copy01 VG, with filesystems /copy/alfa/1 &
/copy/alfa/2 and raw LV's Calfa01 & Calfa02.

This command is used in environments where the hdisks that make up a VG
are copied by the storage hardware (PIT copy or FlashCopy on the Shark)
and you want both the original and the copy available on the same
system.

This is quite usefull to handle backups on almost-24x7 environments.

varyoff, flashcopy & varyon take less than 5 minutes for 400 GB's of
disk.

The recreatevg step takes about the same time an importvg would, without
totaly messing the LV names & FS mountpoints.