ignite and lvm

[Mark Greene_1]

I'm am doing a test of the ignite process on our live L2000 using our current not-yet-live L2000 which has the exact same config. In the ignite config.recover script I've got the commands for mirroring the root vg (from the ignite pdf on working with mirrored disks), and these are working fine. I also have the vgimport for the data volume group which spans all 10 drives in the sc10 array, and those drives are setup into 5 mirrored pairs. There is no file system on this volume group, it is used for a raw database.

The problem I am having is that the lvols for the volume group for the data vg all mount unmirrored and at zero bytes. I assume after the vgimport -m [mapfile] [devicelist] I have to lvextend all the lvols for the data vg?

My question is given that the lvols mounted at 0 bytes, will doing the lvextend -m 1 .... to setup the mirrors work, or should I lvreduce and then lvcreate them all first, and then do the lvextend? I am hoping to get all this put into the ignite script as well.

TIA,
mark

[G. Vrijhoeven]

Hi Mark,

You should be able to lvextend -m 1 a 0 bytes sized lvol.

Gideon

[Mark Greene_1]

>>You should be able to lvextend -m 1 a 0 bytes sized lvol. <<

Gideon,

I realize that, but they all should be 1.5 or 2 gig each. I don't know why they mounted as 0 bytes, and am not sure what steps and in what order to fix that.

mark

[Helen French]

Hi Mark:

For the first question - NO. If you 've properly vgexported the lvols with map files, then after vgimport, it should be exactly the same. You don't need to do lvextend to remirror it.

Did you check the VG's before exporting it ? Did you find any errors/warnings while vgimport/vgexport ? If you wish to start from fresh, then the better way will be to recreate new LVs, and lvextend it.

HTH,
Shiju

[Mark Greene_1]

Shiju,

Before creating the ignite tape, I ran /usr/sbin/vgexport -pvm /tmp/tmpmapfile datavg and compared the results via diff to the mapfile in /etc/lvmconf and they were exactly the same. There were no errors from the vgimport when booting from the ignite tape on the second system.

I had assumed that because I did the make_recovery with the -A to grab all of the root vg that the entries in the /etc/lvmconf would be sufficient to define the lvol sizes and locations for when I booted on the second system. I don't know why the lvols mounted with 0 bytes (and 0 PE and only 1 PV each).

My goal is not only to correct this on the second system, but in doing so have something I can add to the ignite process so that if we ever have to reboot from that tape, the system will come up correctly configured for use.

mark

[Helen French]

Hi Mark:

What is the output of pvdisplay -v of second hard disks ? Is it showing in /etc/lvmtab ? If yes, then whether it shows up with vgdisplay -v ?

Is the second system's paths and SCSI id's are same ? Did you try a vgcfgrestore using the files under /etc/lvmconf ?

HTH,
Shiju

[Mark Greene_1]

>>What is the output of pvdisplay -v of second hard disks ? Is it showing in /etc/lvmtab ? If yes, then whether it shows up with vgdisplay -v ?

Is the second system's paths and SCSI id's are same ? Did you try a vgcfgrestore using the files under /etc/lvmconf ? <<

pvdisplay, "strings /etc/lvmtab", and vgdisplay are the same on both systems.

I've not done the vgcfgrestore.

I did find that if I try and do anthing with lvchange or lvremove on the lvols in question, that I get an error stating the the lvol could not changed/removed because the lvol number references a non-existant lvol.

So, how can lvdisplay show me the info, but lvchange/remove not see them?

mark

[S.K. Chan]

Mark, I'll try to answer the last part of the question though I have not really follow closely the progess of this thread ..

The error "lvol could not changed/removed because the lvol number references a non-existant lvol" you are seeing has happened to me before .. eg: I got /dev/vg01/lvol1 which has 0 size (allocated PE=0) which shows up in "vgdisplay vg01" and "lvdisplay /dev/vg01/lvol1" but when I try to lvremove it I get the error. What I did was remove the device files ..
# cd /dev/vg01
# rmsf lvol1
# rmsf rlvol1

and then go back to the lvremove and it works fine.

[Mark Greene_1]

