Operating System - HP-UX
1752375 Members
6203 Online
108787 Solutions
New Discussion юеВ

Re: Oop! More volume group problems ...

 
SOLVED
Go to solution
Melissa Murphy
Advisor

Oop! More volume group problems ...

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
14 REPLIES 14
Vincenzo Restuccia
Honored Contributor

Re: Oop! More volume group problems ...

Try
#mv /etc/lvmtab /etc/lvmtab.old
#vgscan -v
Melissa Murphy
Advisor

Re: Oop! More volume group problems ...

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
Vincenzo Restuccia
Honored Contributor

Re: Oop! More volume group problems ...

Christopher McCray_1
Honored Contributor

Re: Oop! More volume group problems ...

Did you by chance bind a LUN first before creating the vg? Just wanted to be sure.
It wasn't me!!!!
Melissa Murphy
Advisor

Re: Oop! More volume group problems ...

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
Christopher McCray_1
Honored Contributor

Re: Oop! More volume group problems ...

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.
It wasn't me!!!!
Melissa Murphy
Advisor

Re: Oop! More volume group problems ...

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
David Child_1
Honored Contributor

Re: Oop! More volume group problems ...

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.
Christopher McCray_1
Honored Contributor

Re: Oop! More volume group problems ...

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.
It wasn't me!!!!