2026年9月13日日曜日

クラスターの耐障害性Cluster Fault Toleranceについて(AOS7.6の仕様変更対応版)

従来クラスターの耐障害性は、Redundancy Factor 2 or 3という形で、1台のホストが障害が発生しても問題なく稼働できるか、2台のホストが同時に障害が発生しても問題なく稼働できるのかの2つからの選択でした。

AOS 7.0より1N&1D(1ノードのホストと他のノードのフラッシュまたはディスクの同時障害)に耐えられる機能が実装されましたが、クラスターのノード数が3台に制限されていました。
これが、AOS 7.6からノード数が3ノード以上であればノード数に制限がなくなりました。

耐障害性が、ディスクレベルで選択できるようになったこともあり、従来Redundancy Factorと呼んでいた耐障害性の呼び方も「Cluster Fault Tolerance」に変わりました。


フォールトトレランスとサポートされるRFの種別

フォールト
トレランス種別
説明サポートされる冗長係数
Replication Factor
1N/1D1ノードまたは1ディスクの障害に対応
(クラスタあたり最小1ノードからサポート)
2, 1
1N&1D1ノードおよび1ディスクの同時障害に対応
(クラスタあたり最小3ノードからサポート)
※各ノードに2つのメタデータディスクが必要
3, 2, 1
1N/2D1ノードまたは2ディスクの障害に対応
(クラスタあたり最小5ノードからサポート)
3, 2, 1
2N/2D2ノードまたは2ディスクの障害に対応
(クラスタあたり最小5ノードからサポート)
3, 2, 1


1N/1D


1N&1D


1N/2D



2N/2D



従来のRedundancy Factor2が「1N/1D」に該当し、Redundancy Factor3が、「1N/2D」「2N/2D」に該当します。

1N&1Dは、特殊で、クラスター内の1台のノードと他のノードのディスクが同時に障害が発生しても継続してクラスターを稼働できる仕組みとなります。この場合1ノードあたり2つのメタデータディスクが必要とありますので、NX-1065のようなフラッシュ(SSD)が1本しか搭載されていないモデルでは利用できません。昨今は、1ノードあたりフラッシュメディアが1本というモデルはほとんどないと思いますが、こちらは注意してください。


フォールトトレランスは、以下のパターンのみ変更が可能です。

変更パターン条件
1N/1D → 1N&1D最小3ノード、各ノードに2つのメタデータディスクが必要
1N/1D → 2N/2D最小5ノード
1N/1D → 1N/2D最小5ノード

1N&1Dから2N/2Dへの移行、1N/2Dから1N&1Dへの移行はサポートされません。


これにともない、PrismのCluster Resiliency / Fault Tolerance Statusについては、以下の表記となります。


ステータス状態
OK障害ドメインが障害(ノードやディスク障害など)を安全に処理できる状態
Warning耐障害レベルがほぼ0に近づいている状態(設定したドメインでは耐えられないが、より下位のドメイン障害には耐えられる場合など)
Criticalフォールトトレランスレベルが0であり、ノードやディスクの障害に耐えられない状態
Computing障害発生直後など、リビルド開始前に新しいフォールトトレランスレベルを計算している状態


なお従来からのReplication Factor 2(RF2)やReplication Factor 3(RF3)といったデータの冗長性に関する表記は、そのまま継続となります。

NutanixのドキュメントもCluster Fault Toleranceに表記が変わっていますので、今後はCluster Fault Toleranceとして、どの冗長構成が必要かを設計フェーズで検討してください。

(参考)Cluster Fault Tolerance


 

2026年9月12日土曜日

Nutanix+ESXi環境をNutanix+AHVにハイパーバイザーを変更する(その6)

5回に分けて、ESXiからAHVに変換するConvert Cluster機能についてご紹介してきました。

まず、仮想マシンを変換するうえで大切な要件だけをまとめておきます。


