過去に Fault Tolerance を有効化した仮想マシンからのクローンを削除するとクローン元の仮想マシンで Fault Tolerance を無効化できない
search cancel

過去に Fault Tolerance を有効化した仮想マシンからのクローンを削除するとクローン元の仮想マシンで Fault Tolerance を無効化できない

book

Article ID: 436066

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

免責事項:これは英文の記事「If deleting a clone of a virtual machine enabled Fault Tolerance previously, unable to disable Fault Tolerance on the original virtual machine.」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。


Fault Tolerance (FT) の無効化は、エラー「仮想マシンから切断されました。リモートが切断されましたトランスポート接続を確立できませんでした。」で失敗する場合があります。

FT の無効化に失敗した場合、FT プライマリ仮想マシンはパワーオフされ、vSphere HA によって再起動される場合があります。

FT のプライマリ仮想マシンが稼働する ESXi の vmkernel.log にて下記のようなログが記録されています。

YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu0:1042696)WARNING: FTCpt: 9490: (4321607309907569883 pri) FT primary host cannot write checkpoint data to secondary host.
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu2:1042697)WARNING: FTCpt: 10484: (4321607309907569883 pri) FT primary host cannot hear from secondary host.
YYYY-MM-DDThh:mm:ss.fffZ In(182) vmkernel: cpu0:1042696)FTCpt: 9496: (4321607309907569883 pri) Checkpoint writer thread exiting
YYYY-MM-DDThh:mm:ss.fffZ In(182) vmkernel: cpu2:1042697)FTCpt: 10488: (4321607309907569883 pri) Cpt Reader exiting
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu4:1042688)WARNING: FTCpt: 2167: (4321607309907569883 pri) Error starting checkpoint: Already disconnected
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu0:1042688)WARNING: FTCpt: 1667: Failed to rename, try lookup generation file: /vmfs/volumes/<Datastore>/<VM>/.ft-generation
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu0:1042688)WARNING: FTCpt: 1671: Expected not found /vmfs/volumes/<Datastore>/<VM>/.ft-generation, actual: Not found
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu4:1042688)WARNING: FTCpt: 1683: (4321607309907569883 pri) Error renaming .ft-generation1 -> .ft-generation2: Not found
YYYY-MM-DDThh:mm:ss.fffZ Wa(180) vmkwarning: cpu4:1042688)WARNING: FTCpt: 4358: (4321607309907569883 pri) Couldn't change generation number: Not found

Environment

VMware vCenter Server 8.0.x

Cause

この問題は、仮想マシンのディレクトリに FT の世代に関するファイルである .ft-generation# が存在しないために発生します。

仮想マシンのディレクトリから .ft-generation# が削除され、FT の解除に失敗する状況は、下記手順を実行する際に発生します。

手順:

  1. 仮想マシン vm_origin で FT を構成します。
  2. vm_origin で FT を無効化します。
  3. vm_origin のクローン仮想マシン vm_clone を作成します。
  4. vm_origin で FT を再構成します。
  5. vm_clone を削除します。(.ft-generation# が vm_origin のディレクトリから削除されます。)
  6. vm_origin で FT を無効化します。(.ft-generation# が存在しないため、FT の無効化に失敗します。)

手順 2 で FT を無効化した後も .ft-generation のファイルパス (ft.lockFile = "/vmfs/volumes/<Datastore>/<virtual machine name>/.ft-generation") は、仮想マシン vm_origin の vmx ファイルに残ります。そのため、手順 3 で vm_origin のクローンを作成する際に ft.lockFile がクローン仮想マシン vm_clone の vmx にコピーされます。vm_clone の ft.lockFile のパスは、vm_origin のパスと同じため、手順 5 で vm_clone を削除すると ft.lockFile のパスの .ft-generation# も削除されます。その結果、vm_origin のディレクトリには .ft-generation# ファイルが存在しません。

Resolution

FT 構成の無効化に失敗後、仮想マシンのディレクトリに .ft-generation# が再作成されているか確認します。.ft-generation# が存在することを確認できた場合は、再度 FT 構成の無効化を試みます。


本事象を防ぐための事前の対処:

.ft-generation# の削除を事前に避けるためには下記いずれかの対処に従います。

  • vCenter Server 8.0U3i 以降のバージョンへアップデートします。vCenter Server 8.0U3i では、FT を無効化する際の処理にて vmx から ft.lockFile が削除されるよう修正されています。
  • FT の無効化後に下記の回避策を実施します。

   回避策

    1. 仮想マシンで FT を無効化します。
    2. 手順 1 の仮想マシンが稼働する ESXi の CLI へ SSH 経由で接続します。
    3. vi エディタを使用して下記のように vmx ファイルを編集します。

      vi /vmfs/volumes/<Datastore>/<virtual machine name>/<virtual machine>.vmx

    4. 手順 1 の仮想マシンの vmx ファイルから下記エントリを削除します。

      ft.lockFile = "/vmfs/volumes/<Datastore>/<virtual machine name>/.ft-generation"

    5. vmx ファイルを保存します。

Additional Information

この問題の修正情報は VMware vCenter 8.0 Update 3i Release Notes の Resolved Issues の vSphere High Availability Issues に記載しています。

vSphere High Availability Issues

PR 3621023: In very rare cases, during turning off vSphere Fault Tolerance (FT) or an FT failover, the primary VM might fail
In very rare cases, while Fault Tolerance is turning off or an FT failover triggers, the primary VM might fail.

This issue is resolved in this release.