incorrect LV config after disk clone

[kevin_m]

I cloned some EMC 'standard' disks on a production server to corresponding 'BCV' disks on a test server. The production server has 7 PV's containing 6 LV's, whereas the test server has 4 PV's and 4 LV's. The mapping is as follows:

production /dev/dsk/c11t7d2 - lvol1 - test /dev/dsk/c16t8d4
production /dev/dsk/c13t7d7 - lvol2 - test /dev/dsk/c16t8d5
production /dev/dsk/c11t7d4 - lvol3 - test /dev/dsk/c16t8d6
production /dev/dsk/c11t2d6 - lvol4 - not used on test server
production /dev/dsk/c13t2d7 - lvol5 (1/2) - not used on test server
production /dev/dsk/c13t13d5 - lvol5 (2/2) - not used on test server
production /dev/dsk/c13t13d4 - lvol6 - test /dev/dsk/c16t13d7

We've done this many times with no problems, but in this case there is a gap in the lvol sequence on the test server. As a result one of the logical volumes is sized incorrectly and not using any extents on one of the disks (c16t13d7). The vgdisplay details are attached. I've already taken workarounds to get the missing data mounted elsewhere, but my question is how to correct this situation for the future. Would the only option be to reconfigure the vg on the production server so that the disks I need on test have contiguous logical volumes?

- Kevin

[Armin Kunaschik]

Correct me if I'm wrong:
You have 7 disks in the vg and clone only 4 disks? I doubt that this is supported in any way. You should always clone all disks of a vg!
My advise would be either to clone all 7 disks or split the whole thing into 2 vg's and clone just the vg with the data you need.

As a hotfix (not more!) you can use pvmove to move extents to other disks.

My 2 cents,
Armin

PS: Please assign points if you find answers useful!

[Eric SAUBIGNAC]

Bonjour Kevin,


As said Armin it is probably not supported. But from an other point of view, we could consider that you just try to deal with a VGs which is missing 3 of 7 disks ... it should not be a problem.

The problem I can see is that lvol6 on test shows same size as lvol4 on production. May be it is just a naming problem. Do you use a mapfile to import the VG or not ? If not, you should try :

- on production server : vgexport -p -m vg30.map vg30

Push vg30.map on test server.

- on test server : vgimport -m vg30.map vg30 /dev/dsk/c16t8d4 /dev/dsk/c16t8d5 /dev/dsk/c16t8d6 /dev/dsk/c16t13d7

Regards

Eric

[kevin_m]

Thanks for the responses. You make a good point about splitting up VG's but my predecessor configured several of our servers in this manner. The extra LV's are for database archive logs or exports which we don't need on test servers. That's the reason for not cloning the entire VG. Usually it works since the disks containing the DB files are grouped together (at the beginning of the VG). I have the correct data and number of extents on all disks so essentially it's the LV config that's an issue.

I didn't try removing the volume group and importing from the map file. Since the disks contain information about 6 LV's, would they all be created during the vgimport? Or could I edit the map file to remove lvol4 and lvol5 before importing?

Kevin

[Eric SAUBIGNAC]

"I didn't try removing the volume group and importing from the map file."

vgexport -p ... does not remove the vg. "-p" is "preview". The goal is only to get a mapfile.

"Since the disks contain information about 6 LV's, would they all be created during the vgimport?"

Yes, but it does not matter. What is important is that lv are correctly imported regarding physical disks

"Or could I edit the map file to remove lvol4 and lvol5 before importing?"

You should not. An no more edit the mapfile to change order. For example, initial map is :

VGID acf01b8247bda82f
1 lvol1
2 lvol2
3 lvol3
4 lvol4
5 lvol5
6 lvol6

And you modify it this way :

VGID acf01b8247bda82f
1 lvol1
2 lvol2
3 lvol3
4 lvol6 ---> Modified order

You MUST leave the mapfile UNMODIFIED.

After importing on test, you can lvremove lvol4 and lvol5, then "vgreduce -f" for missing disks. You will have a clean clone of what you exactly want.

Of course, working like this assumes that you control exactly where each LV resides ...

Eric

[kevin_m]

Should I use the -s option with vgexport so the VGID is written to the map file? If so then I'm assuming -s should be used with vgimport on the test server. It appears the other option would be to specify all the PV's during the import as in the example above.

Unfortunately I won't get a chance to try it for a week or two. Despite being a test environment I'll need to schedule the downtime.

[Eric SAUBIGNAC · Accepted solution]

"Should I use the -s option with vgexport so the VGID is written to the map file?"

Why not ... it can help you to diagnose problems on test box side.

"If so then I'm assuming -s should be used with vgimport on the test server"

It depends on what version of LVM you are using. In the past, when a VGID was in mapfile, it was not possible to import a VG without -s option. Now it is no more mandatory.

"It appears the other option would be to specify all the PV's during the import as in the example above."

Yes ... and I do prefer working like this rather than with "-s" : vgimport does whatever it wants and I want to control everything ;-) I mean, for example, there are pvlink and I don't want them to appear in the vg, I want disk to be imported in a specific order, etc ...

Other thing is that when you import a cloned VG it is better to change VGID before (vgchgid). Not mandatory on a different box than the source but a good practice to keep in mind. If you vgchgid the cloned disks, vgimport -s will have no sense.

"Despite being a test environment I'll need to schedule the downtime."

Why ? You mean that vg30 is activated, FS mounted and used on test box ? So how do you deal with lvol6 wich does not correspond to the one you was expecting ?

Evening here, back home now ...

Regards, Eric

[kevin_m]

Yep the volume group is active. The DBA made some creative changes and redirected data on the 4th PV to another mount point. We just scp'd those files to the test server and started up the database again. It's messy but I ran out of troubleshooting time.

Thank you for the clarification, especially regarding the -s option. I'll read up on vgchgid and determine when I can take another shot at this.

Kevin

[kevin_m]

I finally figured out some tricks to this process on different servers. In that case the test environment had a disk that wasn't synchronized from production as part of the BCV volume group. I removed that from the list of devices for the vgimport then extended it into the volume group later. The map file from production was modified to remove lines for lvol's that weren't used on the test server. After running lvremove and vgreduce -f to clean up the volume group it worked out fine. I didn't use the -s option or vgchgid at all.