It seems you do not really understand how a HACMP cluster works, so a few words for clarification. Bear with me if this is already known. Also note that i will leave out a lot of details as i can't write a complete PowerHA documentation here.
OK, let us start with the central term in HACMP, which is "resource group". What is it?
Look at an application, say, a database: for it to run you first need some file systems, where the DB files are stored. Then you need some processes (the DB process(es) running - basically the application has to be started. Finally you need an IP address under which clients from outside can connect to the database and use its services.
Exactly these three components - file systems, (started) processes and an IP address is what a "resource group" consists of.
File systems: one or more volume groups go into a resource group. When a resource group goes active all these VGs are activated on one cluster node and all the file systems in it are mounted there. In case of a resource group move the FSs are unmounted, the VGs are deactivated on the node, then activated on another node and all the FSs mounted there. HACMP does this itself for all the VGs defined in a resource group.
Processes: for each resource group there is a so-called "application monitor", a collection of a start- and a stop-script. Whenever a resource group is deactivated the stop script is executed. It should make sure the application is down, so that afterwards the file systems can be unmounted. When a RG is activated its start script is executed and should start the application. These start-/stop-scripts are provided by you and are simple shell scripts so it is easy to integrate all sorts of applications into HACMP.
Finally the IP address: every RG can have one (or several, but typically one) "service addresses". These service addresses are normal IP addresses which are added to a certain network adapter when the RG starts and remove when it stops. Technically they are IP aliases which are added to network interfaces.
An RG-start now works like this: the VGs are acquired ( varyon ), the filesystems are mounted, then the start-script of the application monitor is executed. finally the service-IP-address is put onto a network interface and the clients can use it to connect to the application. If the RG is moved, the service-IP is taken down, the stop-part of the application monitor stops the application, FS are unmounted and VGs deactivated, then the start-procedure is done on another node. The client will notice that the service-IP is (after a short time) available again. If a node crashes the same as in an RG-move hapeens, only the stop-part is skipped (obviously). HACMP can handle that but you need to take care of the application part in your start-script eventually, like a cleanup in a DB in case of a sudden system shutdown, etc..
When your RG is in the state "UNMANAGED" it means that its FSs, processes, etc. are there, but not started via HACMP. Stop it using HACMP so that it becomes "OFFLINE" (meaning: not active on any node), then bring it online again. Now it should be in status "ONLINE" on a certain node. You can move it to another node from there.
A word about CSPOC: you should absolutely, positively use these commands, not the normal commands, to do LVM management. The reason is that for all the components i talked about above to work all the cluster nodes needs to share consistent information about how the parts of the resoufrce groups look like. The cluster commands do the same as the normal commands, but they distribute the changed information to the other nodes too. THIS IS VITAL!
You can get away with doing LVM operations if you do a "learning import" on the passive node afterwards, eventually a cluster synchronisation too. But why take such risks if there are commands to do exactly this without any risks involved at all?
I hope this helps.
bakunin