lvm import failed

[Greg Butler]

I am trying to import a vg and I get the following message:
Question: How do I get rid of these devices so they don't conflict ?

# vgimport -s -m /dba/san/scripts/vg01cis.map /dev/vg01cis
Verification of unique LVM disk id on each disk in the volume group
/dev/vg01cis failed.
Following are the sets of disks having identical LVM disk id
/dev/dsk/c8t3d3 /dev/dsk/c10t15d7 /dev/dsk/c8t15d7
/dev/dsk/c8t3d4 /dev/dsk/c13t0d0 /dev/dsk/c12t0d0
/dev/dsk/c8t3d5 /dev/dsk/c13t0d1 /dev/dsk/c12t0d1
/dev/dsk/c8t3d6 /dev/dsk/c13t0d2 /dev/dsk/c12t0d2
/dev/dsk/c8t3d7 /dev/dsk/c13t0d3 /dev/dsk/c12t0d3
/dev/dsk/c8t4d0 /dev/dsk/c13t0d4 /dev/dsk/c12t0d4
/dev/dsk/c8t4d1 /dev/dsk/c13t0d5 /dev/dsk/c12t0d5
/dev/dsk/c8t4d2 /dev/dsk/c13t0d6 /dev/dsk/c12t0d6
/dev/dsk/c8t4d3 /dev/dsk/c13t0d7 /dev/dsk/c12t0d7
/dev/dsk/c8t4d4 /dev/dsk/c13t1d0 /dev/dsk/c12t1d0
/dev/dsk/c8t4d5 /dev/dsk/c13t1d1 /dev/dsk/c12t1d1

[John Poff]

Hi,

You might need to do a 'vgchgid' on the disks you are importing so that they have a unique VGID on them. Are those other disks just copies of the disks you are importing?

JP

[Ross Zubritski]

John is correct. Do these volumes "belong" to the host inwhich you are trying to do the import?

Regards,

RZ

[Greg Butler]

I am doing the import to a different host in a san environment so I can business copy, bring the database back up on the parent and backup the bc luns offline. It looks like there have been a couple of exports and the devices are still there. I don't need the exports. The devices that conflict are associated with the vgexports (looked in sam).
Any suggestions ? I just need to cleanup all those device files so I can re vgimport but am unsure if that is the right approach...

[Stuart Abramson_2 · Accepted solution]

Greg:

The above answers are correct. A "vgchgid" is required.

Here is what this means:

In the VGDA/VGRA/header of every PV in a VG, the VGID is written. In that way, vgimport can scan the disks and see which PVs belong to a VG. When you do a vgimport -s he is reading the VGID and comparing to the mapfile (which has the VGID as the 1st line. Looks like this:

# cat mapfile
VGID 25b046553edc24d0
1 lvol01 )

If you make a business copy of a PV, or try to present and then vgimport a PV on a server on which the primary VG is already presented/activated, then you will get VGID duplication, which is what you are getting.

That's when "vgchgid" is required.

Did I explain that clearly?

[Stuart Abramson_2]

Two more things:

1. vgchgid in Business Copy:
When doing a Business Copy or EMC BCV split mount, you CAN'T USE vgimport -s.

Because the "vgchgid" is going to change the VGID, you don't know what to search for; So the vgimport -s will fail.

So, if a "vgchgid" is required, like in Business Copy or just plain presenting the same VG twice to the same server (which isn't all that smart!), you must vgimport and specify device file names.

2. vgchgid in MC/ServiceGuard:
In a cluster, the cluster software notes ALL the VGs on all the nodes, and won't allow the same VG to be mounted at the same time on another node. So, a "vgchgid" is required there, for Business Copy volumes in MC/ServiceGuard clusters, even though the nodes are different.

[Greg Butler]

Very clear thanks.
I understand the need for uniqueness if I was trying to importvg to the same server however,
I have a volume group on server "cis" called vg01cis that consists of pv's in the san and have been secured via the security file so only that server can see those luns. From another server (cddsrvr) where the san manager software resides I created bc luns and secured them so that only the second server can see them. Now I want to importvg from the mapfile generated on the cis server to the cddsrvr where the parent luns are not presented and to me there should be no conflict even it the vgid is the same. Does this make sense ? Thanks for your patience.

[Greg Satchfield]

Greg,

It sounds like you have device files you need to remove. If that is the case, look at the 'rmsf' command. Ex. 'rmsf -H ' removes all of the devices on that hardware path. I've got a SAN (EMC - doh!!) as well and have to do this quite often.

Good luck...