Adding a VG

[Mike Smith_2]

I've got a machine (not the same one as in my other post) that has 2 paths to an EMC array. It currently has a VG and lvol assigned to those volumes.

I'm trying to allocate more volumes to make another VG and lvol, but when I do, HPUX says those new volumes are part of an exported VG and that I should import them first.

Although it's possible that they might contain LVM data as they were probably assigned to a different server at one time, they shouldn't be a part of an exported VG on this server.

What is on them now is irrelevant, how does one make them contain no data so that I can use them?

I tried pvremove, but that's when it complains about the prior vg and suggests vgimport. Is vgexport data (even if used without a mapfile) kept on those volumes, or on the server exported from?

[Denver Osborn · Accepted solution]

So you are attempting to allocate more PV's to a VG and it complains that they have LVM data on them?

As long as the PV's are not in use (listed in lvmtab or another system using the array) It is safe to pvcreate them. Since they may have belonged to a vg at one time you'll have to force it.

# pvcreate -f /dev/rdsk/c?t?d?

Only do this if you know they arent in use by another vg and are available to use. Are the PV's alternate path to pv's being used?

[Mike Smith_2]

These are volumes that MAY have been assigned to another server at one point, but aren't any longer. So, I know these volumes don't have any ties to any servers currently, and I'm trying to create a separate VG and lvol using them.

I'll try the pvcreate -f thing and see if that clears them out.

[Rita C Workman]

I agree with Denver about the possibility of doing a pvcreate <-f>......but I have one question/caution.
This other box that is connected to your EMC array.....is this EMC array also connected to your other boxes????? Are these boxes part of a MC/SG environment?

Although normally, SG and EMC will create a report that lists the disk address uniformly....I have seen it (..in fact I have this situation..) where you can have the EMC connected to multiple boxes and the same drive appears as /dev/dsk/c1t2d0 on one box but the same (..repeat the same disk) on the other box appears as c4t2d0.
This can get confusing and is very easy to 'make a major blunder' with.

Just a thought,

[Tim Malnati]

If this is the same EMC unit that is involved in your other post, I would be VERY reluctant to change anything until the other problem is resolved. If the EMC is somehow confused about its internal mapping, you may be inviting disaster by forcing anything here. Rita's comment regarding dual mapping has a lot of merit too. I've seen the same thing.

[Mike Smith_2]

No ServiceGuard here. It is the same EMC box as the other box is attached to, but each box has it's dedicated paths and volume mapping. We don't have any volumes mapped to more than one machine, and they're mapped to both paths of their respective machines.

The possibility of stepping on another machine's mapping was one of the first things I checked out. The units I'm trying to add to this box are specifically listed as unassigned and their unit numbers don't match any of the missing ones (from HPUX's view) on the other box.

[Mike Smith_2]

No ServiceGuard here. It is the same EMC box as the other box is attached to, but each box has it's dedicated paths and volume mapping. We don't have any volumes mapped to more than one machine, and they're mapped to both paths of their respective machines.

The possibility of stepping on another machine's mapping was one of the first things I checked out. The units I'm trying to add to this box are specifically listed as unassigned and their unit numbers don't match any of the missing ones (from HPUX's view) on the other box.

[Steve Sauve]

Don't know if this applies, but I worked on a system once that had an EMC disk array on it. When I looked (in SAM) for PV's to add to a VG I saw not only the available ones, but also the mirrors of the used PV's. The explaination was that since the EMC was doing the mirroring, SAM didn't see those PV's as in use. Obviously though I didn't want to add those to a VG :)

Hope this helps,
Steve

[John Palmer]

Would it be worth doing 'vgscan' in order to get the voume group information from these disks and importing them. You could then activate the group(s) read only (vgchange -a r from memory), try to mount filesystems and checking file dates etc.

This would perhaps give you confidence that the data was really 'old'. You only then have to deactivate the group(s) and vgexport them to get rid.

[Mike Smith_2]

Well, If I attach them, and do a vgscan -pv, I get this....

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/c0t6d0

Only problem is, vgimport on WHAT? Why would I want to import a VG that's never been there before?

When I tried pvremove /dev/rdsk/c0t6d0, I got this:

The Physical Volume /dev/rdsk/c0t6d0 belongs to an exported Volume Group.
Couldn't remove /dev/rdsk/c0t6d0.

Where would it list exported volume groups?

[James R. Ferguson]

Mike:

I agree with Tim & John. I'd be very, very cautious about a forced pvcreate at this time. I have read your companion post too. In some senses, it appears that EMC "knows" how to map your disks and has a correct view of who owns what. Rather, it appears that LVM (on your other server, in your other post) has a screwy view.

You don't mention HP release and patch levels. Do you have a recent set of LVM cumulative patches in place?

Has anyone been doing any LVM maintenance lately? Any cables been replaced or are no longer properly terminated?

...JRF...

[Mike Smith_2]

Oh, sorry... HPUX 11.0, and March '00 Support plus disk applied.

No recent cable work. In fact nothing changed on either box (or the EMC for that matter) for some time.

On the one that LVM can't see it's volumes, I just stumbled accross it when sar -d wouldn't pickup activity on the devices assigned to those data volumes.

The other box, I was trying to add another VG and assign it's volumes when I started getting the previous LVM data messages and it refused to add them.

Again, the volume IDs for the volumes that don't show up on the one box and won't add for the other are not the same. It doesn't rule out an EMC problem, but there is no indication that there is one.

[Mike Smith_2]

Well, With a bit of help from this forum, I fixed this machine. I checked the EMC mapping and the lvmtabs from the other servers. SInce they were not mapped to any other box, I did the pvcreate -f on them. That seemed to do it and it's working fine now.

Thanks all.