proper procedure for an lxextend

[Gord Moore]

I am having a discussion with a collegue about the "proper" way to do an lvextend in an existing LV with existing disks. I know the procedure would be different if I were adding disks, but I am just extending an LV and the filesystem.

Do I need to vgexport/vgimport to the alternate node if it is a simple lvextend? Are the LV definitions (for example the number of PE's now in the LV, and on which disk the PE's are located) defined on the alternate node during package startup (vg activation), or in the vgimport on the alternate node?

We are also concerned about problems using the vgimport -s flag. Has anyone had problems with the -s tickling the vg from the alternate node while the vg is active on the primary node? I believe this should not be a problem, and the manuals seem to say it can be done, but some things have occasionally gone wrong and we are uncertain about it. Has anyone used the vgimport -s flag on vg's with striped disks?

Thanks.

[Marco Santerre · Accepted solution]

I have to assume that you are talking about a ServiceGuard environment and if that is the case, you do not have to do a vgexport/vgimport to the alternate node.

In the case of a lvextend, the alternate node sees the same disks and therefore would see the same extents since the lvol is already defined. So, in my case, no I have never vgimported the LV when it was only an extent.

As for vgimport -s, though you can use it, I have always preferred using the list of disks in a file and used the -f option instead.

[James R. Ferguson]

Hi Gord:

If the only thing you are doing is changing the size of a logical volume, then you do not need to do anything special on the alternate MC/ServiceGuard node. Simply do your maintenance on the node holding the active logical volume. The reason for this is that when the volume group is activated on the alternate node, the logical volume information will be read from the LVM header.

Regards!

...JRF...

[A. Clay Stephenson]

There is no need to do anything on the adoptive node(s) for lvextends or filesystem extensions. This is all carried in the Volume Group Reserved Area (VGRA) of each disk in the VG (or in the case of the fiklesystem in the filesystem itself) If you are adding LVOLS then am import is needed because the adoptive node(s) will not have all the device nodes.

I never do vgimports of active VG's so I can't answer that one. I suspect (because vgscans do it as well) that it a a 'safe' operation. The vgimport is writing nothing on the disk itself. In general, I'm not even a big proponent of vgimport -s's because everything uses the same primary path. I prefer to conventionally do the vgimport although a vgimport -s is fine to identify the primary and alternate paths. You can then change this after the vgimport for more efficient SCSI paths.

[Gord Moore]

Good, concise answers. Thanks to all.