はじめに
IBM のサポート文書 viosupgrade: auto attribute of rootvg is set to no post viosupgrade to alt disk に関連して、VIOS の rootvg における AUTO ON 属性 の挙動を確認しました。
具体的には、稼働中の rootvg の AUTO ON 属性を yes に設定した状態で再起動を行った際、バックアップとして保持しているディスク（altinst_rootvg や old_rootvg）が誤って自動的に varyon され、システム起動に悪影響を与えないかを実機ログベースで検証します。
検証環境と目的
- 対象: VIOS rootvg (hdisk0) と 代替ディスク (hdisk21 / hdisk17)
-
検証内容:
-
rootvg(稼働側) の AUTO ON 属性をyesに変更。 -
bootlistを切り替えて再起動を実施。 - 待機側のVG (
altinst_rootvg/old_rootvg) が「非活動状態 (inactive)」を維持しているか確認する。
-
検証結果サマリ
結論：問題ありませんでした。
稼働側の rootvg の AUTO ON 属性が yes であっても、システム起動時に待機側のVG (altinst_rootvg / old_rootvg) が勝手に varyon されることはありません。ODM上の定義も含め、待機側は正しく非活動状態を維持します。
検証詳細ログ
以下、時系列順の検証ログです。
1. 初期状態の確認
まず、現在の稼働状態を確認します。rootvg は AUTO ON が yes になっています。
$ lsvg | grep root
rootvg
altinst_rootvg
$ lspv | grep root
hdisk0 00c5ca21923baab6 rootvg active
hdisk21 00c5ca21c4bbd925 altinst_rootvg
$ lsvg rootvg | grep "AUTO ON"
ACTIVE PVs: 1 AUTO ON: yes
$ lsvg altinst_rootvg
replphyvol: Volume group must be varied on; use activatevg command.
altinst_rootvg は varyoff (inactive) 状態であり、正常です。
ODM (CuAt) レベルでaltinst_rootvgのディスクの定義を確認します。
💡 oem_setup_env とは: VIOS の制限された
padminシェルから、chvgやodmgetなど基盤 AIX の root権限で LVM/ODM コマンドを実行するために、一時的に root シェル環境 へ移行するコマンドです。
なお、oem_setup_env 内で システム構成を変更するとIBM のサポート範囲外となる場合があるため、実施には注意が必要です。
$ oem_setup_env
# odmget -q "name=altinst_rootvg" CuAt
~ 省略 ~
CuAt:
name = "altinst_rootvg"
attribute = "auto_on"
value = "n" #<--- ここが "n" (no) になっている
type = "R"
generic = "DU"
rep = "l"
nls_index = 638
ODM 定義でaltinst_rootvg の AUTO ON 属性は no であることが確認できました。
2. bootlist を変更して再起動 (boot disk切替)
起動ディスクを hdisk21 (現在の altinst_rootvg) に切り替えて再起動します。
$ bootlist -mode normal hdisk21
$ bootlist -mode normal -ls
hdisk21 blv=hd5 pathid=0
hdisk21 blv=hd5 pathid=1
hdisk21 blv=hd5 pathid=2
hdisk21 blv=hd5 pathid=3
$ shutdown -restart
3. 切り替え後の確認 (old_rootvg の確認)
再起動が完了し、hdisk21 (ここでは hdisk17 と認識) から起動しました。
(注: 当環境は viosupgrade で構成情報の変更があり hdisk のデバイス認識順序がリフレッシュされているため、元の hdisk21 が hdisk17 として再認識されています。)
元の rootvg (hdisk0) は old_rootvg として認識されています。
$ lspv | grep rootvg
hdisk0 00c5ca21923baab6 old_rootvg
hdisk17 00c5ca21c4bbd925 rootvg active
新しい稼働側の rootvg の属性を確認すると、代替ディスクからの起動後は通常通り AUTO ON: no になっています
$ lsvg rootvg | grep "AUTO ON"
ACTIVE PVs: 1 AUTO ON: no #<= ここ
最も重要なポイントである、以前 AUTO ON: yes だった old_rootvg の状態を確認します。
$ lsvg old_rootvg
replphyvol: Volume group must be varied on; use activatevg command.
old_rootvg は正常に varyoff (inactive) 状態を維持しています。
ODM (CuAt) レベルでold_rootvgのディスクの定義を確認します。
# odmget -q "name=old_rootvg" CuAt
~ 省略 ~
CuAt:
name = "old_rootvg"
attribute = "auto_on"
value = "n" #<--- ここが "n" (no) になっている
type = "R"
generic = "DU"
rep = "l"
nls_index = 638
ODM 定義でもold_rootvg の AUTO ON 属性は no であることを確認できました。
ここで、現在の稼働側 rootvg の AUTO ON 属性をあえて yes に変更します。
$ oem_setup_env
# chvg -a y rootvg
# echo $?
0
# exit
$ lsvg rootvg | grep "AUTO ON"
ACTIVE PVs: 1 AUTO ON: yes
4. 元のディスクへ切り戻し (AUTO ON=yes の検証)
AUTO ON: yes に設定した状態で、再度 bootlist を変更し、元のディスク (hdisk0) から起動します。 ここでの検証の核心は、old_rootvg (hdisk17) が勝手に varyon されないか です。
$ bootlist -mode normal hdisk0
$ shutdown -restart
5. 最終確認とODM 情報のチェック
再起動後、hdisk0 が rootvg として起動しました。
$ lspv | grep rootvg
hdisk0 00c5ca21923baab6 rootvg active
hdisk21 00c5ca21c4bbd925 altinst_rootvg
$ lsvg rootvg | grep "AUTO ON"
ACTIVE PVs: 1 AUTO ON: yes
稼働側は AUTO ON: yes を維持して起動しました。待機側の hdisk21 (altinst_rootvg) の状態を確認します。
$ lsvg altinst_rootvg
replphyvol: Volume group must be varied on; use activatevg command.
正常に varyoff 状態です。
念のため、ODM (CuAt) レベルで待機側ディスクの定義を確認します。
$ oem_setup_env
# odmget -q "name=altinst_rootvg" CuAt
~ 省略 ~
CuAt:
name = "altinst_rootvg"
attribute = "auto_on"
value = "n" #<--- ここが "n" (no) になっている
type = "R"
generic = "DU"
rep = "l"
nls_index = 638
ODM上でも altinst_rootvg の auto_on 属性は n (no) と定義されており、システム起動時に勝手に varyon される設定にはなっていないことが確認できました。
まとめ
実機検証結果より、稼働側 rootvg の AUTO ON 属性が yes であっても、待機中の VG (altinst_rootvg / old_rootvg) が起動時に自動 varyon されることはありませんでした。
これは、ディスク切り替え時、元の稼働VGの AUTO ON 属性が old_rootvg/altinst_rootvg に名称変更されると共に no に上書きされるため、と考えられます。
vios upgrade 参考
以上です。