As root on an AIX vio server, you can run /usr/ios/cli/ioscli with whatever padmin command after it that you want to execute. In this way, you can do things like create scripts:
# /usr/ios/cli/ioscli lsmap -all
Better yet, just get it into your path:
ln -s /usr/ios/cli/ioscli /usr/sbin/ioscli
A wierd but useful flag for the lsdev command is:
lsdev -Cp vhost0
Other lsdev commands are:
lsdev -Cs vtdev
lsdev -Cc virtual target
I got these from the odm:
-bash-3.00$ odmget CuDv | grep disk | tail
name = "hdiskpower24_"
PdDvLn = "virtual_target/vtdev/scdisk"
name = "hdiskpower25_"
PdDvLn = "virtual_target/vtdev/scdisk"
name = "hdiskpower26_"
PdDvLn = "virtual_target/vtdev/scdisk"
name = "hdiskpower32_"
PdDvLn = "virtual_target/vtdev/scdisk"
name = "hdiskpower35_"
PdDvLn = "virtual_target/vtdev/scdisk"
Have you tinkered with partition migration yet?
I’ve run into an issue where several VTDs were created in VIO 1.5 which offsets by 1k. When migrating to VIO 2.1, all new VTDs are offset zero, except in-use legacy VTDs. If you remove/readd, everything is reoffset, and your disks are trashed. Maybe possible to DD migrate the data.
But anyway, LPM requires a unique_id in CuAt, otherwise it gives cryptic errors. I’ve tried clobbering the disks but I don’t get a new unique_id.
PS, I like your deadbeefcafe01ness here.
-Josh
Thanks for the tip. Haven’t looked at partition migration, but we sure don’t want to trash everything. Is it safe to assume that a volume group of disks built with the zero offset could be given directly to a server and imported without a problem?
I upgraded a system from VIO 1.4.1 to 2.1 but had to install patch level 21 to get the errors fixed. I have not had any disk error since. The 2.1 upgrade would not allow me to start up any LPAR’s without this patch.
Bart