6.18.1 自動オフライン移行を使用したゲストの移動

Oracle Exadata Deployment Assistant (OEDA)コマンドライン・ユーティリティ(OEDACLI)を使用して、Oracle Linux KVMゲストを別のKVMホストに移行できます。

自動移行プロセス時、ゲストは停止され、新しいKVMホストに移動された後、再起動されます。ゲストは停止するため、この方法はオフライン移行とも呼ばれます。

OEDACLIを使用した自動オフライン・ゲスト移行に適用される要件は次のとおりです:

  • Exadataシステムでは、RoCEネットワーク・ファブリックを搭載した2ソケットのOracle Exadataシステム・ハードウェア(X8M-2以降)を使用する必要があります。

  • Exadataシステムでは、Oracle Exadata System Softwareリリース25.1.0以降を使用する必要があります。

  • Exadataシステムの現在の状態を正確に反映したOEDA生成のエンジニアド・システムXML構成ファイル(es.xml)が必要です。

  • Exadataシステムは、Exascaleストレージを使用してゲスト・イメージ・ファイルをホストするように構成する必要があります。

  • OSユーザーおよびOEDACLIを実行しているサーバーがソースとターゲットの両方のKVMホストでrootユーザーとしてアクションを実行できるように、環境はSSH等価で構成する必要があります。

  • ソースおよびターゲットのKVMホストは、同じExadataシステム構成に存在し、同一のネットワークが表示されている必要があります。

  • ソースおよびターゲットのKVMホストは、同じOracle Exadataストレージ・サーバーにアクセスできる必要があります。

  • ソースおよびターゲットのKVMホストには、以前のExadataライブ・アップデートからの未処理の作業がない必要があります。

  • ターゲットKVMホストでは、ソースKVMホスト上のパッケージと同じかそれより新しいバージョンのOracle Exadata System Softwareパッケージを使用する必要があります。

  • ターゲットKVMホストには、ゲストを収容するのに十分な空きCPUおよびメモリー・リソースが必要です。

    • 仮想CPUは、すべてのゲストに割り当てられた仮想CPUの総数がシステムの物理CPU数を上回るようにオーバーコミットすることが可能です。CPUのオーバーコミットは、過剰に収容されたリソースへの競合するワークロードが十分理解され、同時に発生する要求が物理能力を超えない場合にのみ、実行する必要があります。

    • メモリーをオーバーコミットすることはできません。

  • 移行対象のゲストには、移行プロセス中にゲストが再起動したときに適用される可能性がある、以前のExadataライブ・アップデート操作からの未処理の作業がない必要があります。移行前に未処理の作業をすべて終わらせるか、移行プロセス中に未処理の作業が発生しないようにゲストを再構成してください。

    「Exadataライブ・アップデートについて」および「データベース・サーバーのpatchmgr構文」を参照してください。

  • ゲストの名前は、ターゲットKVMホストで未使用のものにする必要があります。

OEDACLIを使用してゲストの自動移行を実行するには:

  1. OEDACLIを起動し、エンジニアド・システムXML構成ファイル(es.xml)をロードします。

    次に例を示します:

    # ./oedacli
oedacli> LOAD FILE name=exa01.xml
  2. MIGRATE GUESTコマンドを使用して、移行パラメータを指定します。

    基本的なコマンド構文:

    oedacli> MIGRATE GUEST HOSTNAME=guest_name MODE={OFFLINE|OFFLINEFORCE} SRCHOST=source_host TGTHOST=target_host

    このコマンドの説明:

    • HOSTNAME=guest_name: 移行対象のゲストのホスト名を指定します。

    • MODE={OFFLINE|OFFLINEFORCE}: 移行モードを指定します:

      • MODE=OFFLINE: ゲストが正常に停止され、ターゲットKVMホストに移動された後、再起動される自動移行プロセスを実行します。

        このオプションは、ほとんどの場合、動作中のゲストを正常に移行するために使用します。

      • MODE=OFFLINEFORCE: ゲストを正常に停止せずに強制移行プロセスを実行します。

        このオプションは、ゲストまたはソースKVMホストにアクセスできない場合にのみ使用します。たとえば、障害が発生したKVMホストからゲストを復活させる場合です。

    • SRCHOST=source_host: ゲストが現在存在するソースKVMホストの名前を指定します。

    • TGTHOST=target_host: 移行の完了後にゲストが存在するターゲットKVMホストの名前を指定します。

    たとえば、次のコマンドでは、exa01vm01.example.comという名前のゲストがexa01adm02.example.comからexa01adm06.example.comに正常に移動される自動移行プロセスのパラメータを指定します。 

    oedacli> MIGRATE GUEST HOSTNAME=exa01vm01.example.com MODE=OFFLINE SRCHOST=exa01adm02.example.com TGTHOST=exa01adm06.example.com
  3. MIGRATE GUESTコマンドで定義されたアクションを保存してマージします。
    oedacli> SAVE ACTION