<変換における重要事項>

  1. あらかじめ仮想マシンのゲストOSにVirtIO Driverをインストールする
  2. NGTをゲストOSにインストールする
  3. VM BOOT OPTIONSは、「Power off user VMs」を強く推奨
  4. UPSやバックアップなど、周辺ソフトウェアに注意する
  5. ゲストOSから、VMware Toolsのアンインストールを個別に行う
  6. ゲストOSがWindowsの場合、SANポリシーを変更する
  7. Convert Cluster実行前に、すべての仮想マシンをProtection Domainで保護し、スナップショットを取得しておく
  8. vCenter Serverは、Nutanixクラスターの外に配置する

1は、AHVへの変換後にゲストOSを起動するためには、仮想マシンのディスクバスであるVirtSCSIのドライバーが必要になるためです。NGTをインストールすればVirtIO Driverもインストールされますので、個別にインストールする必要はありません。

3は、それなりに重要な事項です。仮想マシンがAHVに変換されると、仮想マシンのタイムゾーンはすべてUTCで設定されます。

そのため、そのまま自動で仮想マシンをパワーオンすると、UTCの時刻で起動することになります。LinuxやUNIX系OSでは問題にならない場合もありますが、Windows系OSの場合、時刻が9時間ずれることになります。Active Directoryなど、時刻にシビアな仮想マシンがある場合、思わぬトラブルにつながる可能性があります。そのため、クラスター内のすべての仮想マシンの変換が完了した後、仮想マシンのタイムゾーンを適切なものに設定してからパワーオンするのがよいと思われます。

4は、UPSやバックアップソフトなど、ハイパーバイザーと連携するソフトウェアがESXiホストとして認識しているため、AHVとして再登録が必要になります。ESXiにしか対応していないソフトウェアを利用している場合は、AHVに対応したソフトウェアへ切り替える必要があります。

5は、ESXi基盤ではない状態になっているため、Windowsの場合、アプリケーションのアンインストール機能からVMware Toolsを正常に削除できないことがあります。

KB431278を参考に、VMware Toolsを手動で削除する必要があります。


6は、ゲストOSがWindowsの場合、AHVへの変換後にゲストOSを起動すると、起動ドライブであるCドライブ以外のディスクがオフラインになることがあります。これはWindowsの仕様によるものですが、アプリケーションなどが正常に起動しないなどの影響が出る可能性があります。あらかじめSANポリシーを「OnlineAll」にしておくことをお勧めします。

ポリシーの変更については、仮想マシンのDドライブ以降がオフラインになるのを回避する方法をご確認いただければと思います。

7は、万が一変換に失敗したり、仮想マシンがPrism Element上に表示されなくなったりした場合、復旧が困難になる可能性があるためです。Protection Domain(PD)で仮想マシンを保護しておけば、AHVへの変換後もスナップショットが保持され、AHV環境へリストアすることが可能です。その際、仮想マシンの仮想ディスクはAHVで読み取れる形式でリストアされるため、そのままパワーオンできます。


また、ゲストOSが正常に起動できない場合は、VirtIO Driverがインストールされていない可能性があります。以下のKBを参考にドライバーをインストールし、ゲストOSが起動できるように設定する必要があります。


(参考)

KB7121 : Windows liveISO chkdsk for SCSI disk

KB2627 : Migrating Linux VMs to AHV


また、NICは新しいデバイスとして認識されますので、必要に応じてIPアドレスの再設定が必要です。

Nutanix Moveを利用したConvert Clusterでは、IPアドレスの再設定など、Nutanixクラスター単体のConvert Clusterでは対応できない部分もアシストしてくれるようです。(ただし、ハイパーバイザーのコンバージョン部分は、今回紹介したConvert Clusterと同じ動作になるようです)


Convert Cluster機能は、非常に便利な機能です。ただし、変換が100%うまくいくという保証はありませんので、あらかじめバックアップなどの必要な対策を行ったうえで実施してください。

仮にConvert Clusterがうまくいかなかった場合でも、Protection Domainで保護していれば仮想マシンのデータ自体は保護されます。そのため、さまざまな事前対策を行っておけば、より安心してConvert Clusterを実施できると考えられます。




 

Nutanix+ESXi環境をNutanix+AHVにハイパーバイザーを変更する(その5)

