AIX

You won't need alt_disk_copy or alt_disk_install as far as i know. You can mirror the rootvg and then unmirror it, just like the IBM engineer advised you to do.

If you can't afford to risk the machine i suggest you follow this advice and create a spare mirror of the rootvg disk(s) as a safety device. What i said about near-production conditions is true but an ideal: one has to make do with what one has got and what one can afford.

I hope this helps.

bakunin

Moderative Postscriptum BEGIN
If you still have questions ask them here and I (and everybody else) will be glad to answer them: the goal of this board is to create a knowledge base for everyone and when i answer your questions i will not only help you but hopefully everybody else with the same or a similar problem and the skill to use our (quite user-friendly) search engine. If i would tell you the same in a chatroom it would be wasted insofar as nobody else would have the possibility to benefit from it. I hope you understand that.
Moderative Postscriptum END

Hi bakunin,

Thanks alot for the info and I'm very sorry to ask you to talk privately. It is not my intention. Just to ask, is this the steps to do this:

1.) unmirrorvg rootvg hdisk1
2.) reducevg rootvg hdisk1
3.) do a mksysb backup
4.) bootlist -m normal hdisk1
5.) bosboot -a hdisk0
6.) bosboot -a hdisk1
7.) nim_bosinst on NIM server
8.) System will reboot and point the boot device to ethernet
9.) install on hdisk1

The system will boot and hdisk1, bring up HA and test. If everything okay how can I remirror back? I actually don't know how to make the client boot from nim. I already checked that there is /tftpboot in place and that /etc/bootptab already have the client IP addresses. Please note that NIM was previously used to install the base OS. But I have never really done this before. Thanks.

I am not trying to take over here, bakunin is doing a fine job but I just wanted to mention that on my NIM server when you set up a mksysb install to a client the "Initiate reboot and installation now?" option is defaulted to "yes". If I misunderstood the task being performed here I beg for your forgiveness.

Hi jurred1,

Thanks for the response. Yes, i saw this option when I do a smitty nim_bosinst. I am to try it later. I think the client should reboot by itself and boot thru network and in SMS. If my previous resource document is correct. I am doing this later and cross-fingered everything works fine. By then, I can only confirm the results of your suggestions. Thanks a lot.

You are welcome. The idea of this board is to OPENLY DISCUSS and everybody contributing to this is welcome. Btw., my advice is far from being perfect, see below.

Sorry for answering sloppily before: yes, you can initiate the reboot from the NIM server provided that the NIM client fileset is already installed on the client. You have to start up to the POST-menu and enter the IP address of the server like described above in case of some "virgin" hardware. The only thing you need to know to define a "standalone client" (NIM wording) is the MAC-address of the interface used to install it and you can find this out in the POST-menus too, so it is possible to install a system completely from scratch.

This brings me to a suggestion: if you don't want to risk your precious installation but you have some spare hardware you could get a maintainance-window, shut down the production machine (to avoid double IP addresses, etc.), install the spare hardware with the image you took (you can allocate the mksysb image to any client, not only the one it originated from) and restore there. Then test the installation, scratch your test installation and start up your production system again.

I hope this helps.

bakunin

PS: insist on getting such test hardware. It is necessary not only for such purposes but also for testing updates, regression tests, .... If it is argued that money is an issue: if the costs of such a test system do not equal the risk of interrupted service because of updates or maintainance gone awry then this risk is not all too big at all, yes? If the customer who is paying for the system isn't valueing its high availability why should you?

I think I only have one other thought. bakunin suggested installing on some spare hardware and taking down the production machine to avoid duplicate IP address after the spare hardware comes up.

I have done the same thing here but placed the spare hardware on a different VLAN than the production hardware. Setup a temp hostname in the /etc/hosts file, such as unixtest and given it an unused IP from the other VLAN. Create a new host within NIM called unixtest. Then you should be able to leave the current production up because after the install finishes on test hardware even when the production IP is placed on test hardware it will not be detected since it will be on a different VLAN.

Then you can get in through the console, HMC, etc..... to change the IP to a usable one for that VLAN. Just be cautious about crontab entries on the test machine running and doing things you don't want them to.