2026年9月25日金曜日

PolicyEngineのデータリストア方法の紹介

前回、Policy Engine VAのバックアップ(データのバックアップ)をご紹介しました。

今回は、PolicyEngineが故障したり再展開を視座エルを得ない状況に陥った場合にリストアする方法をご紹介します。


1.新規でPolicy EngineのVAを新規展開する

まずは、Policy EngineのVAをPrism Centralから新規展開を行います。


2.Policy Engine VAにSSHでログインします。

デフォルトのユーザ名は「nutanix」、パスワードは「nutanix/4u」です。こちらは、必ずパスワードの変更を行っておきましょう。


3.取得したバックアップデータをPolicy Engine VAにコピーする

scp backupuser@backupsv-ip:/var/backup/polbkup.gz /home/nutanix/data/backups/

この例では、backupsv-ipというバックアップサーバーの「/var/backup/polbkup.gz」ファイルを、Policy Engine VAの「/home/nutanix/data/backups/」にコピーしています。


4.バックアップデータが認識できているかを確認

 /home/nutanix/scripts/restore.sh --list

を実行し、取得したバックアップデータが見えていることを確認します。
ここでは、「polbkup.gz」というバックアップファイルが見えていることを確認します。


5.リストアを実行します

/home/nutanix/scripts/restore.sh -f=polbkup.gz

これで、リストアが完了します。


リストアの手法は、比較的簡単ですが、少し手のかかるものでもあります。

DisasterRecoveryのバックアップは、1時間に1回のスナップショット取得ですので、その時間からデータに差分がある場合は、スナップショットからPolicy Engineをリストアしたのち、細心のバックアップからデータをリストアする流れになります。











 

Policy Engineのバックアップ方法について

主にRBACやSecure Snapshot(承認ポリシー)で利用する際に展開が必要な「Policy Engine」ですが、このPolicy Engineは、Prism Centralとは別の仮想アプライアンスとして展開されます。
Prism Centralのバックアップ機能であるPCBRでは、このPolicy Engineはバックアップ対象外となっており、Prism Centralとは別の方法でバックアップを行う必要があります。

本日は、このPolicy Engineのバックアップ方法について紹介いたします。

1. Policy EngineのアプライアンスIPアドレスを確認します。

Prism CentralのAdmin CenterからSettingsを開き、「Policy Engine」を開くことで、アプライアンスのIPアドレスを確認できます。


2. Policy Engineの仮想アプライアンスにSSHでログインします。

デフォルトユーザーは「nutanix」、パスワードは「nutanix/4u」です。
併せて、必ずパスワードはデフォルトから変更しておきましょう!
(passwdコマンドで変更可能です)


3. バックアップ専用スクリプトを実行します。

/home/nutanix/scripts/backup.sh false <バックアップファイル名>

を実行します。(nutanixユーザーで構いません)

メーカードキュメント上では、このスクリプトのみが実行されていますが、その場合、バックアップファイル名に自動的に日時が付与される形となり、取り扱いが難しくなるため、こちらの例ではバックアップファイル名を指定しています。
このコマンドを実行すると、内部で動作しているPolicy Engineのコンテナを停止してからバックアップを取得するため、バックアップ中はポリシー関連の操作ができなくなります。


4. バックアップデータをバックアップサーバーに退避します。

scp /home/nutanix/data/backups/polbkup.gz backupuser@backupsv-ip:/var/backup

※backupuserというユーザーで、/var/backupというディレクトリにコピーしています。


これで、バックアップは完了です。


Policy Engineのバックアップデータはgz形式で仮想アプライアンス内に保存されるため、SCPでコピーおよび保存が可能なマシンを別途用意し、そちらにデータをコピーする必要があります。コピーしたデータが保存されたマシン、もしくはgzファイルを別途バックアップソフトウェアなどでバックアップするか、Nutanixのスナップショットを取得することで保護が可能となります。


Policy Engine自体は、展開と同時にPrism CentralのDisaster Recovery機能にて「CalmPolicyEngineVMPR」というポリシーが自動作成されます。このポリシーには、自動で1時間おきに2世代のスナップショットを取得する設定が入っています。こちらのポリシーを変更し、別のNutanixクラスターに転送することでバックアップとして保存することができます。




以下は非サポートの内容となりますが、Policy EngineのVAで「crontab -u nutanix -e」を使用したスケジュール実行は、こちらで確認した限りでは可能でした。そのため、バックアップスクリプトの実行からSCPによるコピーまでを一連の処理としてスケジュール実行することで、自動バックアップすることも可能です。







Nutanix MoveによるActive Directory移行の注意点とAHVにおけるGeneration IDの対応

Nutanix MoveでActive Directoryのドメインコントローラー(以下、DC)を移行したいのですが……というご相談を、ちらほらいただくことがあります。

Nutanix Moveを利用したDCの移行については、原則としてサポートされていません。これは、MicrosoftからActive Directory Domain Services(AD DS)の移行手順が正式に公開されているという背景があります。