前回は、仮想マシンにNGTをインストールし、VirtIO DriverをゲストOSにインストールしました。

では、いよいよハイパーバイザーの変換作業となります。


6.ハイパーバイザーの変換

Prism Elementの画面から、「Settings」から「Convert Cluster」を開き、「AVAILABLE HYPERVISOR」に「AHV」を選択、VM BOOT OPTIONSに「Power off user VMs」を選択し、「Validate」ボタンを押します。Nutanixクラスターに接続したvCenter Serverの接続情報を聞かれますので、クレデンシャル情報を含めて入力します。


バリデーションの結果が表示されます。エラーは消えましたが、いくつかのWarningが出ています。

このWarningは、

  1. チーミングモードがActive/Backupになる
  2. NGTはインストールされているが、VirtIO Driverが正しくインストールされていない仮想マシンがある
  3. vCenter ServerにNGTがインストールされていない
  4. 特定のVMで、NGTがインストールされていない

1や3については、特に対応の必要はありません。
2や4については、個別にドライバーだけをインストールしている場合や、変換後は利用しない、もしくは再展開する仮想アプライアンスなどであれば、無視してもらって構いません。
3のvCenter Serverは、すでに他のホストに移動しているため、Nutanix上のvCenter Serverを利用することはありません。

NGTがインストールされていなくても仮想マシン自体はAHVで稼働できるように変換されますので、AHVへの変換後にレスキューメディアなどを利用してVirtIO Driverをインストールする形でも問題ありません。


次に進むと、AHVハイパーバイザーのISOを要求されます。現在稼働しているAOSと互換性のあるAHVバージョンのISOが自動的に指定されますので、Nutanix Support Portalからダウンロードした後、アップロードします。


アップロードが完了すると、「Convert Cluster」のボタンが押せるようになります。


最後に注意点として、一部のオペレーションができなくなる旨と、vCenter ServerがConvert Clusterを実行するNutanixクラスター上で動作していないことを確認されます。


すると、各ホストのタスク情報が表示されます。


vCenter Server側の挙動を見ると、ホストがメンテナンスモードに入るようになっています。
これにより、ワークロードの仮想マシンを他のホストに退避します。しかし、CVM自体は稼働したままで、再イメージングの準備処理が内部で動作しています。そのため、メンテナンスモードへの移行が完了せず待機状態が続きますが、焦らず見守ります。


vCenter Serverから見ると、ホストは全台動作しており、CVMも稼働中になっているように見受けられますが、Prism上ではクラスターの状態がCriticalになります。これは、CVM自体がメンテナンスモードになっていることが影響しています。


しばらくすると、vCenter Serverからホストがオフラインになり、ホストが再起動します。
再起動直後は、ESXiが再起動しているように見受けられます。


しかし、その後画面が切り替わり、そのままPhoenixが起動します。

メンテナンスモードになったノードとは別のノードのCVMでFoundationサービスが稼働しているようで、そこからAHVのイメージングが行われます。


その後、Phoenixによるイメージングが完了するのを待ちます。
イメージング中のサーバー本体は、メンテナンス用のランプが点滅するので、どのノードがイメージング中なのかは、サーバー本体の外観からもわかります。


なお、この間も仮想マシンは正常に稼働中です。これは、NutanixのN+1の冗長性を生かしながら処理が行われていることがわかります。


最初にメンテナンスモードへ移行してから、30分程度でこの画面まで進みました。


以下の画面が表示されたら、そのノードのイメージングが完了し、ハイパーバイザーがAHVに切り替わっていることがわかります。

しばらくすると、一部の仮想マシンはNGTを経由してシャットダウンされた後、AHVホスト上で稼働できるように変換され、リストアされます。

変換された仮想マシンは、vCenter Serverのインベントリ情報からも削除されます。

この処理を繰り返し、各ホストがメンテナンスモードに入り、Phoenixが起動してAHVへのイメージングが行われます。ホストがAHVに切り替わると、一部の仮想マシンがAHV上で動作するように変換されます。

最後の1台のホストを変換する段階では、ほかのホストはすべてAHVに変換されていますので、ESXi上で稼働する仮想マシンは0台になっています。

