RDM を含む MSCS ノードによって使用されている RDM LUN を認識できる ESXi/ESX ホストで、起動または LUN の再スキャンに時間がかかる場合がある

search cancel

RDM を含む MSCS ノードによって使用されている RDM LUN を認識できる ESXi/ESX ホストで、起動または LUN の再スキャンに時間がかかる場合がある

book

Article ID: 345013

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

この記事では、特定の問題について説明します。すべての症状が発生した場合は、以下のセクションを参照してください。

一部の症状のみが発生した場合は、Knowledge Base で症状を検索するか、以下を参照してください。

Symptoms:

免責事項：これは英文の記事「ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to start or during LUN rescan (1016106)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

ESXi/ESX 4.x および ESXi 5.x ホストの起動に時間がかかります。この時間は、ESXi/ESX ホストに接続されている RDM の数に応じて異なります。

注：2 つのノードを含む MSCS クラスタで 10 個の RDM が使用されているシステムでは、セカンダリノードでの ESXi/ESX ホストの再起動に約 30 分かかります。RDM 数がこれよりも少ないシステムでは、再起動にかかる時間は短くなります。たとえば、3 つの RDM のみが使用されている場合、再起動にかかる時間は約 10 分です。
ESXi の [サマリ] タブに断続的にエラーメッセージが表示され、vSphere Client が起動できない場合があります。

Cannot synchronize host hostname. Operation Timed out.
ログ画面に、次のメッセージの後に起動を待機中であることが示されます。

Loading module multiextent.
ホスト間で共有 RDM および SCSI 予約を使用して MSCS に参加する仮想マシンがクラスタで実行されていて、別のホスト上の仮想マシンが SCSI 予約を保持しているアクティブなクラスタノードです。
次の手順で遅延が発生します。
- パスの要求および SCSI デバイス検出の開始
  
  ESXi ホストの再起動の vmkernel.log ファイルに（ESXi のバージョンに応じたログファイルを確認するために以下の注を参照）、次のようなエントリが表示されます。
  
  vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353: Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11 vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11) vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672: Command 0x1a to device "naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0
- RDM LUN のパーティションのマウント
  
  ESXi/ESX ホストの再起動の vmkernel.log ファイルに、次のようなエントリが表示されます。
  
  vmkernel: 0:00:08:58.811 cpu2:4098)WARNING: ScsiCore: 1353: Power-on Reset occurred on naa.600601604550250083489d914fbbdf11 vmkernel: 0:00:08:58.814 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:9:0 (naa.600601604550250082489d914fbbdf11) vmkernel: 0:00:09:38.855 cpu2:4098)ScsiDeviceIO: 1672: Command 0x1a to device "naa.600601604550250083489d914fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. vmkernel: 0:00:09:38.855 cpu1:4111)ScsiDeviceIO: 4494: Could not detect setting of QErr for device naa.600601604550250083489d914fbbdf11. Error Failure. vmkernel: 0:00:10:08.945 cpu1:4111)WARNING: Partition: 801: Partition table read from device naa.600601604550250083489d914fbbdf11 failed: I/O error vmkernel: 0:00:10:08.945 cpu1:4111)ScsiDevice: 2200: Successfully registered device "naa.600601604550250083489d914fbbdf11" from plugin "NMP" of type 0
  
  vmkernel: 47:02:52:19.382 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4 vmkernel: 47:02:52:19.383 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4 vmkernel: 47:02:52:19.383 cpu23:9621)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4 vmkernel: 47:02:52:19.383 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4 vmkernel: 47:02:52:19.383 cpu12:4108)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18 vmkernel: 47:02:52:19.383 cpu12:4108)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18 vmkernel: 47:02:52:19.383 cpu3:5733)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18 vmkernel: 47:02:52:19.384 cpu12:9738)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18 vmkernel: 47:02:52:21.383 cpu23:9621)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
既存の VMFS LUN の設定を構成した場合、vmkernel.log ファイルに次のエントリが記録される場合があります。

cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.
cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.
cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.

注：ESX/ESXi の異なるバージョンの vmkernel.log ファイルの場所については、「Location of log files for VMware products (1021806)」を参照してください。

Environment

VMware vSphere ESXi 7.0.0
VMware vSphere ESXi 8.0

Resolution

ESXi 6.0 ホスト

ESXi 6.0 のすべてのホストでは、この記事の以下 3 つのセクションで説明するように、MCSC クラスタ RDM を永久予約に設定するコマンドライン、vSphere Client、および PowerCLI のメソッドが有効です。

ESXi/ESX 4.x

この問題は、2011 年 07 月 28 日にリリースされた VMware ESXi/ESX 4.1 パッチで解決されています。詳細については、次を参照してください。

パッチのインストールに加えて、該当する ESXi/ESX ホストで次の詳細構成オプションを変更して起動プロセスを高速化します。

