vgchange: Couldn't deactivate volume group Device busy

[Arockia Jegan]

I'm trying to deactivate (vgchange -a n /dev/vgxx) a volume group and getting the following message,

vgchange: Couldn't deactivate volume group Device busy

Before running this command I unmounted all the file systems under that volume group.

Gone through the forum , but couldn't find a solution. The volume group contains EMC meta volumes.

[harry d brown jr]

Do you have "lsof" ??

You could shut down and boot into single user mode, but that's probably not what you want to do.



live free or die
harry

[Arockia Jegan]

Yes I have lsof. I already run the lsof and couldn't find any files opened on that volume group.

Unfortunately I can't reboot the box.

[harry d brown jr]

What does vgdisplay -v vgxx display?

Is there paging on any lv's within this vg?

Any RAW lv's ??

live free or die
harry

[Arockia Jegan]

Here's the output of vgdisplay. There are no RAW logical volumes.

# vgdisplay -v vgbcv07
--- Volume groups ---
VG Name /dev/vgbcv07
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 2
Open LV 2
Max PV 16
Cur PV 2
Act PV 2
Max PE per PV 3596
VGDA 4
PE Size (Mbytes) 4
Total PE 7190
Alloc PE 7190
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vgbcv07/lvol1
LV Status available/syncd
LV Size (Mbytes) 14380
Current LE 3595
Allocated PE 3595
Used PV 1

LV Name /dev/vgbcv07/lvol2
LV Status available/syncd
LV Size (Mbytes) 14380
Current LE 3595
Allocated PE 3595
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c6t3d3
PV Status available
Total PE 3595
Free PE 0
Autoswitch On

PV Name /dev/dsk/c6t3d2
PV Status available
Total PE 3595
Free PE 0
Autoswitch On

[S.K. Chan]

Just quickly check is you got any duplicate minor number.
# ll /dev/vgbcv07/group
==> Take note of it's minor number.
# ll /dev/vg*/group | grep

[harry d brown jr]

I'm wondering if you have a "corrupted" /etc/lvmtab file.

If you rename it (mv /etc/lvmtab /etc/orig_lvmtab), and please rename it, not remove it, and then run "vgscan -v".

Is this a BCV volume? If it is, is it write enabled?

live free or die
harry

[harry d brown jr]

SK,

Good point!

harry

[Arockia Jegan]

I'm just wondering whether the "vgscan -v" command will make any impact. Will that craete any problem?

[harry d brown jr]

I've never had it "destroy" anything. The lvmtab file is like a quick index into the structure of the vg's & lv's.

I have rebuilt the lvmtab file many times because I had messed up LV/VG's

live free or die
harry

[Edgardo M. Yumul]

Are those two logical volumes used for file systems or is it raw lvs? Coz if there are raw lvs, your application might still be using it. The best way is to shutdown to single user mode to deactive the volume group.

[Ceesjan van Hattum]

Hi Arockia,
Please be so kind to continue or evaluate this discussions. There are some interesting comments of our fellow friends. I have similar problems and would like to learn from the discussion.
Regards,
Ceesjan

[Juan Manuel López]

I think you can use " fuser " command to find the process running over your vg. Try it.

Juanma.

[Tim D Fulford]

Are/were any of the logical volumes used for swap? If so, they cannot be deactivated.

just my 0.02??? worth

Tim

[IT Response]

Check for duplicate minor numbers on the disks

[Rajasekhar Raman]

Have any of the logical volumes been used by a database. If so the database server needs to release these devices by either removing references to these logical volumes in the database. We have had similar situations with Sybase, when a device (logical volume) is dropped, but cannot be removed ( or the VG cannot be deactivated ) because Sybase still seems to have some control. Restart the DB server after dropping the devices releases the logical volumes.

I cannot think of any other scenario under which this occurs. Maybe you have some application which uses these devices..Just check.

[Elif Gius]

Hi,

we hava had a similar problem.Sometimes one user is in the directory, so try "fuser -uc" to check this.

Another time a process had a lock on the filesystem, you can check this with "lsof |grep vgNAME". Sometimes one cronjob or a backup process is stil working on it.

I hope you find a solution.

[Gnegel Weindl]

Hi
This is mostly guesswork from systems I've had with the same problem, but
since you seem to be running EMC BCV this is probalby what has happend:
You had the vg active but established the disks on the emc side.The system seems to remember the old vg structure and since that has changed it can't write the info back and complete the vgchange. So what might help is splitting the disks again and trying a vgcfgrestore (always asuming you've got a new .conf version in /etc/lvconf directory)
then the system might (big might) accept the disks again and let you do a vgchange -a n
again. The same effect can be seen if you create a vg on one machine umount the fs but forget to deactivate it, then fire up the same vg on a different machine using Sevice Guard (vgchange -c y /vgchange -a e ). I haven't found any sure way to clear the status appart from a reboot, anybody else found a way?
nigel@devoss.de

[Dietmar Konermann]

Just a short notice if you are on 11.11 or on 11.00 with VxFS 3.3. There is a known problem where a failed mount attempt may leave the lvol device open... which causes vgchange -a n to fail with EBUSY. Only a reboot will clear in this situation, since you will never get this device closed otherwise.

JAGae05460 for 11.00, fix PHKL_27212 or later
JAGae04912 for 11.11, fix PHKL_25885 or later


Best regards...
Dietmar.

[Q4you]

Just try this if you stillhave problem..

vgchange -q n -a n

Q-4-u

[Chip M. Coon]

has this issue been resolved. I have the same problem, and I am using EMC devices, but my BCV's are not attached to the disk in the filesystem that can't be unmounted. fuser and lsof do not show any active process on this dev or mount point. Any suggestions?

[Tom Danzig]

I think Dietmar has the answer. I remember a situation a few months back where an admin tried to mount the same logical volume twice on different dir's. It fail the second time of course, however, a bug in LVM hung the logical volume thinking it was still mounted when it was not.

There is a patch out there to correct it.

[Muhammad L Durrani]

Well I had the same problem. I unmounted the directory mounted on lvol and now I could deactivate the vg.

[generic_1]

Only saw one mention of fuser. This is anoter good util to see why a disk is busy. It is also easy to be sitting in the filesystem you are trying to unmount :) which is an obvious problem, but easy to do. I hope your problem was fixed.

[hari jayaram_1]

Hi,

Not sure if your problem is resolved. Could you please run fuser -u on all the raw logical volumes and volume group.