(参考)Active Directory Domain Services の移行 
https://learn.microsoft.com/ja-jp/training/modules/active-directory-domain-services-migration/

しかし、実際には「ADが稼働している仮想マシンを、そのまま別の仮想化基盤へ移行したい」という要望をいただくことがあります。

ADが稼働している仮想マシンをそのまま移行する際に、理解しておくべき仕組みの1つが「Generation ID」です。

本記事では、Generation IDの意味とNutanix AHV上での取り扱いについて紹介します。


Generation IDとは

Generation ID(VM-GenerationID)は、ハイパーバイザーから仮想マシンに提供されるIDです。Windows Server 2012以降のドメインコントローラーでは、このGeneration IDを利用して、仮想マシン上で稼働するDCの状態が過去の状態へ巻き戻された可能性があることを検知します。仮想化環境では、DCが稼働する仮想マシンを古いスナップショットへ戻すなどの操作を行うと、Active Directoryデータベースも過去の状態へ巻き戻る可能性があります。

このような状態を適切に検知できない場合、他のDCとのレプリケーションに不整合が発生する可能性があります。

このような問題を防ぐため、Windows Server 2012以降のAD DSでは、AD DS内部に保存されているGeneration IDと、現在ハイパーバイザーから仮想マシンに提供されているGeneration IDを比較します。スナップショットからの復元などによってGeneration IDの変更を検出すると、AD DSは仮想マシンの状態が過去へ戻された可能性があると判断し、Virtualization SafeguardsによるSafe Restoreの処理を行います。

この際、AD DSはInvocation IDを新しい値へ変更するとともに、現在保持しているRID Poolを破棄します。

また、正常にレプリケーション可能な他の書き込み可能なDCが存在する場合、そのDCから非AuthoritativeなInbound Replicationを行うことで、Active Directoryの情報を他のDCと整合した状態へ収束させます。

Generation IDに対応したハイパーバイザーでは、スナップショットからの復元など、仮想マシンを過去の状態へ戻す可能性のある特定の操作が行われた際に、仮想マシンへ提供するGeneration IDを変更します。ゲストOS上のAD DSは、ハイパーバイザーから提供されるGeneration IDとAD DS内部に保存されているGeneration IDを比較することで、仮想マシンの状態が巻き戻された可能性を検知し、必要に応じてVirtualization SafeguardsによるSafe Restoreを実行します。


Nutanix AHVにおけるGeneration ID

AHVにおけるVM-Generation IDのサポートは、AOS 6.6.1から提供されています。

(参考)VM-Generation ID support on AHV 
https://portal.nutanix.com/kb/14470


既存のvSphereなどの環境からNutanix Moveを利用してAHVへDCの仮想マシンを移行し、その際にVM-Generation IDが変更された場合、前述の通りVirtualization SafeguardsによるSafe Restoreが実行されます。

Safe RestoreによってAD DSの状態を他のDCと収束させるためには、正常にレプリケーション可能な他の書き込み可能なDCが存在することが重要です。また、Moveによる移行後にAD DSでトラブルが発生した場合、その原因としてはレプリケーション、DNS、SYSVOL、FSMOロールなど、さまざまな要因が考えられます。

このような問題は仮想マシンの移行だけではなく、Active Directoryそのものの設計や運用に関係する問題となります。

そのため、DCの移行についてはMoveによる仮想マシン単位の移行ではなく、新しいDCの追加、FSMOロールの移行、旧DCの降格など、Microsoftが公開しているAD DSの移行手順に沿って実施することが基本的な考え方となります。


Windows Server上でGeneration IDを確認する

Windows Server OS上で、ハイパーバイザーから提供されているVM-Generation IDを確認する方法の一例として、以下のPowerShellを実行します。

Add-Type @"
using System;
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