ESXi/ESX 4.1：詳細オプションの Scsi.CRTimeoutDuringBoot を 1 に変更します。
ESXi/ESX 4.0：詳細オプションの Scsi.UWConflictRetries を 80 に変更します。

詳細構成オプションの変更については、「Configuring advanced options for ESXi/ESX (1038578)」を参照してください。

ESXi/ESX 4.1 で、再スキャンの時間が引き続き長引く場合、問題を解決する最善の方法はホストを ESXi 5.0 にアップグレードすることです。これには、前述の修正が両方とも（つまり、2011 年 07 月 28 日にリリースされたパッチと、詳細オプション Scsi.CRTimeoutDuringBoot を 1 に変更すること）含まれます。

perennially-reserved 設定を既存の LUN で構成する前に、LUN が VMFS LUN としてマウントされていることを確認できます。既存の設定を表示するには、次のコマンドを実行します。

esxcfg-scsidevs -m|grep naa.XXXXXXXXXXXXXXXXXXX

問題「Cannot synchronize host hostname. Operation Timed out」は ESXi 5.0 で修正されました。ESXi 5.0 以降にアップグレードすることをお勧めします。

ESXi 5.0

ESXi 5.0 は異なる方法を使用して、MSCS クラスタに参加している永続的な予約として各デバイスをマークする構成フラグを導入することで、Raw デバイスマッピング (RDM) された LUN が MSCS クラスタデバイスで使用されているかどうかを判断します。ESXi ホストの起動中、デバイスの要求フェーズ時に ESXi ホストに提示されたすべてのデバイスの検出がストレージの中間レイヤーで試行されます。ただし、永続的な SCSI 予約のある MSCS LUN によって、起動プロセスにかかる時間が長くなる可能性があります。これは、別の ESXi でホストされるアクティブな MSCS ノードによって、永続的な SCSI 予約が特定のデバイスに設定されていることが原因で、ESXi ホストが LUN を確認できないためです。

デバイスを永続的に予約する構成は、各 ESXi ホストにローカルです。MSCS クラスタに参加する各デバイスを認識できる、すべての ESXi 5.0 ホストでこの構成を実行する必要があります。これにより、デバイスを認識できるすべての ESXi ホストの起動時間が短縮されます。

vSphere ホストプロファイルを使用したこの設定の適用はサポートされていません。vSphere Auto Deploy を使用してデプロイされた ESXi 5.0 ホストでは、この機能を利用できません。

注：詳細オプション Scsi.CRTimeoutDuringBoot が ESXi 5.0 では無効になっています。

ESXi 5.0 へのアップグレード

ESXi 5.0 にアップグレードするには：

MSCS RDM LUN を認識できるホストごとに、次の手順を実行します。

クラスタ内のすべての仮想マシンをパワーオフする必要があります。
アップグレードの前に、次の手順を実行してホストからすべての MSCS RDM をアンマウントします。
1. MSCS クラスタに含まれる RDM LUN を特定します。
2. vSphere Client から、MSCS クラスタ RDM デバイスへのマッピングがある仮想マシンを選択します。
3. 仮想マシンの設定を編集し、マッピングされた RAW LUN に移動します。
4. [パスの管理] を選択して、それぞれのマッピングされた RAW LUN のデバイスプロパティとそのデバイス識別子 (naa ID) を表示します。
5. このようにして見つけた naa ID をそれぞれメモしておきます。この ID は、RDM のグローバルに一意の識別子です。
6. すべての MSCS RDM デバイスへのパスをすべてホストからマスクします。詳細については、「Masking a LUN from ESX and ESXi using the MASK_PATH plug-in (1009449)」を参照してください。
7. ストレージアレイで、このホストからすべての MSCS RDM デバイスを提供解除します。
ホストを ESXi 5.0 にアップグレードします。詳細については、「Methods of upgrading to ESXi 5.0 (2004501)」を参照してください。
再起動に続いて、そのホストで esxcli コマンドを使用し、各 RDM デバイスを永久予約としてマークします。

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

注：これは、LUN が現在ホストに提供されていない場合でも機能します。
再度 MSCS RDM デバイスをホストに提示し、再スキャンします。
ホストで次のコマンドを実行し、正しいデバイスが永久予約としてマークされていることを確認します。

esxcli storage core device list |less

注：ホストを再起動することで、MSCS デバイスに問題が発生することはありません。

アップグレード済みの ESXi 5.1/5.5 ホスト

すでに ESXi 5.1/5.5 にアップグレードしたホスト上で MSCS LUN を永続的な予約としてマークするには、[ホストプロファイル] で永続的な予約フラグを設定します。詳細については、vSphere ドキュメントセンターの次の各ガイドの「vSphere MSCS 設定のチェックリスト」セクションを参照してください。

RDM LUN を使用して MSCS ノードをホストするホストは、esxcli コマンドを使用してデバイスを永久予約としてマークします。

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

