topic Re: Oop! More volume group problems ... in Operating System - HP-UX

Oop! More volume group problems ...

Melissa Murphy — Mon, 18 Jun 2001 14:06:06 GMT

I seem to have gotten myself into a little pickle again. I had volume groups mounted on each of my two systems, and then (for a failover situation) was making additional volume groups. On computer #1, Data, a 100GB array was called vg100 and on computer #2, Lore, a 67GB array was called vg67. From there, I have a couple problems.

Right now I have a vg67 and a vg100 on Data, both of which are unmounted and deactivated. I tried:

#vgchange -a y vg67
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c4t0d1":
Invalid argument
vgchange: Warning: couldn't query physical volume "/dev/dsk/c4t0d1":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query all of the physical volumes.
vgchange: Couldn't activate volume group "vg67":
Quorum not present, or some physical volume(s) are missing.

I do a vgdisplay or bdf and don't see anything about a vg67 or vg100. I'm trying to make sure they even exist. I can't create logical volumes on vg100 because it doesn't exist in the lvmtab file. Okay. I try vgimport vg100 and it says it can't read the physical volume. I pvcreate and get: pvcreate: writing LVM record: Invalid argument. I can't remove it because it doesn't exist in the lvmtab. So what I'm thinking is the volume group isn't even there, but I can't even remake it. And the problems with vg67 are still that I can't activate it, but not for the same reason as vg100.

I've posted here a few times with similar problems, and I've used those answers and read over many other people's problems, and I'm not able to work this out with that information. Much like another question I had, I cannot remove a certain volume group on Data either .I bdf and see /dev/vgraid/lvprojects, which I thought was long gone. /dev/vgraid does not exist, as far as I can see. The problem I was having once was similar in that I had a volume group that was left over and it was preventing me from creating new volume groups. Right now on Data I have both vg67 and vg100 and don't need any others, so I don't think this remnant of vgraid is really interfering. How do I get rid of this volume group now? The way I believe I did it before was just forcing a new pv and recreating a vg that I wanted, but I don't think I have to go through that now.

I've been trying to do this in SAM, but I seem to be having problems there. I can go to Disks and Files Systems and see my vg100/vg67 on Data, but when I try to go view more information, I get:

A SAM internal error has occurred. Additional information regarding this error has been logged to the SAM log file (/var/sam/log/samlog). Contact your HP rep ... yadda yadda. Should I really just call up HP support and have then help me out with everything? Is calling them worth it and going to get things sorted out?

If you have any suggestions for me, that would be great. Thank you very much.

Melissa

Re: Oop! More volume group problems ...

Vincenzo Restuccia — Mon, 18 Jun 2001 14:08:30 GMT

Try
#mv /etc/lvmtab /etc/lvmtab.old
#vgscan -v

Re: Oop! More volume group problems ...

Melissa Murphy — Mon, 18 Jun 2001 14:16:30 GMT

Thank you for your quick response, I don't think it solved everything yet, though.

And the output ....

Creating "/etc/lvmtab".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg00".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg67".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg100".
Couldn't stat physical volume "/dev/dsk/c4t0d0":
Invalid argument
Couldn't stat physical volume "/dev/dsk/c4t0d1":
Invalid argument
Physical Volume "/dev/dsk/c4t0d7" is not part of a Volume Group
Couldn't stat physical volume "/dev/dsk/c2t2d0":
Invalid argument

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c0t5d0

The Volume Group /dev/vg67/group was not matched with any Physical Volumes.
The Volume Group /dev/vg100/group was not matched with any Physical Volumes.
#

That doesn't quite seem right. Still cannot vgimport vg67. Still get:

# vgchange -a y vg67
vgchange: Volume group "/dev/vg67" does not exist in the "/etc/lvmtab" file.
# vgchange -a y vg100
vgchange: Volume group "/dev/vg100" does not exist in the "/etc/lvmtab" file.
#

as well. Do you have an idea of where I should go from here?

Thanks,

Melissa

Re: Oop! More volume group problems ...

Vincenzo Restuccia — Mon, 18 Jun 2001 14:26:29 GMT

Try http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x068e663ce855d511abcd0090277a778c,00.html

Re: Oop! More volume group problems ...

Christopher McCray_1 — Mon, 18 Jun 2001 14:32:38 GMT

Did you by chance bind a LUN first before creating the vg? Just wanted to be sure.

Re: Oop! More volume group problems ...

Melissa Murphy — Mon, 18 Jun 2001 14:47:52 GMT

Well, I read through that post and the problem seems simlar, but not quite the same. In there I found the advice to do the following, and this is its result:

# vgcfgrestore -R -n /dev/vg67 /dev/rdsk/c4t0d1
vgcfgrestore: Volume group "/dev/vg67" does not exist in the "/etc/lvmtab" file.
vgcfgrestore: IO error on Physical Volume device /dev/rdsk/c4t0d1: #
# vgcfgrestore -R -n /dev/vg100 /dev/rdsk/c4t0d0
vgcfgrestore: Error opening LVM configuration file : /etc/lvmconf/vg100.conf
#

