pvlinks status after importing/exporting VG

[Bruce Troutman]

A switch is being introduced in the environment and the vg needs to be exported. Am i correct to assume that the pvlinks in that volume group will have to be set up again because of the device files will change?

#vgexport ???v -s ???m /tmp/vg03_map /dev/vg03
reboot
#vgimport ???v -s ???m /tmp/vg03_map /dev/vg03

Pvlinks?

[Sridhar Bhaskarla · Accepted solution]

Hi Bruce,

When you used -s option, it will find out all the devices including PVlinks and import them into the volume group.

A suggestion however. Above will work just fine. But if you have many disks, then -s may take much longer. You might want to consider using -f option and grab the disks into a file.

vgexport -v -m /tmp/vg03.map -f /tmp/vg03.disks vg03

After the re-arragements, only the controller numbers will change. So edit vg03.disks file and globally replace the c# with the new ones. For ex., if c3 becamse c5 later, you can simply do :%s/c3/c5/g' in vi session. Once it is done, use import using -f option again.

vgimport -v -m /tmp/vg03.map -f /tmp/vg03.disks vg03.

I assume you would create the directory+group file etc.,

-Sri

[Marco Santerre]

Actually, you won't have to do a thing if you are using the -s switch. Your system will scan your disk and add them in the vg, whether pv links were there in the first place or not.

See man vgimport :
Since the -s option causes a search on the system for each disks with
the same vg_id. When vgimport reconstruct the newly imported volume
group entry in /etc/lvmtab file, the order of disks could be different
than it was before. And the following will happen:

The designated primary and alternate link might not be the same
as it was configured before.

Alternate links will be added to the importing volume group even
if they might not be configured in the volume group initially.

If the original primary path of a disks become an alternate path after
the newly imported volume group entry is created in /etc/lvmtab, the
order can be easily reverted by using vgreduce to remove the primary
path and then use vgextend to add the path back again.

So your pvlinks will be created, only the order in which the disks will be added to your VG might not be the order you like, therefore you can then re-arrange them using vgreduce and vgextend to your likings.

[S.K. Chan]

Since you're using -s (which searches the disk with VGID instead of device naming) it should take care of the pvlinks for you. You might see the order of the pvlinks being changed because you cannot guarantee the order of how the system scan the disks for its VGID but that should not matter (the order).

[Helen French]

Your command will work fine and will import all your PVs and pvlinks. The issue is since you are using -s option, your pvlinks will not be in the order as before. You may see all your PVs primary paths will be from the same controller. If you don't want this to happen, then specify each disk individually (or using another script) or manually set up the pvlinks after vgimporting.

[Bruce Troutman]

Thanks, that was the answer I wanted to hear :)

[Claudiu Schmidt]

Hi,

if you are using the -s option, you can have problems if you have BCV, or BC Luns on the storage. Then at the vgimport command, he will find double disks having the same pvid, and stop importing. Then you have to find out the disk devicefiles manualy

[Claudiu Schmidt]

Hi,

if you are using the -s option, you can have problems if you have BCV, or BC Luns on the storage. Then at the vgimport command, he will find double disks having the same pvid, and stop importing. Then you have to find out the disk devicefiles manualy

[Claudiu Schmidt]

Hi,

if you are using the -s option, you can have problems if you have BCV, or BC Luns on the storage. Then at the vgimport command, he will find double disks having the same pvid, and stop importing. Then you have to find out the disk devicefiles manualy