Convert Clusterの作業中は、Prism Element画面から仮想マシンを編集することはできません。

クラスター内のすべてのホストがAHVに変換されると、タスクが終了し、そのままAHVクラスターとして利用できるようになります。


これで、Convert Clusterの作業は終了です。

かかる時間はサーバーの性能などにもよりますが、今回検証した環境では、通常のFoundationで行うイメージング作業に加えて、仮想マシンの変換作業にかかる時間は、おおよそ5分程度でした。


実は、事前準備ができていれば、わずかな時間でESXiからAHVへハイパーバイザーを変更できます。

次回は、Convert Clusterにおける注意点を含め、まとめの情報を記載いたします。





Nutanix+ESXi環境をNutanix+AHVにハイパーバイザーを変更する(その4)

前回までに、Convert Clusterを実行するためのvCenter Serverの設定変更を行いました。

では、準備フェーズとして最後の手順を行います。


4.仮想マシンへのNGTのインストール

AHVへの変換を行うと、ゲストOS側でVirtIO Driverが読み込まれていない場合、正常に起動できません。そのため、あらかじめゲストOSにNutanix Guest Tools(NGT)をインストールします。NGTをインストールすると、VM Mobilityの機能としてVirtIO Driverがインストールされます。

Prism ElementのVM画面から、NGTをインストールする仮想マシンを選択し、「Manage Guest Tools」をクリックして設定画面を開きます。

「Enable Nutanix Guest Tools」にチェックを入れ、「Mount Nutanix Guest Tools」にチェックを入れます。

以下の画面のように「Guest Tools cannot be mounted as there not enough empty CD-ROM(s)」と表示される場合は、OSインストールメディアなど、CD-ROMドライブに何らかのISOがマウントされている可能性があります。


CDがマウントされていた場合は、vCenter Serverの画面から仮想マシンのCD-ROMドライブのマウントを解除し、「クライアントデバイス」に変更します。


次に、ゲストOSのコンソール画面に入ります。

まずは、Windows版のインストール方法から紹介します。

CD-ROMドライブを見ると、「NUTANIX_TOOLS」というメディアがマウントされているかと思いますので、「setup.exe」を実行します。


インストールウィザードが表示されますので、ライセンスを承諾し、「Install」をクリックします。

すると、すぐにインストールが開始されます。


インストールは数分で終わります。


すでにNGTをインストールしている環境で、NGTをアップグレードインストールした場合は、ドライバーが更新されるためOSの再起動を要求されます。
新規でNGTをインストールした場合は、ゲストOSの再起動は不要です。


続いて、Linux版のインストール方法をご紹介します。

Prism Elementの画面から、同様にNGTのISOをマウントします。


ここでは、Rocky Linux 10.1で説明しますが、Linux系であれば基本的な手順は同じです。

まず、mountコマンドを利用し、CD-ROMドライブをマウントします。(ここでは、/mediaにマウントしています)

sudo mount /dev/cdrom /media

続いて、CD-ROM内のディレクトリに移動します。

cd /media/installer/linux

インストールにはPythonを利用します。Python 3がインストール済みの場合は、以下のように実行します。

python3 ./install_ngt.py --operation install

以下のような形で、インストールが完了します。

[root@rocky10 linux]# python3 ./install_ngt.py --operation install
[2026-09-12 16:08:17] {install_ngt.py:61} INFO - Executing command: which rpm
[2026-09-12 16:08:17] {install_ngt.py:81} INFO - Output: /bin/rpm

