NetBackupでインベントリ操作をコマンドで実行する方法


NetBackupのテープ関連操作は基本GUIから行うことで解説されている場合が多い。

CLIから行う場合の手順について確認した。

NetBackupで管理しているテープチェンジャーの確認「tpconfig -l」

NetBackupでテープチェンジャーに対する操作を行う場合、テープチェンジャーが持つ操作装置(ロボット)の番号を指定して行う。
このため、管理下にあるロボットの番号をtpconfig -lコマンドで確認する必要がある。
なお、このコマンドでは同時にそのロボット内にあるドライブについても確認出来る。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
Device Robot Drive       Robot                    Drive                Device     Second
Type     Num Index  Type DrNum Status  Comment    Name                 Path       Device Path
robot      0    -    TLD    -       -  -          -                    /dev/sg2
  drive    -    1 hcart2    1      UP  -          IBM.ULT3580-TD5.000  /dev/nst1
robot      1    -    TLD    -       -  -          -                    /dev/sg4
  drive    -    0    dlt    1  DISABL  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]#

上記結果サンプルはrobot:1として認識されているSDLT600ドライブがあるロボットはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

NetBackupで管理しているテープドライブの確認「tpconfig -d」

テープ装置単独で確認したい場合は「tpconfig -d」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -d
Id  DriveName           Type   Residence
      Drive Path                                                       Status
****************************************************************************
0   QUANTUM.SDLT600.000  dlt    TLD(1)  DRIVE=1
      /dev/nst0                                                        DISABLED
1   IBM.ULT3580-TD5.000  hcart2 TLD(0)  DRIVE=1
      /dev/nst1                                                        UP

Currently defined robotics are:
  TLD(0)     robotic path = /dev/sg2
  TLD(1)     robotic path = /dev/sg4

EMM Server = nbuserver

[root@nbuserver ~]#

上記結果サンプルはSDLT600ドライブについてはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

テープ装置のインベントリ実行確認「vmupdate -rt tld -rn ロボット番号 -recommend」

GUI操作でいうところの[Inventory Robot]-[Preview volume configuration changes]に相当するものは「vmupdate -rt tld -rn ロボット番号 -recommend」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

変更がある場合は以下の様に表示される。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
[root@nbuserver ~]#

変更がない場合は以下のようになる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Volume configuration is up-to-date with robot contents.
[root@nbuserver ~]#

テープ装置のインベントリ実行「vmupdate -rt tld -rn ロボット番号」

GUI操作でいうところの[Inventory Robot]-[Update volume configuration]に相当するものは「vmupdate -rt tld -rn ロボット番号」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
Updating volume configuration ...

Processing existing media added to or moved within the robotic library by
logically moving media as follows...
        Media ID        Slot
        ========        ====
         O502L5            3


Volume configuration successfully updated.

[root@nbuserver ~]#

NetBackupに登録されているテープメディア一覧確認「vmquery -b -a」

NetBackupの管理下にあるテープメディアを確認するには「vmquery -b -a」となる。
テープ装置外にあるメディアについては「robot type:NONE」となる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

ロボット内のテープメディア一覧確認「vmquery -b -rn ロボット番号」

指定したロボット内にあるメディアを確認するには「vmquery -b -rn ロボット番号」で確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rn 0
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

テープ装置外で保管されているテープメディア一覧「vmquery -b -rt NONE」

テープ装置外で保管されているテープメディアだけを確認するには「vmquery -b -rt NONE」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rt NONE
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
[root@nbuserver ~]#

現在存在しないテープ装置内にテープメディアが残存してしまっている場合の処理

現在存在しないテープ装置内にテープメディアが残存してしまっている場合、データベース上の登録をvmchangeコマンドで修正する必要がある。

テープメディアの置き場所を「-new_rt」オプションで「NONE」にすることで、テープ装置外であるという認識になる。
なお、Media Typeも指定する必要があるためvmqueryコマンドで現状のMedia Typeを確認すること。

Media IDが「O502L5」のステータスを変更する場合は、以下の様に実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmchange -m O502L5 -new_rt NONE -mt HCART2
[root@nbuserver ~]#

設定変更後は「vmquery -b -a」もしくは「vmquery -b -rt NONE」を実行し、robot typeが「NONE」に変わったことを確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery  -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

