I recently received a request to reclaim hard disks and IP addresses within an AIX system(s). THe file systems are no longer in use and the client has indicated that it is OK to remove them and reclaim the disks and release the IP's. Now, since the file systems belong to a Volume group I am assuming I would need to take the VG offline and remove the file systems via smitty. Since the disk belongs to a SAN, I would need to remove the disk definition from ODM and erase the path. What I am looking for is an idea of what steps to follow in order to accomplish the task. Any help would be greatly appreciated.
AIX is good because you cannot remove anything that the OS believes is in use so it protects itself. You can detach them at the SAN end, but that will cause hardware alerts.
Are you relinquishing all IP addresses? Is this part of a cluster perhaps?
I presume you mean that you want to reclaim the disks/LUNs for use on other servers/partitions so:
You cannot remove these safely from AIX without them being removed from the relevant volume group.
You cannot remove them from the volume group unless they are empty (no logical volumes)
You cannot remove the logical volumes if they are in use as either raw devices (such as for a database) or as formatted and mounted filesystems.
You cannot unmount filesystems if they are in use, i.e. open files or any process with their current directory within the tree.
Before going through the process to unwind them, will anything be left of the server at the end of this or is it being turned off? If so, shut it down and use the SAN to detach/dis-associate the LUNs from the client AIX node (or whatever terminology your SAN uses) To reuse the server at a later date, you would be best to re-install over the root volume group so that it doesn't try to use devices that have been removed or use IP addresses that may have been reallocated elsewhere.
If you need to do a partial removal, it would be helpful to know what we're dealing with. Can you share the output (pasted in CODE tags) from the following:-
oslevel -s
df
lsvg
lsvg -p each volume group in turn
lsvg -l each volume group in turn
lspv
This is the disk in question. THe command resulted in over 100 disks being displayed.
lspv
hdisk9 <disk_id> <vg_name> active
as for the rest of the outputs you requested, I would need client permission to post it. I can say that for this server, there are 4 LV's and they all belong to on VG. Hdisk9 is the only disk belonging to this VG. There are 3 servers in all, so whatever i do on one can be replicated for the others.
<vg_name>:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
lv_name jfs2log 1 1 1 open/syncd
lv_name jfs2 7 7 1 open/syncd
lv_name jfs2 64 64 1 closed/syncd
lv_name jfs2 223 223 1 open/syncd
lv_name jfs2 6 6 1 open/syncd
lv_name jfs2 6 6 1 open/syncd
As for the IP, the file systems are databases that have been decommissioned, so there is 1 IP related to the lv's.
---------- Post updated at 09:56 AM ---------- Previous update was at 09:54 AM ----------
Also Robin, this is only an FS, the server will remain in service as it is being used for other things as well. So this is a partial removal.
Can we have the output from the other commands too please? They are:-
df
lsvg -p each volume group in turn
Please wrap the output in CODE tags, not ICODE tags. Use the icon that is a white square and has black "co" over "de" on it, rather than the </> one, thanks. I've changed them in your post.
I'm a bit confused by this:-
I don't understand how an IP relates to a filesystem. If there are multiple IP addresses offered and there is no clustering in use, then you can just remove them. Can you additionally show us the output from:-
In AIX all (really all) filesystems are managed by a logical volume manager. As a rule of thumb you have:
one or more filesystems belong to a volume group
one or more disks provide the space for this volume group (each disk belongs to exactly one VG)
If a system is set up sensibly volume groups build logical groups of FSes, i.e. all FSes for one application are in one VG. Therefore you most probably want to remove all FSes from one VG.
If so:
lsvg -p to get the disks belonging to the VG ( man lsvg ). Write these down.
umount all the FSes in question.
varyoff the VG after unmounting all the FSes in it. ( man varyoffvg )
export the VG ( man exportvg )
The last command will remove the FS definitions from /etc/filesystems as well as the VG. Finally you can remove the disk(s) which (formerly) belonged to the VG:
rmdev -Rdl <disk> ( man rmdev )
Afterwards remove the zoning/LUNs and it might be necessary to remove the disks from the VIOS too (if they are vSCSI).
Finally do a cfgmgr on teh LPAR to make sure the disks are out of the system cleanly (if some artefacts are configured again you know you have more work to do).
Note, that there was a lot of assuming going on when writing this. In principle the procedure will cover the most common cases but you might have to change details for i.e. EMC SAN running PowerPath drivers, etc., so as long as we have no detailed description of your system we can#t tell you in all detail what to do and how.
@rbatte1, The request from my customer was that the database was decommissioned on three servers(LPARS) and that it was ok to remove the file systems (LV's) and reclaim the disks, which belong to a SAN. Because these disks belong to a SAN there is a cost to them, thus the reason for reclaiming them. Also included in the request was to reclaim one DNS and IP per server as it too was no longer needed. What the IP was used for, I do not know.
@bakunin - The setup on all three servers is that the list of 4 or 5 LV's belong to one volume group and each VG has 1 disk assigned to it with the expception of one VG, it has 2 disks. From the looks of it, the general how-to you posted is fine. I have a good direction I can follow. All I really need is concerning removing the IP.
If the IP address was offered as part of a cluster, then that makes a difference. Was this server perhaps part of an Oracle RAC or IBM PowerHA cluster other something similar?
Can we see the output from ifconfig -a ?
The content of /etc/hosts might be useful too.
We might need to look at the output from other network commands to be sure, but we'll get to that later.
OK, i concentrated on one part only in my first posting.
I share the underlying assumption of my dear colleague rbatte1: the IP was perhaps the service IP address over which the DB service was known to the outside world. This is commonly the case with cluster-setups (either HACMP/SystemMirror/PowerHA or Oracle RAC or even other cluster systems as well).
If you have any cluster on this system: before either removing the VGs or the IP you need to deconfigure the "resource group" (that is the HACMP term, whatever it is called in your cluster). Such a resource group usually consists of:
a service IP address
one or more VGs/filesystems
start-/stop-script(s)
optionally monitoring scripts to check if the application still runs
However, if this is a non-cluster (again: really make sure this is the case, you can easily render the whole system unusable by deleting VGs which are part of a cluster) and you only need to delete the IP service:
check on which network adapter the IP is configured and if this network adapter also serves other IP addresses
check wehter there are special routing entries for that IP ( netstat -rn )
check wether the corresponding name is provided by: DNS/NIS/hostfiles/whatever
check the type of the network adapter if planning to remove it (virtual/physical).
Only then you start to remove the IP from service:
deconfigure the IP and the associated routing (if any) from the network adapter and the system (if unsure how: use the SMIT panels, it will deal with the rather intricate ODM handiwork for you)
i suggest to wait for one or two days then,maybe there are (unknown) services provided over the IP address which you would become aware now from the complaints
remove the IP definition from whatever name system (see above: NIS, DNS, ...) it is configured in
if the network adapter on which the IP ran is not used any more you can deconfigure it: rmdev
if you deconfigured the network adapter and it was virtual: remove the definition from the LPAR profile and the VIOS(es).
if you want to be super-clean: get a downtime and, after changing the LPAR profile, shut the LPAR down (to "halt", not just reboot), then power it up again. It should come up without the adapter in question.
So, this is a rough overview what it entails. The real work is just a few minutes worth, but planning and double-checking is vital.
You will also note that you will have to acquaint yourself with some concepts of IBMs virtualisation to understand what you are doing. I'd like to emphasize the point: TAKE THE TIME to do so! It is quite easy to make yourself rather prominent within a company rather quickly if this is an important system and you fumble there. This is not rocket science, but you should know what you are doing when you do it.
