Should I vgexport / vgimport my BCVs or just deactivate / activate ?

[Stuart Abramson]

I'm working at a new location. I'm looking at their BCV scripts.

I have always vgexported (on HP-UX) the BCV Volume Groups from the BCV host before I started synching, and then vgimported them after the split.

The client here only "deactivates" the BCV volume groups (vgchange -a n) before the synch and then "activates" them after the split (vgchange -a y ).

It apparently works! It's been working for some two years...

What do we think of that?

[John Poff]

Hi Stuart,

We've always exported/imported our BCV VGs too, but I guess it must work. Are they doing a vgchgid in there somewhere?

JP

[Duncan Edmonstone · Accepted solution]

This will work fine until someone adds a new lvol to the volume group... but of course a new lvol likely implies a new filesystem, so scripts would need updating anyway to handle the mounts/umounts of the new filesystems.

So I guess its horses for courses...

HTH

Duncan

[Steven E. Protter]

If it is not broke don't fix it.

It would appear that the forth response indicates its possible to break things.

So the right plan for the right situation.

SEP

[Geoff Wild]

That's what we do as well - only vgexport/vgimport when change to vg is made.

deactivate/activate works fine (over 3 years now for us).

Rgds...Geoff

[Devender Khatana]

Hi,

We are using Veritas Volume Manager and do need to deport all disk groups before syncing.
Again no problems for us as well for past 3 years now.(Deporting is done through Script for all disk groups)

HTH,
Devender

[Stuart Abramson]

Are there any PROBLEMS with doing it this way (deactivate / activate)?

For example, in the vgexport method if you reboot while the volumes are exported, HP-UX won't try to activate the VG, mount the LVs, etc. In the deactivated case, he will try to activate them, but they might be "corrupt" because who knows where they will be in the synch cycle, and you'll get an error.

If you add LVs/PVs/mount points, etc, you have to update scripts or tables in all cases.

You only need "vgchgid" if you are mounting BCVs on the same host as STDs or in a cluster connected to STDs. We're not.

[Geoff Wild]

Setup /etc/lvmrc to NOT activate...

AUTO_VG_ACTIVATE=0

Then - for any vg's you want to activate on boot - set them in

custom_vg_activation()
{
# e.g. /sbin/vgchange -a y -s
# parallel_vg_sync "/dev/vg00 /dev/vg01"
# parallel_vg_sync "/dev/vg02 /dev/vg03"
/sbin/vgchange -a y -s /dev/vg01

}

Rgds...Geoff

[Devender Khatana]

Hi,

Yes, it is not advisable to have the
BCV to be set for auto activation.As you do not know when you server reboot(Due to any reason). If it happens during resyning then the second hosts can not open these VG's. It will through many EMS notifications showing hardware failures in accessing devices.

These should be controlled by some manual script or should be done during application start like package run in cmcluster.

HTH,
Devender

[Stuart Abramson]

Thanks all. Since it seems to be working just fine every night, I'm not going to mess with it...