If it helps, this is there is this:

lore:/# strings /etc/lvmtab
/dev/vg00
/dev/dsk/c0t6d0

data:/# strings /etc/lvmtab
/dev/vg100
/dev/dsk/c4t2d0
/dev/vg02
/dev/dsk/c1t5d0
/dev/vg67
/dev/dsk/c4t2d1

This is how I initially created vg67 on Lore:

# pvcreate -f /dev/rdsk/c4t0d0
# mkdir /dev/vg67
# mknod /dev/vg67/group c 64 0x010000
# vgcreate /dev/vg67 /dev/dsk/c4t0d1
# lvcreate -L 69372 vg67
# newfs -F vxfs /dev/vg67/rlvol1
# mkdir /export/lore
# mount /dev/vg67/lvol1 /export/lore

And all that wasy okay. I did the same thing for vg100 (c4t2d0) on Data with node 0x050000 (And yes, now I know that's not proper if it's the third volume group, should have been 0x030000). I unmounted/deactivated vg67 on Lore and created a vg67 (c4t2d1) on Data. I'm not sure if I messed up real early on or when it was if I made a mess while trying to fix things.

Ideas?

Thanks for all your help,
Melissa

Re: Oop! More volume group problems ...

Christopher McCray_1 — Mon, 18 Jun 2001 15:04:45 GMT

I'm going to have to look at this. I have a couple of questions, though. What type of "failover" are you referring to? I am also assuming that you are using a 12H autoraid when you refer to array; is this correct? I'm going to try to stick this out. Regards.

Re: Oop! More volume group problems ...

Melissa Murphy — Mon, 18 Jun 2001 15:09:43 GMT

Here's some reading to get you up to speed. I accidentally posted in general when I meant to in LVM with my other posts. This should give you some background on my problem.

Messed up Volume Groups!
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x149e663ce855d511abcd0090277a778c,00.html

More volume group problems
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xb49e663ce855d511abcd0090277a778c,00.html

More questions! RAID, volume groups, etc.
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x659f663ce855d511abcd0090277a778c,00.html

Thanks,
Melissa

Re: Oop! More volume group problems ...

David Child_1 — Mon, 18 Jun 2001 16:58:02 GMT

Mellisa,

Just a couple of things:

1. Make sure the disks are still accessable by the system (# ioscan -funC disk)

2. When you set up these disks on the second server, did you do another 'pvcreate'? If you did, then all the data and disk header information was wiped out. I'm not sure what type of disks and failover setup you are using, but at a high level you should:
a. 'pvcreate' your disks on serverA
b. set up your volume groups/lvols on serverA
c. you can then vgimport these onto serverB

Of course I left out a lot of details since I'm not sure at this point if this is your issue. Check out 'vgchgid' as well.

Re: Oop! More volume group problems ...

Christopher McCray_1 — Mon, 18 Jun 2001 17:48:30 GMT

Sorry for the long moment of silence; I was busy installing apps downstairs. I concurr with what david has said. If your disks are accessable from both machines, then you need only create the vgs from scatch once, and in the case of failure of one machine, you can then import the vgs onto the other. I suggest you start over and go through the process again. I have read your other trouble calls and agree with what they are saying. If you want a real failover solution, MCServiceguard is what you want. Let us know how you're doing.

Re: Oop! More volume group problems ...

Melissa Murphy — Mon, 18 Jun 2001 18:52:38 GMT

Thanks a bunch guys, but I'm still not completely on my way. I would start over completely, but I can't seem to clean up enough so that I can. I was planning on keeping vg100 where it is on Data and vg67 on Lore the way they're supposed to be. I was going to remove vg67 on Data and vg100 on Lore, which would be mounted in the case of an emergency. So on Data right now I just have vg100, but I still have both of them on Lore. I guess this is what I'm trying to do:

# vgremove /dev/vg100
vgremove: Volume group "/dev/vg100" does not exist in the "/etc/lvmtab" file.
vgremove: Couldn't remove volume group "/dev/vg100".
# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -v
Creating "/etc/lvmtab".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg00".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg67".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg100".
Couldn't stat physical volume "/dev/dsk/c4t0d0":
Invalid argument
Couldn't stat physical volume "/dev/dsk/c4t0d1":
Invalid argument
Physical Volume "/dev/dsk/c4t0d7" is not part of a Volume Group
Couldn't stat physical volume "/dev/dsk/c2t2d0":
Invalid argument

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c0t5d0

/dev/vg00
/dev/dsk/c0t6d0

The Volume Group /dev/vg67/group was not matched with any Physical Volumes.
The Volume Group /dev/vg100/group was not matched with any Physical Volumes.
Scan of Physical Volumes Complete.
#

Maybe I'm wrong here, but I thought that the volume groups vg67 and vg100 existed. Maybe not? Well, assuming that, I went to start fresh, beginning with pvcreate.

# pvcreate -f /dev/rdsk/c4t0d1
pvcreate: writing LVM record: Invalid argument

Alright, so I went to try to create vg67 there.

# vgcreate /dev/vg67 /dev/dsk/c4t0d1
Increased the number of physical extents per physical volume to 17346.
vgcreate: IO error on Physical Volume device /dev/dsk/c4t0d1: #

Well, I thought I'd just trash the physical volume.

# pvremove /dev/rdsk/c4t0d1
pvremove: Physical Volume "/dev/rdsk/c4t0d1" contains no LVM information

What is the problem here with my physical volume? Do you know what I need to do in order to rebuild my volume groups? Thanks.

Still truckin',

Melissa

Re: Oop! More volume group problems ...

dhanish — Tue, 19 Jun 2001 13:50:03 GMT

Hi,
Can u pls try moving the lvmtab and lvmtab.old and doing the vgscan again.

Re: Oop! More volume group problems ...

Eddie Warren — Tue, 19 Jun 2001 14:52:28 GMT

Hi Melissa,
If the arrays are being shared by both systems, verify the hardware paths are the same. For instance do
"ioscan -fnC disk" on both systems and compare the output. It sounds like when you tried to import the volume group the system did not recognize the hardware path. This would occur
if you did a "vgexport" (created your mapfile and copied it to the system you are doing the vgimport. "The hardware paths would have to be the same on both systems".
Take Care, and good luck.

Eddie

Re: Oop! More volume group problems ...

Melissa Murphy — Tue, 19 Jun 2001 15:52:17 GMT

Thanks for your suggestions, guys.

I did another mv /etc/lvmtab /etc/lvmtab.old followed by a vgscan -v and here is what I got:

# vgscan -v
Creating "/etc/lvmtab".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg00".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg67".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg100".
Physical Volume "/dev/dsk/c4t0d7" is not part of a Volume Group
Couldn't stat physical volume "/dev/dsk/c2t2d0":
Invalid argument

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c0t5d0

/dev/vg00
/dev/dsk/c0t6d0

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c4t0d0

/dev/vg67

vgscan: Quorum not present, or some physical volume(s) are missing.
Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c4t0d1

The Volume Group /dev/vg100/group was not matched with any Physical Volumes.
Scan of Physical Volumes Complete.
*** LVMTAB has been created successfully.
*** If PV links are configured in the system.
*** Do the following to resync information on disk.
*** #1. vgchange -a y
*** #2. lvlnboot -R

Then I tried:

# vgchange -a y
Volume group "/dev/vg00" has been successfully changed.
vgchange: Couldn't activate volume group "/dev/vg67":
Quorum not present, or some physical volume(s) are missing.
# lvlnboot -R
vgcfgbackup: Volume group not activated.
# vgremove vg100
vgremove: Volume group "/dev/vg100" does not exist in the "/etc/lvmtab" file.
vgremove: Couldn't remove volume group "vg100".

So that didn't work out. I never tried vgimports and vgexports like I guess I should have. Right now I can't even remove or recreate any. I looked at the ioscan and the hardware paths were something that I was curious about at one point. Here are portions of ioscan -fnC disk on each computer:

On Lore:

Class I H/W Path Driver S/W State H/W Type Description
==================================================================================
disk 6 10/8.8.0.255.0.0.0 sdisk CLAIMED DEVICE LSI INF-01-00
/dev/dsk/c4t0d0 /dev/rdsk/c4t0d0
disk 8 10/8.8.0.255.0.0.1 sdisk CLAIMED DEVICE LSI INF-01-00
/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1
disk 7 10/8.8.0.255.0.0.7 sdisk CLAIMED DEVICE LSI Universal Xport
/dev/dsk/c4t0d7 /dev/rdsk/c4t0d7
disk 2 10/12/5.2.0 sdisk CLAIMED DEVICE

On Data:

Class I H/W Path Driver S/W State H/W Type Description
==================================================================================
disk 8 8/12.8.0.255.0.2.0 sdisk CLAIMED DEVICE LSI INF-01-00
/dev/dsk/c4t2d0 /dev/rdsk/c4t2d0
disk 9 8/12.8.0.255.0.2.1 sdisk CLAIMED DEVICE LSI INF-01-00
/dev/dsk/c4t2d1 /dev/rdsk/c4t2d1
disk 10 8/12.8.0.255.0.2.7 sdisk CLAIMED DEVICE LSI Universal Xport
/dev/dsk/c4t2d7 /dev/rdsk/c4t2d7

The paths that end in .0 should be the 100GB array and the ones that end in .1 should be the 67GB array. Also, something that's not directly connected, what is the Universal Xport? What is this device? It's not *actually* another disk, is it? Well, what do I do if the hardware paths are not identical on each system?

Thanks again,
Melissa

Re: Oop! More volume group problems ...

Joel Shank — Tue, 19 Jun 2001 16:43:02 GMT

Melissa

You need to specify the physical disk devices that are assigned to the volume groups you are trying to import. this means that you need to know which devices on DATA map to the SAME devices on LORE. For example, if vg67 is on c4t0d0 on lore and maps to c4t2d0 on data, then your import would look like this (on data):
vgimport vg67 /dev/dsk/c4t2d0

HTH -- jls