[2026-09-12 16:08:17] {install_ngt.py:61} INFO - Executing command: which dpkg
[2026-09-12 16:08:17] {install_ngt.py:106} WARNING - Dpkg command failed due to error : which dpkg failed, Status code:1, Output:'', Error:'which: no dpkg in (/root/.local/bin:/root/bin:/sbin:/bin:/usr/sbin:/usr/bin)\n'
[2026-09-12 16:08:17] {install_ngt.py:61} INFO - Executing command: sh /media/installer/linux/ngt_rpm_installer/ngt_install_upgrade.sh
[2026-09-12 16:09:54] {install_ngt.py:81} INFO - Output: Current Directory: /media/installer/linux/ngt_rpm_installer
Linux Distribution : NAME="ROCKY LINUX"
VERSION="10.1 (RED QUARTZ)"
ID="ROCKY"
ID_LIKE="RHEL CENTOS FEDORA"
VERSION_ID="10.1"
PLATFORM_ID="PLATFORM:EL10"
PRETTY_NAME="ROCKY LINUX 10.1 (RED QUARTZ)"
ANSI_COLOR="0;32"
LOGO="FEDORA-LOGO-ICON"
CPE_NAME="CPE:/O:ROCKY:ROCKY:10::BASEOS"
HOME_URL="HTTPS://ROCKYLINUX.ORG/"
VENDOR_NAME="RESF"
VENDOR_URL="HTTPS://RESF.ORG/"
BUG_REPORT_URL="HTTPS://BUGS.ROCKYLINUX.ORG/"
SUPPORT_END="2035-05-31"
ROCKY_SUPPORT_PRODUCT="ROCKY-LINUX-10"
ROCKY_SUPPORT_PRODUCT_VERSION="10.1"
REDHAT_SUPPORT_PRODUCT="ROCKY LINUX"
REDHAT_SUPPORT_PRODUCT_VERSION="10.1"
ROCKY LINUX RELEASE 10.1 (RED QUARTZ)
ROCKY LINUX RELEASE 10.1 (RED QUARTZ)
ROCKY LINUX RELEASE 10.1 (RED QUARTZ)
Rocky Linux 10 - BaseOS                         8.6 kB/s | 4.3 kB     00:00
Rocky Linux 10 - BaseOS                          27 MB/s |  27 MB     00:00
Rocky Linux 10 - AppStream                      9.1 kB/s | 4.4 kB     00:00
Rocky Linux 10 - AppStream                      739 kB/s | 2.6 MB     00:03
Rocky Linux 10 - Extras                         7.0 kB/s | 3.1 kB     00:00
Rocky Linux 10 - Extras                          11 kB/s | 5.8 kB     00:00
インストール済みパッケージ
名前         : rpm
バージョン   : 4.19.1.1
リリース     : 20.el10
Arch         : x86_64
サイズ       : 3.0 M
ソース       : rpm-4.19.1.1-20.el10.src.rpm
リポジトリー : @System
repo から    : anaconda
概要         : The RPM package management system
URL          : http://www.rpm.org/
ライセンス   : GPL-2.0-or-later
説明         : The RPM Package Manager (RPM) is a powerful command line driven
: package management system capable of installing, uninstalling,
: verifying, querying, and updating software packages. Each software
: package consists of an archive of files along with information about
: the package like its version, a description, etc.

利用可能なパッケージ
名前         : rpm
バージョン   : 4.19.1.1
リリース     : 23.el10
Arch         : x86_64
サイズ       : 543 k
ソース       : rpm-4.19.1.1-23.el10.src.rpm
リポジトリー : baseos
概要         : The RPM package management system
URL          : http://www.rpm.org/
ライセンス   : GPL-2.0-or-later
説明         : The RPM Package Manager (RPM) is a powerful command line driven
: package management system capable of installing, uninstalling,
: verifying, querying, and updating software packages. Each software
: package consists of an archive of files along with information about
: the package like its version, a description, etc.

Nutanix NGT                                     390 kB/s | 2.1 kB     00:00
利用可能なパッケージ
nutanix-guest-agent.i686            4.3.1-1           nutanix-ngt-20260912160817
nutanix-guest-agent.x86_64          4.3.1-1           nutanix-ngt-20260912160817
メタデータの期限切れの最終確認: 0:00:01 前の 2026年07月12日 16時08分30秒 に実施 しました。
依存関係が解決しました。
============

# パッケージ           Arch    バージョン      リポジトリー                サイズ

インストール:
nutanix-guest-agent  x86_64  4.3.1-1         nutanix-ngt-20260912160817   60 M
依存関係のインストール:
libxcrypt-compat     x86_64  4.4.36-10.el10  appstream                    90 k

