Package problem - missing LUNs

[No idea what I'm doing]

Hey, guys. I have a problem with one of my packages which is a Database package. Let's call the volume group VG10. Right now VG10 consists of the following filesystems:

/a

/b

/c

/d

/e

There is one database across /a, /b and /c. And there is one database across /d and /e. The first database has been retired and we've been okay to reclaim the space from it. The problem is that two LUNs have been unintentionally remove from VG10. So if it was built with 7 LUNs, it only has 5 in it right now. Fortunately, none of the physical extents for the database on /d and /e were on these two LUNs that were removed.

My problem is that I have to bring down this package soon and I'm going to have problems if two of those LUNs are missing. I believe I can do a vgreduce -f on those two missing PVs and get them out of the volume group. Assuming I do this and I shut the package down, will the volume group still be able to be activated when I try to start the package back up and it tries to activate the volume group?

I have also considered unmounting /a, /b and /c and then deleting the logical volumes. Then I can us pvmove to get everything else on one or two LUNs and vgreduce out the others. But wouldn't unmounting /a, /b or /c result in the package shutting down automatically if the package is up and running? That is considered a trigger for the package failing, correct?

I'm trying to figure out the best way to get this fixed and this one has me kind of stumped for right now.

Thanks!

[Matti_Kurkela]

> But wouldn't unmounting /a, /b or /c result in the package shutting down automatically if the package is up and running?

If the package configuration includes either an EMS monitor specification or a service script that monitors the presence of the mounted filesystems, then yes. But such monitoring is optional: it may or may not have been configured... and if the package did not fail when the two LUNs were accidentally removed, I think the monitoring either does not exist or is less strict than expected.

> Assuming I do this and I shut the package down, will the volume group still be able to be activated when I try to start the package back up and it tries to activate the volume group?

Before restarting the package, you should remove all references to /a, /b and /c from the package configuration (if they are mentioned there) and the package control script (if it exists, i.e. you're using an older version of Serviceguard or a modern version with a legacy package configuration style).

The package control script can be edited at any time, but you must manually copy the updated script to all the cluster nodes. The package configuration file must be submitted to the cluster with the cmapplyconf command, but it will automatically transmit the new package configuration to all the cluster nodes.

After removing the missing LVs/PVs from the VG, you should also create a new map file for the VG (vgexport -p -s -m vg10.map) on the node you did the VG modifications, and then export+re-import the VG on the other node(s) using the new map file. This is to bring the VG configuration to the same state in the other cluster nodes: you must do it any time you add or remove PVs or LVs to/from a clustered  LVM VG.