vgexport for map file on inactive VG

[dev44]

Is it possible/recommended to get a vg map file on an inactive VG? I have three nodes in a cluster and wanted to write a script to just grab map files from the whole list of all VG's (active and in-active) and then import them into the new node. Or do I have to create the map files from each nodes' active VGs?

Thanks,

[Pete Randall]

As a matter of fact, you can't run vgexport on an active vg:

# vgexport -p vg03
vgexport: Volume group "vg03" is still active.


Pete

[dev44]

Thanks Pete.....my question is can I create a legitimate map from an INactive Vg or is it best to do it from active vg's.

The command that I run is:

vgexport -v -s -p -m file.map vgxx

[Rita C Workman · Accepted solution]

You say what is best or recommended. So, from my perspective, regarding making mapfiles for a clustered environment, I'd tend to lean to making your mapfiles from the primary node, while it's active. Then copying it over to the other nodes and vgimporting. Cause when it's running, the vg is running set as exclusive (i.e. vgchange -a e) with control to the cluster (i.e vgchange -c y). So when the scripts they will change the vg settings appropriately. Remember, to put a volume into a cluster you must:
vgchange -a n
vgchange -c y

See my point...

My other reason is, if it's inactive, ..why is it inactive and do I really need it. Must not, cause it's inactive. Or it's inactive cause something is not right with it, so before I'd make a mapfile I'd make sure it was okay and could be activated. Then I'd make the mapfile.

But that's just me....

Rgrds,
Rita

[dev44]

All nodes have active and inactive VG's. The inactive VGs are the active VGs on other nodes, for failover reasons.

So I would like to vgexport -p and create map files from all active and inactive VGs from one node.

[Rita C Workman]

OK...then to answer.

Why would you want to vgeport the inactive/failover nodes volume group? The one that really counts and would be up to date is the one on the primary node. Where your package is running.

This guarantees that you have the latest, correct volume group information. Can't count how many I got interupted and one the multi-node cluster here I missed vgimporting the latest vg mapfile. Don't realize till I do a failover and it doesn't come up right.

Now, with your logic, you are going to make a mapfile from a node where the volume is not active. Sorry I don't see any reasonable reason to do what you are suggesting. In fact I predict your mapfiles will get confused or you'll copy over some potentially old mapfile from some inactive volume group and maybe overwrite a good one.

I'm sorry, I can not follow your logic or the benefit of it. If I understand what you're trying to do correctly.

Rgrds,
Rita

[dev44]

Ok, makes sense....but the inactive ones have to be accurate as they are the failover for the active VGs. So if they contain inaccurate information, then the failover would bomb, correct?

[Rita C Workman]

Correct.

So the goal is always to ensure that your failover nodes vg information is the same as the primary. Hence, making your mapfile from your primary node that you know is running correctly, and then importing that mapfile into the other nodes.

If something goes awry on a failover, you know it's not the mapfile - it's strictly something on that node that you missed.

Kindest regards & happy clustering,
Rita

[dev44]

Thanks Rita

[Viktor Balogh]

>As a matter of fact, you can't run vgexport on an active vg

Pete, the question was 'to get a vg map file' and not 'to export it'. You can everytime get a mapfile from your inactive VG, but as Rita said it's not the recommended way.

# vgexport -p -m mapfile.map vghomeora
vgexport: Volume group "vghomeora" is still active.
#

This "still active" message is only a warning that the VG hasn't been exported. But the mapfile is there..