NetBackupマスタサーバのホスト名を変える手順(非公式


NetBackupマスタサーバのホスト名は通常変更できない。

しかし、探すと、NetBackup 6.0時代の非公式手順なるものが発見出来る。


Change Name of Master Serve」消えそうなので下記に内容を転記しておく。

Renaming a Master Server under NetBackup 6.0 requires making some updates to the EMM database and
EMM configration files as well as the changes to configuration files and registry entries required for earlier
versions of NetBackup. The steps involved are:

1. Shut down NetBackup on the Master Server.
2. Change the various entries for the Master Server and EMM server in bp.conf and vm.conf (or the
registry on a Windows server).
3. Change the value of VXDBMS_NB_SERVER in the vxdbms.conf file (located in
/usr/openv/db/data on UNIX and <install path>\VERITAS\NetBackupDB\data on Windows) to
reflect the name of the new Master Server.
4. Change the corresponding value found the server.conf file (located in /usr/openv/var/global on
UNIX and <install path>\VERITAS\NetBackupDB\conf on Windows)
5. Rename the server and restart it.
6. Re-start NetBackup
7. Run nbemmcmd –renamehost –machinename <old master> -newmachinename <new master> –
machinetype master
8. Re-start NetBackup again
9. Run the command nbemmcmd –listhosts –verbose on the Master Server to confirm that the
entries for ‘server’ and ‘master’ reflect the new Master Server name.
10. Run nbemmcmd –setemmserver –emmserver <old master> -newemmserver <new master> on
each media server
11. Update the entries for the master server in bp.conf and vm.conf (or the registry on a Windows
server) on each media server
12. Update the entries for the master server in bp.conf (or the registry on a Windows server) on each
client server
Note: The process described here cannot be used to change a non-clustered Master Server to a
clustered Master Server. This change involves a separate procedure covered in the document
NBU_non-cluster-to-cluster guide which can be found in the data protection operational documents
area of the CoE web site.
Note: Due to limitations in the nbemmcmd –rename command this process cannot be used to
rename clusters on versions below 6.0 MP6, if the Master Server is clustered we recommend moving
to another cluster rather than renaming the existing cluster.


で、この手順は「NetBackup 6.0MP6」では動いたものの、現代はどうなのか試してみた。

結果・・・

・NetBackup 7.xは上記+1ファイル修正で変更可能だった
・NetBackup 8.0,8.1はSSL証明書に記載されたホスト名の変更手順がわからないので不可
・NetBackup 7.xでもRBACを利用しているとSSL証明書が含まれるため失敗した

という結果でした。

とりあえず、「NetBackup 7.6まで実験済みのマスタサーバホスト名変更手順」は以下です。
ちなみにホスト名変更後、NetBackup 8.1にアップデートを行っています。

2019/08/26追記 「/usr/openv/db/data/.odbc.ini.az」の書き換えを追加

(1) NetBackupサービスを停止する。

# /usr/openv/netbackup/bin/bp.kill_all -v -f
# /usr/openv/netbackup/bin/bpps -x

(2) /usr/openv/netbackup/bp.conf の書き換え

ホスト名記述を変更

(3) /usr/openv/volmgr/vm.conf の書き換え

ホスト名記述を変更

(4) /usr/openv/db/data/vxdbms.conf の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(5) /usr/openv/var/global/server.conf の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(6) /usr/openv/db/bin/servername の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(追加) /usr/openv/db/data/.odbc.ini.az の書き換え

「ENG=~」となっている記述を書き換える

(7) /etc/hosts の編集

新しいホスト名と古いホスト名で同じサーバをさすよう修正

(8) OSホスト名変更

OSの変更手法を使ってホスト名変更

(9) NetBackup自動起動を停止

RHEL6だったら以下でオフ

# chkconfig netbackup off

(10) OS再起動

# reboot

(11) NetBackupが起動していないことを確認

# /usr/openv/netbackup/bin/bpps -x

(12) NetBackup起動

# /usr/openv/netbackup/bin/bp.start_all
# /usr/openv/netbackup/bin/bpps -x

(13) 現状のNetBackup EMMの登録確認

# /usr/openv/netbackup/bin/admincmd/nbemmcmd -listhosts -verbose

(14) EMMの登録修正と確認

# /usr/openv/netbackup/bin/admincmd/nbemmcmd -renamehost -machinename 古いホスト名 -newmachinename 新しいホスト名 -machinetype master
# /usr/openv/netbackup/bin/admincmd/nbemmcmd -listhosts -verbose

(15) NetBackupの再起動

# /usr/openv/netbackup/bin/bp.kill_all
# /usr/openv/netbackup/bin/bpps -x
# /usr/openv/netbackup/bin/bp.start_all
# /usr/openv/netbackup/bin/bpps -x

(16) NetBackupの自動起動設定を復旧させる

RHEL6だったら以下を実行

# chkconfig netbackup on

これは、NetBackupインストーラにより設定が変更されているが、その変更がchkconfig側に反映されていないため実行する必要がある。

最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージ


最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージを確認した。

なお、表示させるのはLinuxサーバローカルのディスプレイではなく、同一ネットワーク上にあるWindows10にインストールされた「VcXSrv

# yum install libXext libXrender libXtst xorg-x11-fonts-Type1 vlgothic-fonts vlgothic-p-fonts

なお、「vlgothic-p-fonts」は入れなくても表示はされるが、文字がゴツゴツした感じとなる。

・vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合


vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合

・vlgothic-fontsのみインストールした場合


vlgothic-fontsのみインストールした場合

NetBackup GUIはJavaを使って表示している。

フォントに関する指定はJREのlibにfontconfig~.srcというファイルで保存されている。

# ls /usr/openv/java/jre/lib/fontconfig*.src
/usr/openv/java/jre/lib/fontconfig.RedHat.5.properties.src
/usr/openv/java/jre/lib/fontconfig.RedHat.6.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.10.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.11.properties.src
/usr/openv/java/jre/lib/fontconfig.Turbo.properties.src
/usr/openv/java/jre/lib/fontconfig.properties.src
#

「fontconfig.RedHat.6.properties.src」の中を見てみると、関係しそうな記述として以下を発見

# Font File Names
filename.-misc-kochi_gothic-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf
filename.-misc-kochi_mincho-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/ipa-mincho/ipam.ttf
filename.-misc-zysong18030-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/cjkuni-uming/uming.ttc


# AWT X11 font paths
awtfontpath.chinese-tw-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.chinese-cn-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.japanese-iso10646=/usr/share/fonts/vlgothic
awtfontpath.korean-iso10646=/usr/share/fonts/un-core

どうやら明朝体は「ipa-mincho-fonts.noarch 」 に含まれる /usr/share/fonts/ipa-mincho/ipam.ttf、ゴシック体は「vlgothic-fonts」 に含まれる /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf を使っているようだ。

NetBackupクライアントの接続エラーに関して調査


Veritas NetBackupにおいて、NetBackupクライアントとの接続に問題があった場合の調査手法についてメモ書き

1.1 マスタサーバ/メディアサーバ上での名前解決確認

マスタサーバ/メディアサーバ上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

ここで予期しないIPアドレスが出てきてしまうのであれば、ホスト名/IPアドレス/DNS設定を見直すこと。

続いて問題が発生しているクライアントについての名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

クライアントホスト名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にクライアントホスト名のエントリを追加すること。

追加後は、再度bpclntcmdを実行して、状況が変化したことを確認する。

1.2. クライアント上での名前解決確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

通常はクライアント自身については正常に情報が取得できるはずです。

続いてマスタサーバ/メディアサーバについての名前解決状況を確認

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

マスタサーバ上で実行した結果と異なる場合は、名前解決情報のキャッシュが残存している可能性があるため、「bpclntcmd -clear_host_cache」を実行してキャッシュ削除した上で、再度、名前解決状況を確認する。

マスタサーバ/メディアサーバ名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にマスタサーバ/メディアサーバ 名のエントリを追加すること。

1.3. クライアント上でマスタサーバが認識している情報の確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、NetBackupが認識しているホスト名情報を確認する。

# bpclntcmd -pn -verbose

2.1. 接続テストを実施

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd/bptestbpcd もしくは C:\Program Files\Veritas\NetBacku\bin\admin\bptestbpcd を実行して、 マスターサーバからクライアントへの接続テストを実施します。

# bptestbpcd -client クライアントホスト名 -verbose -debug

QUADSTOR VLTを使ってみた


以前「オープンソース版もあるVTLソフトウェアQUADSTOR」という記事を作成したが、使ってはいなかった。

よく見てみたら、ローカルのテープ装置/テープライブラリとしてエミュレートしてくれる機能もあったので、NetBackup Linuxでテープライブラリを使う案件が来たついでに、練習のためQUADSTORを使ってみた。

QUADSTORの注意点

  • CGIを使うWebインタフェースのプログラム(標準はポート80使用)
  • Webインタフェースに認証機能がないので要注意(アクセスすれば誰でも消せます)
  • SELinux環境下で使う場合、後述のSELinuxコマンドを実行すること
  • 仮想テープのデータを保存する領域はRAWデバイスディスクが必要(OSからマウントされない)
  • QUADSTORの起動に時間がかかる(うちの環境では10分かかった)

セットアップ実施

セットアップは簡単で、「Installation/Upgrading on RHEL/CentOS 6/7, SLES 12 SP2 and Debian 7/8」に書いてあるものをそのまま実行した形である。

# yum install httpd gcc perl kernel-devel sg3_utils
# rpm -ivh quadstor-vtl-ext-3.0.31.1-rhel.x86_64.rpm

プログラムの自動起動で以下を実行

# systemctl enable httpd.service
# systemctl enable quadstorvtl.service

SELinux環境で動作するように下記の設定を実行

# setsebool -P httpd_enable_cgi 1
# semanage permissive -a httpd_t

なお「semanage」は標準ではインストールされていないので「yum install policycoreutils-python」を実行して、追加インストールする必要がある。

Webインタフェースにアクセスする為に、firewallに穴を開けます。

# firewall-cmd --permanent --zone=public --add-service=http

iSCSIデバイスとして動作するので、iSCSIで使用するポートについても設定します。

# firewall-cmd --permanent --zone=public --add-service=iscsi-target

また、Webインタフェースには認証機能がなく、誰でも使用できる状態であるため「Accessing the Web Management Interface」の「SECURING ACCESS TO THE WEB INTERFACE」に記載されているように.htpasswdを使ってアクセス制限をかけましょう。

このあと、Webインタフェースにアクセスすると、以下の様な感じの画面がでてきます。(なお、これはすでにVTL登録済みの状態です)

「Physical Storage」から「Rescan」するとマウントしていないRAWディスクが表示されますので、それを登録します。

「Virtual Libraries」から「Add VTL」よりテープチェンジャーを作成します。

登録したテープチェンジャーは下記の様に見えます。

iSCSIのテープ装置としては作成されましたので、Linuxサーバから接続してみます。

CentOS7だったら、まずは「yum install iscsi-initiator-utils」で接続に必要なソフトウェアをインストールします。

続いて、iSCSI接続を永続化するため「systemctl enable iscsid」を実行します。

「iscsiadm -m discovery -t sendtargets -p <IPアドレス>」を実行し、検出したあと、「iscsiadm -m node –login -p <IPアドレス>」でログインします。

接続するとLinux上からは下記の様に見えるようになります。

# cat /proc/scsi/scsi
<略>
Host: scsi34 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: ULT3580-TD1      Rev: D711
  Type:   Sequential-Access                ANSI  SCSI revision: 06
Host: scsi33 Channel: 00 Id: 00 Lun: 00
  Vendor: ADIC     Model: Scalar 24        Rev: 6.24
  Type:   Medium Changer                   ANSI  SCSI revision: 03
#

NetBackupのコマンドで確認してみると、下記の様にみえました。

# /usr/openv/volmgr/bin/tpautoconf -t
TPAC60 IBM     ULT3580-TD1     D711 2688700001 -1 -1 -1 -1 /dev/nst0 - -
# /usr/openv/volmgr/bin/tpautoconf -r
TPAC60 ADIC    Scalar 24       6.24 26887167A2DC4D54B8910000 -1 -1 -1 -1 /dev/sg4 - -
# /usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/sg4"
Passthru Name: "/dev/sg4"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "ADIC    Scalar 24       6.24"
Vendor ID  : "ADIC    "
Product ID : "Scalar 24       "
Product Rev: "6.24"
Serial Number: "26887167A2DC4D54B8910000"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "ADIC    26887167A2DC4D54B8910000"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-3
Number of Drives : 1
Number of Slots  : 20
Number of Media Access Ports: 1
Drive 1 Serial Number      : "2688700001"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst0"
Passthru Name: "/dev/sg3"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULT3580-TD1     D711"
Vendor ID  : "IBM     "
Product ID : "ULT3580-TD1     "
Product Rev: "D711"
Serial Number: "2688700001"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULT3580-TD1     2688700001"
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
#

ドキュメントを確認すると、「Data deduplication best practices」というのがあり、重複排除が行われた状態でRAWストレージに格納されている模様。


2019/11/01追記

QUADstorをアップデートする場合の注意点。

「rpm -Uvh quadstor*.rpm」といったアップデートはできない。

一度、アンインストールした上で、再インストールする必要がある。

ここまでは「Installation or Upgrading the VTL software」にも書かれているのだが、実際にやろうとするとスクリプトの実行に失敗する場合がある。

アンインストール時、quadstorによりinitrd imageに組み込まれたモジュールを削除するために、quadstorの停止とモジュールのアンロードが実施されるのだが、モジュールの使用状況によってはアンロードが失敗する場合がある。

その場合は、一度OSを再起動して、モジュールがロードされていない状態にしないとアンインストールができなかった。

CentOS7の場合、以下の手順で行った。

(1) 「systemctl mask quadstorvtl」で再起動時にQUADstorが起動しない様に設定(maskしなくでも大丈夫な場合もある)
(2) OS再起動
(3) 「rpm -ev quadstor-vtl-ext-3.0.36-rhel.x86_64」といった感じでパッケージ削除
(4) 「rpm -ivh quadstor-vtl-ext-3.0.37-rhel.x86_64.rpm」といった感じでパッケージインストール
(5) 「 systemctl unmask quadstorvtl」 「systemctl enable quadstorvtl」で有効化
(6) OS再起動