# トランザクションの概要

インストール  2 パッケージ

合計サイズ: 60 M
ダウンロードサイズの合計: 90 k
インストール後のサイズ: 302 M
パッケージのダウンロード:
libxcrypt-compat-4.4.36-10.el10.x86_64.rpm      1.0 MB/s |  90 kB     00:00
---------------------------------------------------------------------------

合計                                            181 kB/s |  90 kB     00:00
Nutanix NGT                                     3.0 MB/s | 3.1 kB     00:00
鍵のインポートに成功しました
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備             :                                                        1/1
インストール中   : libxcrypt-compat-4.4.36-10.el10.x86_64                 1/2
scriptletの実行中: nutanix-guest-agent-4.3.1-1.x86_64                     2/2
Pre: RPM is getting installed

インストール中   : nutanix-guest-agent-4.3.1-1.x86_64                     2/2
scriptletの実行中: nutanix-guest-agent-4.3.1-1.x86_64                     2/2
Post: RPM is getting installed.
Running installer utility script.
/usr/local/nutanix/ngt//src/rpm_installer_utils.py:74: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
if LooseVersion(self.version) < LooseVersion(self.REDHAT_8_VERSION):
INFO: Setting up Nutanix Guest Tools - VM mobility drivers.
WARNING: Kernel module bochs-drm does not exist.
INFO: Successfully set up Nutanix Guest Tools - VM mobility drivers.
INFO: Creating desktop shortcuts...

Reloading systemd manager configuration...
Restarting ngt_guest_agent.service systemctl service...
ngt_guest_agent.service service restart done.
Restarting ngt_self_service_restore.service systemctl service...
ngt_self_service_restore.service service restart done.

インストール済み:
libxcrypt-compat-4.4.36-10.el10.x86_64   nutanix-guest-agent-4.3.1-1.x86_64

完了しました!
メタデータの期限切れの最終確認: 0:01:23 前の 2026年07月12日 16時08分30秒 に実施 しました。
依存関係が解決しました。
行うべきことはありません。
完了しました!
cleanup started...
Removing yum repo : /etc/yum.repos.d//nutanix-ngt-20260912160817.repo, if exists.
Removing temporary created repo file : /tmp/nutanix-ngt-20260912160817.repo, if exists.
cleanup done...

[2026-07-12 16:09:54] {install_ngt.py:83} ERROR - Failure : GPG 鍵 0x6E4B3ED2 をインポート中:
Userid     : "Nutanix, Inc. (NGT Packaging) "
Fingerprint: 112B XXXX XXXX XXXX XXXX XXXX XXXX 46BC 6E4B 3ED2
From       : /media/installer/linux/ngt_rpm_installer/RPM-GPG-PUBLIC-KEY

[root@rocky10mst linux]# 

最後にGPG鍵のインポートエラーが出ていますが、ドライバーのインストール自体は完了しているため、ここでは一旦この問題はスキップします。

これで、NGTのインストールは完了です。


ただし、インストールしただけではなく、Convert ClusterのValidationでWarningが表示されないようにするため、NGTとNutanixクラスターが正常に通信できていることを確認します。


CVMにSSHでログインし、NGTエージェントとNutanixクラスターが通信できているかを確認します。

ncli vm lsで、NGTをインストールした仮想マシンのUUIDを確認します。

nutanix@NTNX-XXXX-A-CVM:XX.XX.XX.XXX:~$ ncli vm ls name=CNV-RokcyLinux10.1

```
Id                        : 00063087-e3d4-f515-1df0-1866da62c70a::50380ffc-8f75-393c-49c0-a1164d96d1a2
Uuid                      : 9566cc78-ba5d-4ab7-9763-ebce99dca637 #★こちらを控える
Name                      : CNV-RokcyLinux10.1
VM IP Addresses           : XX.XX.XX.18, fe80::250:56ff:feb8:ffe0
Hypervisor Host Id        : 00063087-e3d4-f515-1df0-1866da62c70a::6
Hypervisor Host Uuid      : b17e247e-aa3c-4da0-94f3-5eb251e3991a
Hypervisor Host Name      : ESX3
Memory                    : 4 GiB (4,294,967,296 bytes)
Virtual CPUs              : 4
VDisk Count               : 2
VDisks                    : 00063087-e3d4-f515-1df0-1866da62c70a::NFS:4:0:13174, 00063087-e3d4-f515-1df0-1866da62c70a::NFS:4:0:13231
Protection Domain         :
Consistency Group         :
```