oedacli> MERGE ACTIONS
...
Merging MIGRATE GUEST
Action Validated and Merged OK

    MERGEコマンドからの出力を調べて、アクションが検証され、正常にマージされている場合のみ続行します。

  4. エンジニアド・システムXML構成ファイル(es.xml)のコピーを保存します。

    この時点でファイルを保存すると、移行情報が事前デプロイ済状態でマークされたXML構成で確定されます。固有のファイル名を使用してファイルをこの状態で保存すると、変更を追跡できます。

    oedacli> SAVE FILE NAME=exa01.migration-merged.xml
File : exa01.migration-merged.xml saved OK
  5. MIGRATE GUESTコマンドで定義されたアクションをデプロイします。
    oedacli> DEPLOY ACTIONS

    DEPLOY ACTIONSコマンドは、移行を実行するようにOEDACLIに指示します。このとき、ゲストが実際にターゲットKVMホストに移動されます。

    移行プロセスは、明確に定義された一連のステップを使用して実行されます。次のリストに、オフライン移行の移行ステップの順序を示します。

    1. STOP_GUEST
    2. CREATE_BRIDGES
    3. DETACH_INTERFACES
    4. DETACH_VOLUMES
    5. ATTACH_VOLUMES
    6. MIGRATE_GUEST
    7. ATTACH_INTERFACES
    8. STARTUP_GUEST

    OEDACLIセッションの出力には、様々なステータス・メッセージが表示され、各ステップが完了した際にもレポートされます。これにより、移行プロセスをモニターできます。

    一般的な移行セッションからの出力例を次に示します。

    oedacli> DEPLOY ACTIONS
