Quote:
Originally Posted by
Joseph Sabo
All I really need is concerning removing the IP.
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.
I hope this helps.
bakunin