nutanix@NTNX-XXXX-A-CVM:XX.XX.XX.XXX:~$ ncli ngt get vm-id=9566cc78-ba5d-4ab7-9763-ebce99dca637

```
VM Id                     : 00063087-e3d4-f515-1df0-1866da62c70a::50380ffc-8f75-393c-49c0-a1164d96d1a2
VM Name                   : CNV-RokcyLinux10.1
NGT Enabled               : true
Tools ISO Mounted         : false
Vss Snapshot              : true
File Level Restore        : false
Communication Link Active : true #★ここがtrueならOK
```


「Communication Link Active」がtrueになっていれば問題ありません。

2026年9月時点でサポートされているAOS 6.10以降であれば、NGTはNutanixクラスターのVIP以外に、COMポートを使用してハイパーバイザーとの通信も行えるようになっているため、仮想マシンのネットワークとNutanixクラスターの管理ネットワークが分離されていても、通信上の問題はありません。


これで、仮想マシンの準備は終わりました。

仮想アプライアンスなど、NGTをインストールできないものについては、あらかじめVirtIO Driverが組み込まれているかを確認してください。仮想アプライアンスがESXi版とAHV版で分かれている場合は、仮想アプライアンス上で稼働するシステム設定のバックアップを取得し、AHV版のアプライアンスを再展開して設定をインポートするなど、無理に変換だけにこだわらない手法を選択してください。


5.仮想マシンの保護

