vgimport with alternate links

[Shankar_6]

Hi,

We have a plan to migrate storage from XP-512 to new storage box.Storage is connected to 2-node cluster.We planned to use vgexport/vgimport to get the vg configurations after new storage is alloted to nodes.I have below queries on this work.

1.Presently the node have 1 primary link and 3 alternate links to old storage box.Can i perform vgexport with alternate links? If i do vgimport after new storage is connected will it looks for the same alternate paths?
In that case what happens if path got changed..?

2.Will the controller number changes after new storage box is connected(we are not changing the controller in server side and not removing the device files)..?

Points will be alloted.

Shankar.B

[Patrick Wallek · Accepted solution]

vgexport / vgimport will not do you any good in this case. These commands are meant to export / import VGs to different machines. They are NOT meant migrate a VG configuration from one machine to another.

If you were to do a vgexport from the old storage, and then run vgimport on the new storage it will fail. It will fail because the new devices will not have any VG configuration on them.

To do what you want to do it will be easier to extend your current VGs with the new devices and alternate paths.

To your last question, YES your device paths will definitely change. You have new devices which entails new paths.

[Shankar_6]

Hi Patrick,

Thanks for your reply.

Activity is like old storage box will be removed.Data copy will happen on storage level(I think through virtualization) to new storage.In this case we need to vgimport/vgexport using the disks on the new storage..right?

Please advise..Points will be allotted.

Shankar.B

[Matti_Kurkela]

1.) Yes, you can run vgexport with alternate paths. I recommend you use the "-s" option of the vgexport/vgimport commands. It stores the VGID into the map file in the export phase.

When importing with the "-s" option, the system will search that VGID from all the disks the system is currently seeing, and import them all. The first device with the correct VGID becomes the new primary link, all the rest will be alternate links.

When you do a vgexport, the system essentially forgets the exported VG and the paths of the PVs that belonged to it. The VGID remains on the exported disks, so the correct disks can be located if the VGID is known.

2.) Yes, the controller number will change. With FibreChannel, the controller/device/LUN number triplet is tied to the WWN of the device. If the WWN changes, so will the c#t#d# triplet.

[Tim Hempstead_1]

Hi,

We did some similar sounding work last month to migrate between disk arrays. We had luns on the old array with 1 primary and 3 alternate links.

We did a vgexport (with the -s switch to get the vgid into the map file (-m switch)). The disk array was then disconnected from the server and copied to a new array at the SAN level (preserving the lun structures). This was then presented to the server and a vgimport (with -s and -m) run to get the storage back again. (vgchange then used of course to reactivate the volume groups).

The vgexport and vgimport had no problems with the alternate links and when the import was complete the volume groups had a full complement of alternate links for each lun, (1 primary and 7 alternates!), although in all cases the same set of addresses was set as primary so if you want to balance your primaries across hbas you may need to fiddle around afterwards.

Tim

[Shankar_6]

Hi All,

Thanks for all your reply.Points allotted.

Shankar.B

[Shankar_6]

thanks