lvmtab and vgscan - unmatched PV to VG

[Norman Dignard]

I had a bad lvmtab in that it was vgdisplay on boot was complaining about a /dev/nas/group being bad. (This was created when adding external disk array but subsequently dropped).

I moved the lvmtab out of the way and ran vgscan -a to recreate it. vgscan completes but reports that its unamte to match a physical volume to a volume group and run vgimport to complete the process on /dev/dsk/c2t2d0.

Looking at the old lvmtab file it had an entry for /dev/dsk/c2t2d0 but not the new lvmtab file. Ioscan sees it and SAM lists it as swap space. (The entire disk was assigned as system swap on inital setup.)

I don't believe that a PV/VG pair was created for system swap space.

Do I have a problem here and how do I fix it?

Regards
Norm



Is this a

[Olivier Masse]

HP has a lot of troubleshooting guides for LVM problems in their ITRC. Assuming you have access to it, try pasting your exact eror message and maybe you'll find a howto.

[RAC_1]

If current configuration says, this is swap disk, then you can do anything. Check that. swapinfo -mat
Does the lvol that swapinfo gives, lie on this disk?? Also, if it is the case, then disk is already a part of some vg.

[Pete Randall]

Norm,

When I've seen this message in the past, I've been able to do exactly what it says: run vgimport. However, I'm confused by your case. You say SAM currently sees this device as swap space? In a separate VG or as an lvol in vg00? Exactly what does SAM say?


Pete

[Norman Dignard]

running swapinfo -mat returns:
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2
dev 17366 0 17366 0% 0 - 1 /dev/dsk/c2t0d0
reserve - 661 -661
memory 6328 406 5922 6%
total 27790 1067 26723 4% - 0 -

In Sam -> SWAP I see
/dev/vg00/lvol2 ((which using hw paths 0/0/1/1.2.0 and 0/0/2/0.2.0 (disks /dev/dsk/c1t2d0 and its mirror /dev/dsk/c2t2d0)) and
/dev/dsk/c2t0d0 ((using 0/0/2/0.0.0 (disk /dev/dsk/c2t0d0))

RAC - I'm not sure what you mean by does the lvol lie on the disk that swapinfo gives. There is no lvol nor go associated with this disk. The swap space was created NOT using LVM.

This is where I'm a little confused/lost.

[RAC_1]

You have that disk set as swap space, you do not need to do anything. Check lvlnboot and check if eberything is ok.

[Norman Dignard]

I was thinking that. Its a little strange however that the original lvmtab file had a entry for this disk. And ideas on that?

[Sameer_Nirmal]

It is quite sure that the disk c2t0d0 was used with LVM before and was attached with that nas VG as it was in old lvmtab. Subsequently, as you said you dropped that vg & you might have done vgreduce to remove the that disk. But remember the disk still has got the LVM PV structure on it. So LVM can detec it through vgscan. Thats why you are getting that un-match error. I think using that disk as swap didn't remove the LVM structure from it.

There is nothing wrong and you can simply ignore the error.

Was there any specific reason to keep non-LVM disk for swap?

[Devender Khatana]

Hi,

The error in normal as your system has one unused disk with LVOL structure on it. vgscan always reports this message for unused disks having LVM structure on them. You can get rid of this by doing a pvremove on that disk.

Allthough as indicated above it is normal and is a expected behaviour.

HTH,
Devender

[Norman Dignard]

To answer a few questions - the swap disk was setup via SAM. The box has 9GB RAM so we assigned 18GB disk for swap. The LVM structure was either on the swap disk (savanged from another host) or added as part of the setup. I can't say which.

As for using a non LVM disk for swap - there was no specific reason to sue LVM or not. Is there an advantage to use LVM/not use for swap?

[Sameer_Nirmal · Accepted solution]

The advantage of having LVM disk is ease in managebility of disk space. Since you have already configured other disk as LVM disk for swap , it is good idea to have another as LVM disk only instead of non-LVM disk.

If you are using non-LVM disk , then you have to take it in account always alongwith all other LVM disks. Because you won't see this disk in LVM configuration , it may be confusing for someone if he only looks at LVM configuration.

[Norman Dignard]

Noted as a known behavior for swap disks with LVM structure