クラスターを変換する準備ができたら、必ずData Protectionで、すべての仮想マシンを保護してください。万が一、変換中にエラーが発生した場合でも、Protection Domainから仮想マシンを復旧することができます。(AHVへの変換後にリストアした場合、自動的にAHVに変換された仮想マシンとしてリストア可能です


以上で準備は整いました。次回は、Convert Clusterの作業を行いたいと思います。





Nutanix+ESXi環境をNutanix+AHVにハイパーバイザーを変更する(その3)

前回までに、vCenter ServerをNutanixクラスターの外に再配置しました。引き続き作業を行います。


2.バリデーションの確認

Convert Clusterを実行するためには、ほかにも設定を確認する必要がありますが、Convert Clusterには移行前のチェック機能がありますので、まずはこのチェック機能を実行してみたいと思います。

変換したいNutanixクラスターのPrism Elementを開き、「Settings」から「Convert Cluster」を開きます。

AVAILABLE HYPERVISORは「AHV」、VM BOOT OPTIONSは「Power off user VMs」を選択します。


「Validate」をクリックして、チェックを行います。

vCenter Serverの接続情報が表示されますので、NutanixのESXiホストを管理している、前回移動したvCenter Serverを指定します。


Validateには、それなりに時間がかかります。画面左上にタスクの状況が表示されますので、タスクから進捗を確認することも可能です。


しばらくすると結果が表示されます。

ここでは、ErrorとWarningの2つが表示されます。Errorはスキップすることができませんので、必ず設定変更を行う必要がある項目です。
Warningについてはスキップが可能ですが、注意事項を確認する必要があります。また、仮想マシンに関するWarningでは、NGTが未インストールの仮想マシンが検出されます。NGTが未インストールの仮想マシンについては、AHVへの変換後に仮想マシンのOSが起動しない可能性がありますので、慎重に確認してください。

この画面では、アドミッションコントロールの変更と、仮想スイッチに速度の異なるNICが混在している旨が表示されています。


スナップショットを保持している仮想マシンがある場合は、以下のようなエラーが表示されます。


3.vCenter Serverの設定変更

では、1つずつ設定を変更していきましょう。

アドミッションコントロールを無効化しますので、vSphere HAの設定を編集します。


ホストのフェイルオーバーキャパシティの定義基準を「無効」にします。


アップリンクNICの変更

本環境では、あえてNIC速度が混在する仮想スイッチを作成していました。この環境で不要なNICを、まずはアップリンクから外していきます。

速度の異なるNICや、スタンバイNICに設定されている不要なNICをすべて未使用アダプタに移動します。


これで、vCenter Serverの設定は完了しました。
これ以外にも、DRSが有効になっているかなども確認しておきましょう。

再度Validateを実行すると、今度は違うエラーが出てきました。


1つは、HAの設定でPDLの設定を無効にする必要があります。


もう1つは、ポートグループがすべてのホストに存在していないために表示されているエラーです。仮想マシンが利用しているポートグループについて、標準スイッチを利用している場合は、すべてのホストに同じポートグループを追加します。


これで再び、Convert ClusterからValidateを実行してみます。



すると、Errorの項目が消え、仮想マシンのNGTインストールチェックだけがWarningとして表示されていることがわかります。


このままConvert Clusterを実行することもできますが、NGTが未インストールの状態ですと、AHVへの変換完了後に仮想マシンのゲストOSが起動しない可能性があるため、先にNGTをインストールしておく必要があります。

こちらは、次回紹介いたします。




 

Nutanix+ESXi環境をNutanix+AHVにハイパーバイザーを変更する(その2)

前回までに、ハイパーバイザーのコンバージョン(Convert Cluster)の要件を確認していきました。

今回は、実際の変換までの作業タスクを紹介します。

1.vCenter Serverの退避

vCenter Serverが、変換対象のNutanixクラスター以外のサーバーですでに稼働中であれば、この作業は不要ですが、一般的には既存のNutanix環境上でvCenter Serverが稼働していることが多いと思います。

Convert Clusterを利用するためには、別の環境でvCenter Serverを稼働させる必要がありますので、一時的にvCenter Serverを稼働させるホストを用意する必要があります。

まずは、既存のvCenter Serverのデータバックアップを行います。

既存のvCenter ServerのIPアドレスに、ポート5480を指定してアクセスします。
例) https://vCenterServer IP:5480

すると、vCenter Server管理画面のログイン画面が表示されますので、「root」ユーザーでログインします。(vCenterのAdministratorアカウントではありません)


「バックアップ」から「今すぐバックアップ」を選択し、バックアップを取得します。


ここでは、あらかじめ用意したバックアップ先(SMBファイルサーバー)を指定し、バックアップを取得しています。


バックアップは、仮想マシン台数やログの期間などにもよりますが、そこまで長い時間はかからないと思います。

バックアップフォルダにファイルが保存されたことを確認します。


あわせて、ステータスが完了になったことを確認します。


バックアップの取得が終わったら、既存のvCenter Serverを終了します
これは、リストア先のvCenter Serverが同じIPアドレスで稼働するため、IPアドレスの競合を防ぐためです。

続いて、新しい環境にvCenter Serverをリストアします。
vCenter ServerのインストールISOをマウントし、インストールウィザードを起動します。
言語をJapaneseに変更し、「リストア」をクリックします。

続いて、バックアップを保存したファイルサーバーを指定します。

リストア先となる、Nutanix以外のESXiホストを指定します。


vCenter Serverのパスワードやデプロイサイズ、データストア、ネットワークを選択し、展開を行います。

ステージ1が完了するのを待ち、ステージ2のウィザードに進みます。


ステージ2のリストア項目に進みます。


ウィザードのバックアップの詳細はすでに選択されているはずですので、サマリーを確認し、ステージ2の処理が完了するのを待ちます。


リストアは、それなりに早く進むと思います。


リストアが完了したことを確認し、もともとのvCenter ServerのIPアドレスで接続できることを確認します。


vCenter Serverに接続後、Prismの「vCenter Server Connection」の部分で、接続が確立していることを確認してください。


これで、vCenter Serverのお引越しは終わりです。

次回は、移行前のvCenter Serverの設定確認を行っていきます。