Deploying Action ID : 28 migrate guest hostname=exa01vm01.example.com mode=offline srchost=exa01adm02.example.com tgthost=exa01adm06.example.com
Deploying MIGRATE GUEST
Migrate Guest
Starting Guest Migration : exa01vm01.example.com
Stopping Guest exa01vm01.example.com on KVM host exa01adm02.example.com
Waiting for node : exa01vm01.example.com to be stopped
exa01vm01.example.com is down
exa01vm01.example.com is Down
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step STOP_GUEST completed successfully...
Detaching Network Interfaces for Guest : exa01vm01.example.com on KVM host exa01adm02.example.com
VF POOLS in use in kvmHost exa01adm02.example.com. No need to detach re* interfaces
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step DETACH_INTERFACES completed successfully...
Detaching Exascale Volumes for Guest : exa01vm01.example.com on KVM host exa01adm02.example.com
Unmounting Guest Configuration Files volume /dev/exc/exa01vm01_cfg_82abd35b3cb04643848b556c31e8903f for guest exa01vm01.example.com on kvmhost exa01adm02.example.com.
Removing Guest Configuration Volume entry /dev/exc/exa01vm01_cfg_82abd35b3cb04643848b556c31e8903f for guest exa01vm01.example.com from fstab on kvmhost exa01adm02.example.com.
Removing Guest Configuration Files directory /EXAVMIMAGES/GuestImages/exa01vm01.example.com for guest exa01vm01.example.com on kvmhost exa01adm02.example.com.
Detaching EDV Volume exa01vm01_sys from KVM host exa01adm02.example.com
Detaching EDV Volume exa01vm01_cfg from KVM host exa01adm02.example.com
Detaching EDV Volume exa01vm01_gih01 from KVM host exa01adm02.example.com
Detaching EDV Volume exa01vm01_dbh01 from KVM host exa01adm02.example.com
Detaching EDV Volume exa01vm01_u01 from KVM host exa01adm02.example.com
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step DETACH_VOLUMES completed successfully...
Attaching Exascale volumes for Guest : exa01vm01.example.com on KVM host exa01adm06.example.com
Attaching EDV Volume exa01vm01_sys using device exa01vm01_sys_95d9f89aeacf4e7f8997972b2e1354ff to host exa01adm06.example.com
Attaching EDV Volume exa01vm01_cfg using device exa01vm01_cfg_82abd35b3cb04643848b556c31e8903f to host exa01adm06.example.com
Attaching EDV Volume exa01vm01_gih01 using device exa01vm01_gih01_5ea0689d6e4f4eedbde29fcf3f9f618d to host exa01adm06.example.com
Attaching EDV Volume exa01vm01_dbh01 using device exa01vm01_dbh01_95370e3d9cfe49639c8943a659137265 to host exa01adm06.example.com
Attaching EDV Volume exa01vm01_u01 using device exa01vm01_u01_0b66086a58474595a3d2f00b1bd7bb63 to host exa01adm06.example.com
Mounting Guest Configuration Files volume /dev/exc/exa01vm01_cfg_82abd35b3cb04643848b556c31e8903f for guest exa01vm01.example.com on kvmhost exa01adm06.example.com.
Adding Guest Configuration Volume entry /dev/exc/exa01vm01_cfg_82abd35b3cb04643848b556c31e8903f for guest exa01vm01.example.com to fstab on kvmhost exa01adm06.example.com.
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step ATTACH_VOLUMES completed successfully...
Creating Network Bridge for Guest : exa01vm01.example.com on KVM host exa01adm06.example.com
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step CREATE_BRIDGES completed successfully...
Migrating Guest exa01vm01.example.com from KVM host exa01adm02.example.com to  KVM host exa01adm06.example.com
Enabling autostart for guest exa01vm01.example.com on kvm host exa01adm06.example.com
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step MIGRATE_GUEST completed successfully...
Removing Network Bridges for Guest : exa01vm01.example.com on KVM host exa01adm02.example.com
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step REMOVE_BRIDGES completed successfully...
Skipping NAT bridge removal since this is not a cloud deployment...
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step REMOVE_NAT_BRIDGE_SRC completed successfully...
Skipping NAT bridge creation since this is not a cloud deployment...
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step CREATE_NAT_BRIDGE_TGT completed successfully...
Attaching Network Interfaces for Guest : exa01vm01.example.com on KVM host exa01adm06.example.com
VF POOLS in use in kvmHost exa01adm06.example.com. No need to attach re* interfaces. Proceeding with other post-mgration tasks.
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step ATTACH_INTERFACES completed successfully...
Starting Guest exa01vm01.example.com on KVM host exa01adm06.example.com
Waiting for node : exa01vm01.example.com to be ready
Migrate guest exa01vm01.example.com from exa01adm02.example.com to exa01adm06.example.com. Step STARTUP_GUEST completed successfully...
Done...
Done [Elapsed = 193346 mS [3.0 minutes] Wed Jul 30 16:14:59 PDT 2025]]

    なんらかの理由で移行プロセスが完了しない場合は、OEDACLI出力を調べて原因を特定します。問題を解決した後に、残りのステップを一度に1つずつ実行して移行を完了できます。以前に失敗したステップから始めることを忘れないでください。

    単一ステップを実行するには、MIGRATE GUESTコマンドにWHERE句を指定してステップ名を指定します。次に、アクションを保存、マージおよびデプロイします。次に例を示します: 

    oedacli> MIGRATE GUEST HOSTNAME=exa01vm01.example.com MODE=OFFLINE SRCHOST=exa01adm02.example.com TGTHOST=exa01adm06.example.com WHERE STEPNAME=STARTUP_GUEST
oedacli> SAVE ACTION
oedacli> MERGE ACTIONS
oedacli> DEPLOY ACTIONS
  6. エンジニアド・システムXML構成ファイル(es.xml)を保存します。

    この時点でXML構成ファイルを保存すると、構成の変更が確定し、ファイルは移行完了後のシステム構成が反映されたものになります。固有のファイル名を使用してファイルを保存すると、変更を追跡できます。 

    oedacli> SAVE FILE NAME=exa01.migration-deployed.xml
File : exa01.migration-deployed.xml saved OK

関連トピック

親トピック: 別のKVMホストへのゲストの移動