注：Auto Deploy で構成されているステートレス ESXi ホストは、ESXi 5.1 P04、ESXi 5.5 P04 以降を実行している間に起動が遅延する前にのみ永久予約フラグを適用します。これらのビルドでは、デバイス要求の段階で、ストレージミッドレイヤーが ESXi ホストに認識させるすべてのデバイスを検出しようとする前に、ホストプロファイルによって使用される新しいネイティブプラグインによって、永久予約フラグが設定されます。前のビルドで永久予約フラグは、遅延を引き起こすすべてのデバイスを ESXi ホストが要求しようとした後に、ホストプロファイルによって設定されました。

すでに ESXi 5.0 ホストにアップグレード済みの場合

すでに ESXi 5.0 にアップグレードしたホストで MSCS LUN を永続的な予約としてマークするには、この記事の「アップグレード済みの ESXi 5.1/5.5 ホスト」のセクションに記載されている esxcli コマンドを実行します。この後のすべての再スキャン/起動は通常の速度で実行されます。

MSCS クラスタに含まれる RDM LUN を特定します。
vSphere Client から、MSCS クラスタ RDM デバイスへのマッピングがある仮想マシンを選択します。
仮想マシンの設定を編集し、マッピングされた RAW LUN に移動します。
[パスの管理] を選択して、マッピングされた RAW LUN のデバイスプロパティとデバイス識別子 (naa ID) を表示します。
この naa ID をメモしておきます。この ID は、グローバルに一意の共有デバイスの識別子です。
esxcli コマンドを使用して、デバイスを永久予約としてマークします。

esxcli storage core device setconfig -d naa.id --perennially-reserved=true
デバイスが永久予約であることを確認するには、次のコマンドを実行します。

esxcli storage core device list -d naa.id

esxcli コマンドの出力で、エントリ Is Perennially Reserved: true を検索します。このエントリによって、デバイスが永続的な予約としてマークされていることが示されます。
MSCS クラスタに参加しているマッピングされた各 RAW LUN でこの手順を繰り返します。

注：この構成は ESXi ホストで永続的に保存され、再起動後も維持されます。永続的な予約フラグを削除するには、次のコマンドを実行します：

esxcli storage core device setconfig -d naa.id --perennially-reserved=false

PowerCLI 5.0

PowerCLI を使用して MSCS LUN を永続的な予約としてマークする場合は、esxcli 機能を PowerCLI から直接使用できます。esxcli インスタンスを取得し、そのメソッドのいずれかを呼び出します。詳細については、「VMware vSphere PowerCLI Blog」を参照してください。

esxcli インスタンスを取得するには、次のコマンドを実行します。
Connect-VIServer -Server xxx.xxx.xxx.xxx -User xxxxx -Pass xxxxx

esxcli インスタンスを設定するには、次のコマンドを実行します。

$myesxcli= get-esxcli -VMHost ESXhost
デバイスを一覧表示するには、次のコマンドを実行します。

$myesxcli.storage.core.device.list()

PowerCLI パラメータを決定するには、次のコマンドを実行します。

$myesxcli.storage.core.device.setconfig
TypeNameOfValue : VMware.VimAutomation.ViCore.Util10Ps.EsxCliExtensionMethod
OverloadDefinitions : {void setconfig(boolean detached, string device, boolean perenniallyreserved)}
MemberType : CodeMethod
Value : void setconfig(boolean detached, string device, boolean perenniallyreserved)
Name : setconfig
IsInstance : True

デバイス naa ID 別に詳細を一覧表示するには、次のコマンドを実行します。

$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters :
DevfsPath : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device : naa.50060160c46036df50060160c46036df
IsPerenniallyReserved : false
IsPseudo : true

デバイスを永久予約として設定するには、次のコマンドを実行します。

$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $true)

パラメータの更新を確認するには、次のコマンドを実行します。

$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters :
DevfsPath : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device : naa.50060160c46036df50060160c46036df
IsPerenniallyReserved : true
IsPseudo : true

永続的な予約フラグを削除するには、次のコマンドを実行します：
$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $false)

Additional Information

詳細については、「Obtaining LUN pathing information for ESX or ESXi hosts (1003973)」および「Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910)」を参照してください。

注：PowerCLI および esxcli コマンドでは大文字と小文字を区別します。コマンドの発行時に naa.id を大文字で指定した場合、新しいデバイスが ESXi ホストに追加されます。

この記事の解決手順は、次のような NMP エラーを報告するストレージデバイスを解決することも判明しています。

WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.600601604ec0360065efeed9d265e411": awaiting fast path state update for failover with I/O blocked.No prior reservation exists on the device.
この記事が更新されたときにアラートを表示するには、Actions ボックスで Subscribe to Document をクリックします。 ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to start or during LUN rescan

Feedback

thumb_up Yes

thumb_down No