Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

mksysb and volume groups

Status
Not open for further replies.

nomad1945

MIS
Oct 28, 2003
90
US
Hello:

I have 2 identical systems. One we use as a fail over, so after a mksysb from primary, I do a restore the secondary,
with nonthing plug in, no ssa disk, or networking, it normally sits with just rootvg and waiting on me to move ssa disk cables, and networking to it, its an apple to apples change.

However I notice after updating the mksysb on the secondary system, normally I thought if i do a lsvg, i would see the volume groups even though they cant be connected to yet, becuase they are not physically to disk.
is this true? or how is it I dont see them?

Thanks
Scott
 
To my understanding, yes you should get the other volume groups coz they should have been copied with the ODM of the primary system! have you tried to look into the ODM? how many disks you have defined for now? (lspv)?
 
With the secondary system it shows the 2 root disk,and the current OS, which is from the MKSYSB. In the past I thought it would show the vgs as well, even though the external disk are not connected yet.

So in the past I would power down the primary system, and the standby, move cables, reboot or power on, and the drives simple mounted sinces it is a apples to apples system and mount, however my concern is the past 2 mksysb loads look good, but a lsvg does not show the VGs, I thought they should even though the physical disk are not connected yet.

How can I check the ODM?

thanks
scott
 
Hi!

You can check lsvg -o to list VG-s in opened state (varyed on). All other VG-s should be closed, and the devices should be in defined state.

You can do magic on the ODM, but be very careful, you can do evil magic very easily. Even though the ODM classes in your interest are CuAt and CuDv. So the command to query the ODM is odmget, and if you want to tamper with, use odmdelete and odmadd as well.

--Trifo
 
What's the output of this?

odmget -q name="hdisk1" CuDv
(or the no of the disk you expect to exist)

odmget -q name="vgname" CuDv
(replace vgname with the name of your vg)

What's the output of prtconf command?

Regards,
Khalid
 
well on the disk nonthing, on the vg nonthing but a syntax
error I cant even use rootvg.

One thing though, I have doen this before with no problem.
However I am wandering if i had actually plugged in the ssa cables (the drives) right after the mksysb loaded, and when it was booting, i did notice not having the drives in, the screen display configuring for about 7 minutes, and i suppsoe if the drives were not attached at that point, it did not bring the vg to life. i just recall since i have rootvg, that the vg even though the disk are not there as of yet they should be displayed since they are in that database configuration.

i am going to have to do a couple life test to see at what point do we have to acttually connect them to this box if we had an emergecy, i simply can not recall from several months ago.

thanks

scott
 
Scott,

Maybe you should disable the auto varyon feature on the non root vg-s, thus avoiding the disk errors during boot. I think this way your disks simply remain in defined state as they are not present when cfgmgr is run. Trying to configure not present disks can be considered quite normal. But trying to vary on a vg using a disk which is not present, it can be a pain for AiX.

And finally: maybe your last mksysb failed somehow. Try to make a new image.

--Trifo
 
Very good point and thanks, but now i have a question, ..
since the prime system may and does get booted monthly due to old programming bugs, i need to have auto varyon since the reboots are done though cron, however is there a way to do a mksysb or somehow get to it to Not autovaryon?

It is very possible, I can get a work around by leaving the thing in mainteance mode until we would go to this system, which i will be scheduling some tes.

thanks
 
Since auto varyon flag can be modified runtime, you can simply set it off before backup and set back on when backup is finished. Just a few lines of scripting.

# turn off AutoVaryon on all VG-s
lsvg | grep -v rootvg | xargs -n1 chvg -a n

# create backup on your favor
mksysb blah-blah-blah

# turn on AutoVaryon on all VG-s
lsvg | grep -v rootvg | xargs -n1 chvg -a y

Or something like that.

--Trifo

 
I thank that after a mksysb restore, the vg (other than rootvg) structure were not restored ...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top