>>What I did was remove the device files ..
# cd /dev/vg01
# rmsf lvol1
# rmsf rlvol1

and then go back to the lvremove and it works fine. <<

S.K.,

Cool! While this doesn't yet tell me how to fix the ignite process, it gets me around my immediate issue so I can procede with the testing on the second system I was doing this for.

Thanx!

mark

[Helen French]

Hi Mark:

Does the pvdisplay and vgdisplay shows all PE's as free ? Does it show that it's allocated to the LV's ?

Also use make_tape_recovery to make the ignite tapes. It's more convenient and with better tools.

HTH,
Shiju

[Mark Greene_1]

>>Does the pvdisplay and vgdisplay shows all PE's as free ? Does it show that it's allocated to the LV's ?<<

Shiju,

Both pvdisplay and vgdisplay show all PE's as free and zero allocated. This is, at least, consistent with the lvol's being 0 bytes.

mark

[Helen French]

Hi Mark:

Another thing: In this case, you are not doing a disaster recovery checking rt ? Instead, you care just creating another system with new disks using the ignite tape.

The difference is that if only root disk failed and if the data VG's are the same, then just recovering from the ignite will be fine. Because the VGDA of the data VG's (disks on SC10) remains the same. But in your case, you 've recovered the ignite tapes and the vg00. But the VGDA of SC10 disks (data VGs) doesn't have any information on that. So I think just doing 'vgcfgrestore' from the /etc/lvmconf files will resolve the issue.

I think, I am not confused now =))

HTH,
Shiju

[Helen French]

Hi Mark:

Another thing: In this case, you are not doing a disaster recovery checking rt ? Instead, you are just creating another system with new disks using the ignite tape.

The difference is that if only root disk failed and if the data VG's are the same, then just recovering from the ignite will be fine. Because the VGDA of the data VG's (disks on SC10) remains the same. But in your case, you 've recovered the ignite tapes and the vg00. But the VGDA of SC10 disks (data VGs) doesn't have any information on that. So I think just doing 'vgcfgrestore' from the /etc/lvmconf files will resolve the issue.

I think, I am not confused now =))

HTH,
Shiju

[Mark Greene_1]

>>Another thing: In this case, you are not doing a disaster recovery checking rt ? Instead, you care just creating another system with new disks using the ignite tape. <<

Correct. Actually, I am doing a "proof-of-concept" for swapping 2 of the 18 gig drives for 36 gig drives. We are close on space on our live system, and before doing the disk swap, I wanted to setup this other system to look the same as the live one. That way I can do the swap and verify the order of events without worrying about blowing-away any live data. The first step, of course, is to setup the vg's and lvols, then do the data restore, then swap the drives. Being stuck at step one isn't that encouraging. :-(

I have a call into HP via our software vendor (from whom we bought the system and have this convoluted service contract with), so I am hoping to hear back from them today. If not, I may try the recover solution you posed.

thanks!
mark

[S.K. Chan · Accepted solution]

Just a thought Mark .. why don't you try lvreduce your mirror copies to zero, then do your vgexport, then vgimport , then lvextend the mirror copy back to the PV. I've seen some glitch with import/export of mirrored LVs in the past though not frequent and I think if you did this additonal step (lvreduce/lvextend the mirror copy) the export/import will be cleaner at the end.
1) Lvreducing mirror copy to 0 on all your LVs.
Ex: lvreduce -m 0 /dev/vg02/lvol1 /dev/dsk/
2) Do your vgexport
3) Do your vgimport. If everything looks well then ..
4) lvextend -m 1 /dev/vg02/lvol1 /dev/dsk/

[Helen French]

Hi Mark:

Working with HP will be a good solution. Good luck with that !

The reason why I suggested the last post is: 'vgimport/vgexport' works only if the disks will have the VGDA data available on that. If the disks doesn't have any VG information on that, then vgimport will not do the taks for you. In your case, you are going to set up new disks. And these disk doesn't have any VG information on that. So, if you just do a vgimport, it will not create anything. Instead of doing that, you can do either:

# vgcfgrestore OR create new VG information with vgcreate, lvcreate etc.

HTH,
Shiju