public class VmGenerationId
{
    [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    static extern SafeFileHandle CreateFile(
        string lpFileName,
        uint dwDesiredAccess,
        uint dwShareMode,
        IntPtr lpSecurityAttributes,
        uint dwCreationDisposition,
        uint dwFlagsAndAttributes,
        IntPtr hTemplateFile);

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern bool DeviceIoControl(
        SafeFileHandle hDevice,
        uint dwIoControlCode,
        IntPtr lpInBuffer,
        uint nInBufferSize,
        byte[] lpOutBuffer,
        uint nOutBufferSize,
        out uint lpBytesReturned,
        IntPtr lpOverlapped);

    public static string Get()
    {
        const uint GENERIC_READ  = 0x80000000;
        const uint GENERIC_WRITE = 0x40000000;
        const uint FILE_SHARE_READ  = 0x00000001;
        const uint FILE_SHARE_WRITE = 0x00000002;
        const uint OPEN_EXISTING = 3;
        const uint IOCTL_VMGENCOUNTER_READ = 0x0032C004;

        using (SafeFileHandle h = CreateFile(
            @"\\.\VmGenerationCounter",
            GENERIC_READ | GENERIC_WRITE,
            FILE_SHARE_READ | FILE_SHARE_WRITE,
            IntPtr.Zero,
            OPEN_EXISTING,
            0,
            IntPtr.Zero))
        {
            if (h.IsInvalid)
                throw new System.ComponentModel.Win32Exception(
                    Marshal.GetLastWin32Error());

            byte[] buffer = new byte[16];
            uint returned;

            if (!DeviceIoControl(
                h,
                IOCTL_VMGENCOUNTER_READ,
                IntPtr.Zero,
                0,
                buffer,
                (uint)buffer.Length,
                out returned,
                IntPtr.Zero))
            {
                throw new System.ComponentModel.Win32Exception(
                    Marshal.GetLastWin32Error());
            }

            return new Guid(buffer).ToString();
        }
    }
}
"@

[VmGenerationId]::Get()

Generation IDに対応した環境であれば、ハイパーバイザーからゲストOSへ提供されているVM-Generation IDを確認できます。


AHV側からGeneration IDを確認する

AHV側では、ACLIを使用して仮想マシンに設定されているGeneration IDを確認できます。

acli vm.get <仮想マシン名> | grep generation


AHV環境では、仮想マシンに対してVM-Generation IDが提供されます。

通常の仮想マシン作成・運用では、Generation IDを利用者が意識して設定する必要はありません。一方、物理サーバー上で稼働しているDCをAHV環境へ移行する場合など、移行元と移行先におけるGeneration IDの取り扱いについて確認が必要となるケースがあります。

AHVでは、仮想マシンの作成時に `generation_uuid` を指定することができます。


1.Generation IDを指定した仮想マシンの作成

acli vm.create <仮想マシン名> generation_uuid=<Generation ID>


2. Generation IDの確認

acli vm.get <仮想マシン名> | grep generation


`generation_uuid` は仮想マシン作成時に指定するパラメーターであり、既に作成済みの仮想マシンに対して任意のGeneration IDへ変更する用途では使用できません。



Generation IDを意図的に一致させる場合の注意点

AD DSは、AD DS内部に保存されているGeneration IDと、ハイパーバイザーから現在提供されているGeneration IDを比較します。

両者が異なっていた場合、AD DSは仮想マシンが以前の状態へ戻された可能性があると判断し、Virtualization SafeguardsによるSafe Restoreを実行します。この際、Invocation IDの再生成やRID Poolの破棄などが行われ、正常にレプリケーション可能な他の書き込み可能なDCとのレプリケーションによってActive Directoryの状態を収束させます。

一方、Generation IDが一致している場合、Generation IDの不一致を契機とするVirtualization Safeguardsは実行されません。

このため、DCをイメージバックアップなどから別の仮想マシンへ復元する際にGeneration IDを意図的に一致させた場合、Generation IDの不一致を契機とするVirtualization Safeguardsが発動しないことになります。

ただし、Generation IDを一致させること自体が、Active Directoryの整合性を保証するものではありません。

Active Directoryでは、Generation IDだけではなく、Invocation IDやUSNなどを使用して、複数のDC間でレプリケーション状態を管理しています。そのため、移行元DCと移行先DCを同時に稼働させたり、バックアップ取得後に他のDCとの間で変更が発生したりすると、Generation IDが同一であってもActive Directoryのレプリケーションに問題を生じさせる可能性があります。

このため、Generation IDを意図的に維持してDCを移行する方法を、一般的なActive Directoryの移行・復元方法として使用することは推奨されません。

DCをバックアップから復元する場合は、原則としてAD DSに対応したバックアップおよび復元方法を使用し、Generation IDによるVirtualization Safeguardsが適切に機能する構成とすることが重要です。


まとめ

ADの移行においてGeneration IDは重要な役割を果たしますが、Generation IDを一致させることだけでActive Directory全体の整合性が保証されるわけではありません。

Active Directoryは、Generation IDだけではなく、Invocation IDやUSNなどの情報を利用して、複数のDC間でレプリケーションの状態を管理しています。

そのため、移行対象以外のDCが稼働し、ユーザーやコンピューター、パスワードなどの変更を受け付けている場合、それらの変更を各DC間で適切にレプリケーションし、整合性を維持する必要があります。

また、Generation IDによるVirtualization Safeguardsは、AD DSのバックアップそのものを代替する仕組みではありません。


このようなActive Directory特有の仕組みがあることから、DCの移行については、原則としてMoveによる仮想マシン単位の移行ではなく、新しいDCの追加、FSMOロールの移行、旧DCの降格など、Microsoftが公開しているAD DSの移行手順に沿って実施することが推奨されます。

どうしてもMoveを利用してDCを移行する場合は、製品のサポート可否を確認したうえで、移行対象外のDCが正常に稼働していることや、DC間で正常にレプリケーションできる状態であることなどを事前に確認してください。また、Generation IDの仕組みだけでActive Directoryの整合性や移行の安全性が保証されるわけではないため、十分な検証とバックアップを行ったうえで、慎重に移行を実施してください。





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の設定確認を行っていきます。