Dear Guys ..
I'm going to Upgrade one of the servers AIX 6.1
I want to stop rootvg mirror to save the mirror then upgrade to AIX 6.1 this is to help me in rollback if something goes wrong but ..
can anyone help me how to make sure that system is relay mirrored and how to know that second mirror has relay synchronized data
Please advice ..
If you are jumping from AIX5.3 to AIX6.1, then it is called migration.
Since you are saying the rootvg is mirrored, you can use one disk for migration keeping the other on current OS version.
I recommend using NIMADM (only reboot require downtime, rest can be done when the system is up).
Steps:
Break the rootvg's mirror
unmirrorvg rootvg <hdiskname>
If you still see some LV mirrored you can run
rmlvcopy <lvname> <no of copies (1)> <pvname>
Now that the rootvg is unmirrored, run
reducevg rootvg <hdiskname>
recreate the boot image (safe side)
bosboot -a -d /dev/<hdiskname>, here hdisk is the disk on which you have your rootvg
then
bootlist -m normal -o <hdiskname>
Coming to actual migration, you need
After confirming all the above and their dependencies, proceed with the below. From NIM Server run
smitty nimadm --> Perform NIM Alternate Disk Migration
* Target NIM Client [Client name] +
* NIM LPP_SOURCE resource [61_lppsource] +
* NIM SPOT resource [61_spot] +
* Target Disk(s) to install [select the empty disk]
DISK CACHE volume group name [] +
NIM IMAGE_DATA resource [] +
NIM BOSINST_DATA resource [] +
NIM EXCLUDE_FILES resource [] +
NIM INSTALLP_BUNDLE resource [] +
NIM PRE-MIGRATION SCRIPT resource [] +
NIM POST-MIGRATION SCRIPT resource [] +
Phase to execute [all] +
NFS mounting options []
Set Client bootlist to alternate disk? yes +
Reboot NIM Client when complete? no +
Verbose output? no +
Debug output? no +
ACCEPT new license agreements? yes +
, make sure you change the Accept new license agreement to yes.
It will 1st do an Alternate Disk Install and then it will do the migration.
Make sure you change the bootlist to new disk and reboot (after coordinating with other teams)
Hope this helps.
This might seem like a great way to do it, but it depends what you are starting with. Do you have a NIM server for a starter?
I think that the unmirrorvg will not split you off a copy that you can boot from later, it simply removes the mirror and leave the disk free to be re-used.
I do not beleive that you can just boot from this disk. It will be empty.
What current resources do you have? If you have 4 local disks that you can boot from (and all your data elsewhere) it might be better to make an alternate boot pair. Assuming the local disks are hdisk0-3 and hdisk0 & 1 are on one controller and hdisk2 & 3 are on another, you would be best to first spread your risk. Make the rootvg from hdisk0 & 2 for instance so you are protected from a controller failure. If you need to move disk contents from one to another, use migratepv, but be aware that this can take a long time. Additionally, you will need to recreate the boot image and correct the boot-list as stated by ibmtech
If you can do this process and it leave you two disks free, then you can use the smit panels:-
This should build an alternate boot pair that you can revert to should your upgrade/migration have undesirable effects.
After this, you should test that you can boot from the alternate pair. You will need to get into SMS during the power-on process for this.
Another simpler approach would be to create and test a mksysb backup and restore to a separate machine. You would then be able to recover to your existing server if you need to. Of course you would need hardware to test this on, although good DR service suppliers will allow you testing time for this anyway. I'm presuming that you have DR provision already? Now is a good time to test it! 
I'm hoping that I haven't scared you, and I'm open to being corrected if I'm wrong. I just don't want anyone to assume that an unmirrorvg will give you a split off boot disk.
I hope that this gives you something to consider and that it helps in your planning.
Robin
Liverpool/Blackburn
UK
Rather than alt disk install look at MultiBos.
Very easy to use! For starters, the command syntax/help.
michael@x054:[/home/michael]multibos -?
Usage multibos: Setup standby BOS.
multibos -s [-l <Device> {-a | -f <File> | -b <File>}] [-e <File>]
[-i <File>] [-L <File>] [-pntNX]
Usage multibos: Setup standby BOS using mksysb.
multibos -M <File> [-pntNX]
Usage multibos: Customization standby BOS.
multibos -c -l <Device> {-a | -f <File> | -b <File>} [-pnNX]
Usage multibos: Mount standby BOS.
multibos -m [-pnX]
Usage multibos: Unmount standby BOS.
multibos -u [-pnX]
Usage multibos: Rebuild standby BOS boot image.
multibos -B [-ntX]
Usage multibos: Launch standby BOS shell.
multibos -S [-nX]
Usage multibos: Remove standby BOS.
multibos -R [-ptX]
Flags:
-a = Update_all -N = Block bosboot
-B = Bosboot operation -n = Block cleanup
-b = Install bundle file -p = Preview only
-c = Customization operation -R = Remove operation
-e = Exclude file -S = Shell operation
-f = Fix List file -s = Setup operation
-i = image.data file -t = Block bootlist change
-L = Additional LVs file -u = Unmount operation
-l = Install device or directory -X = Expand file systems as needed
-m = Mount operation -M = Mksysb setup operation
p.s. I would not do a "migration" from AIX 5.3 to AIX 6.1 or AIX 7.1, but would try, as much as possible, to do a fresh install. Having an mksysb image and/or a copy of /etc (for user administration, many applications configuration files) on a separate server is handy.
p.p.s. alt_disk_install is still very strong, but I think of it as "old school". In other words, I may be an old dog but MultiBos is my new trick/bone!
Hope this (in in time to) helps!
:o Ah, well, some of us are at AIX 4.3.3 & 5.1 :o This is introduced at AIX 5.3, which is a shame for me.
Mind you I do have two AIX 6.1 installations that I will use this on straight away. I'm always happy to learn! 
Robin
For years the portal I manage was on AIX 4.3.3, recently moved portal to a mix of AIX 6.1 and ubuntu.
And I have an AIX 5.1 system that cannot go higher because it is rspc architecture and cannot go even to AIX 5.2
Enjoy multibos. It is very simple to use! Easier than alt_disk_install - imho.
I've had a good read, but there is nothing I've spotted on how to choose which to boot from. I presume that one would get to SMS and select it there. Has anyone actually done this? I wouldn't want to just leap in without knowing what to do and I guess neither would any other reputable system manager.
Does this affect a mksysb by the way, or does that only make an image of what is the running OS?
Thanks again,.
Robin
OK. let's get back to basics.
make a mksysb to be able to go back in case all else fails. Possible is that this mksysb image will want two disks to reinstall to. See below.
Unmirrorvg does not save a copy of rootvg - it removes it. After running the command reducevg rootvg hdiskX you will have a spare disk - hdiskX.
So, now there is a spare disk.
You could do a clean install onto hdiskX - assuming the hardware support AIX 6.1 (is it Power4 or newer?). You may be missing a lot of information from the other system - but at least you know AIX installs and runs.
So, now that you know AIX 6.1 installs - then if AIX 6.1 has the files needed to support alt_disk_install from AIX 4.3.3 then use the clone option to make the rootvg copy on hdiskX (overwriting the fresh install you just did) and then continue the process to do the migration.
If AIX 6.1 does not support alt_disk_install from 4.3.3 then you will need to make a second mksysb of the current configuration (only one disk in rootvg) and when that finishes, reboot from the mysysb image and restore to the spare hdiskX.
Now you have the same AIX installed twice (clone_copy the old slow way). Now reboot again using the AIX 6.1 media and follow the migration path to update to keep the information lost by the fresh install.
I hope this is all fairly clear - AND - that it helps! 
If you are talking about multibos (or alt_disk_install), you will change the bootlist when the system is up and running, then you reboot the system and it will boot off the upgraded/migrated version of OS.
After you had perform multibos operation, you will change the bootlist (hd5)
bootlist -m normal hdiskX blv=bos_hd5, where X=0,1,2,3 etc.., (root disk)
, this will change the bootlist to the one you just upgraded/migrated.
I have done it many times and it works, and you don't have to go to SMS menu to configure this.
I think the mksysb will take the multibos backup when they are mounted. ( Please correct if I am wrong).
My worry would be that if I am not able to boot with the upgrade done (and it's a pretty strong case to revert really) I am not at a prompt that I can update the bootlist. How would I achieve it then? I guess that there is maintenance mode from CD, but I would still need to know the value to set for blv Do we know what multibos will generate?
It does seem like a neat process, especially where physical disks are limited. Personally, I would never risk reducing to a single copy of any LV unless it's on externally protected disks (RAID SAN LUNs etc.) because sod's law could apply.
Thanks for any more information.
Robin
Say you upgraded and changed the bootlist, but for any reason the system ain't liking it, you can reverse the bootlist and reboot the system to go back to old version.
Now, to know which bootlist you booted off, you can do
bootlist -m normal -o, it will list you the current bootlist option
Here if you are seeing
blv
, as
hd5
, then you need to change the bootlist to
bos_hd5
or vice versa.
To change the bootlist you can use the syntax I mentioned in my previous posts.