データストアを含む LUN を VMware ESXi/ESX 4.0 および 4.1 から削除する

search cancel

データストアを含む LUN を VMware ESXi/ESX 4.0 および 4.1 から削除する

book

Article ID: 343707

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

この記事には、データストアの中身を削除せずに、データストアが格納された LUN を ESXi または ESX 4.x ホストから提供解除にする手順が記載されています。

注： ESX によるストレージの再スキャン方法は、パッチ ESX400-200912401-BG によって変更されています。詳細については、以下を参照してください：

注：vCenter Server からデータストアを削除した後、そのデータストアを格納する LUN を提供解除にすることは、ほとんどの場合、有効です。ただし ESXi/ESX 4.x では、LUN をマスキングせずに LUN を削除すると、ホストは LUN へのアクセスを永続的に試行するため、ホスト上で全パスダウン (APD) 状態が発生します。詳細については、ESX hosts in APD may appear Not Responding in vCenter Server (1030980) を参照してください。

このような問題を回避するには、LUN をマスキングしてから LUN を提供解除にする必要があります。詳細については、Unmounting a LUN or detaching a datastore/storage device from multiple ESXi 5.x hosts (2004605) を参照してください。

Symptoms:

免責事項：これは英文の記事「Removing a LUN containing a datastore from VMware ESXi/ESX 4.0 and 4.1 (1029786)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

Environment

VMware ESXi 4.1.x Installable
VMware ESX 4.1.x
VMware ESX 4.0.x
VMware ESXi 4.0.x Embedded
VMware ESXi 4.0.x Installable
VMware ESXi 4.1.x Embedded

Resolution

データストアを格納する LUN を ESXi/ESX 4.x ホストから提供解除にするには、次の手順を実行します。

手順 1：該当するボリュームを特定する
手順 2：後で使用するために VMFS ボリュームのデータを残しておかない場合は、データストアを削除する
手順 3：後で使用するために VMFS ボリュームのデータを残しておく場合、またはボリュームがすでに削除されている場合は、ボリュームをマスキングする
手順 4： LUN をアレイから提供解除にする
手順 5：すべてのホストを再スキャンする
手順 6：通常の要求ルールをリストアする

注：これらの手順は、ESX サービスコンソールまたは vSphere コマンドラインを使用して実行する必要があります。これらの手順は、vSphere Client の [パスの管理] ダイアログを使用して実行できません。

手順 1：該当するボリュームを特定する

該当するボリュームを特定するには、次の手順を実行します。

vSphere Client から、削除するデータストアを（名前で）特定します。これが RDM の場合は、手順 3 に進みます。
ホストに対する SSH セッションから、この名前を NAA ID に関連付けます。

関連付けるには、次のコマンドを実行します。

esxcfg-scsidevs --vmfs

出力例：

mpx.vmhba0:C0:T0:L0:5 /dev/cciss/c0d0p5 4a9fd860-6098929b-70e1-001e0b1df518 0 Storage2 naa.60a9800050334c424a6f55566d466f31:1 /dev/sdd1 4b5f0b60-a09c425d-3953-001e0b1df518 0 NetApp_iSCSI naa.6006016033201c00a43a4ab9be9cde11:1 /dev/sda1 4bc37846-18f3c301-2ecb-001e0b1df518 0 delete_datastore

この例では、データストア delete_datastore には NAA ID である naa.6006016033201c00a43a4ab9be9cde11 が関連付けられています。また完全に互換性のある EUI ID または T10 ID が表示されることもあります。
RDM の場合：
1. 該当する仮想マシンの設定を編集し、削除する RDM を選択して、vml.XXX 番号をコピーします。これは次の手順で使用される vml.ID です。
2. 仮想マシンから RDM を削除し、ディスクから削除を選択してから OK をクリックします。これによりマッピングファイルが破棄されますが、LUN の内容には影響しません。
3. ホスト上で次のコマンドを実行します。
  
  esxcfg-scsidevs –u | grep –i vml.ID
  
  このコマンドは、そのボリュームの NAA ID を返します。
ホストに対する SSH セッションから、この NAA ID を vmhba ID に関連付けます。

関連付けるには、次のコマンドを実行します。

esxcfg-mpath –L | grep naa.ID

例：

# esxcfg-mpath -L | grep -i naa.6006016033201c00a43a4ab9be9cde11

出力例：

vmhba1:C0:T1:L1 state:standby naa.6006016033201c00a43a4ab9be9cde11 vmhba1 0 1 1 NMP standby san fc.20000000c9739842:10000000c9739842 fc.50060160c1e0b7ec:5006016941e0b7ec vmhba1:C0:T0:L1 state:active naa.6006016033201c00a43a4ab9be9cde11 vmhba1 0 0 1 NMP active san fc.20000000c9739842:10000000c9739842 fc.50060160c1e0b7ec:5006016141e0b7ec vmhba0:C0:T1:L1 state:standby naa.6006016033201c00a43a4ab9be9cde11 vmhba1 0 1 1 NMP standby san fc.20000000c9739842:10000000c9739842 fc.50060160c1e0b7ec:5006016941e0b7ec vmhba0:C0:T0:L1 state:active naa.6006016033201c00a43a4ab9be9cde11 vmhba1 0 0 1 NMP active san fc.20000000c9739842:10000000c9739842 fc.50060160c1e0b7ec:5006016141e0b7ec

この例では、vmhba1:C0:T1:L1、vmhba1:C0:T0:L1 などの出力の最初の部分は HBA1/0, Controller 0, Target (SP) 1/0, Lun 1 に分けられます。

パスが変わる部分（通常 HBA と Target）と変わらない部分 (LUN) に注目してください。

一部のストレージアレイでは、同じ LUN 番号が使用されますが、Equalogic、Lefthand などのターゲットは変更されます。アレイで異なるターゲットまたは異なる LUN が使用されるかどうかわからない場合は、作業を続けずに、VMware サポートにお問い合わせください。

手順 2：後で使用するために VMFS ボリュームのデータを残しておかない場合は、データストアを削除する

注： RDM の場合は、このセクションを省略してください。

VMFS データストアを削除するには：

vSphere Client を開きます。
データストア ビューを開きます。
削除する VMFS データストアを右クリックして、削除をクリックします。

これに失敗する場合は、作業を続けずに、VMware サポートにお問い合わせください。詳細については、Filing a Support Request in My VMware (2006985) を参照してください。

手順 3：後で使用するために VMFS ボリュームのデータを残しておく場合、またはボリュームがすでに削除されている場合は、ボリュームをマスキングする

この手順では、たとえば、HBA が変化することを考慮してください。この場合、ボリュームをマスキングするための 2 つのルール（HBA1 用と HBA2 用）が必要です。101 から 200 の任意のルール番号を使用できます。この例では、192 と 193 を使用します。

先に進む前に、次のことを確認してください。

データストアが使用中でないことを確認します。
データストアに格納されているすべてのオブジェクトを、仮想マシン、テンプレートなどのインベントリから登録解除します。
サービスコンソール上で、該当する LUN にアクセスできるサードパーティ製のスクリプトやユーティリティが実行されていないことを確認します。

SSH を使用して各 ESX ホストに接続します。
次のコマンドを実行します。

esxcli corestorage claimrule add --rule 192 –t location –A vmhba1 –L 1 –P MASK_PATH esxcli corestorage claimrule add --rule 193 –t location –A vmhba0 –L 1 –P MASK_PATH

ご使用の環境で単一の HBA （またはソフトウェア iSCSI）が使用されている場合は、1 つのコマンドのみを実行する必要があります。

-t location と -P MASK_PATH は必須です。その他のオプションは省略可能であり、ご使用の環境に合わせて使用します。この例では両方の HBA （vmhba0 と vmhba1）と LUN 1 （LUN1 のみをマスキング）を指定しますが、コントローラとターゲットは指定しません（すべてのコントローラとターゲットをマスキング）。LUN を識別するターゲットがストレージで使用される場合は、-T X を使用して適切なターゲットを指定できます。詳細については、この記事の最後の例を参照してください。
各ホストで次のコマンドを実行して、要求ルールをロードします。

esxcli corestorage claimrule load
各ホストで次のコマンドを実行して、要求ルールがロードされたことを確認します。

esxcli corestorage claimrule list

出力例：

# esxcli corestorage claimrule list Rule Class Type Plugin Matches 0 runtime transport NMP transport=usb 1 runtime transport NMP transport=sata 2 runtime transport NMP transport=ide 3 runtime transport NMP transport=block 4 runtime transport NMP transport=unknown 101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport 101 file vendor MASK_PATH vendor=DELL model=Universal Xport 192 runtime location MASK_PATH adapter=vmhba1 channel=* target=* lun=1 192 file location MASK_PATH adapter=vmhba1 channel=* target=* lun=1 193 runtime location MASK_PATH adapter=vmhba1 channel=* target=* lun=1 193 file location MASK_PATH adapter=vmhba1 channel=* target=* lun=1 65535 runtime vendor NMP vendor=* model=*

新しい各ルールに、表示ファイルとランタイム用の新しいエントリがあることを確認します。このエントリは、ルールが保存およびロードされたことを示します。このエントリがない場合は、作業を続けずに、VMware サポートにお問い合わせください。
該当するボリュームを解放するには、すべてのホストで次のコマンドを実行します。

esxcli corestorage claiming reclaim –d naa.ID
手順 1 から 5 がすべてのホストで完了していることを確認します。
次のコマンドを実行します。

ESXi の場合：
grep vmkernel /var/log/messages

ESX の場合：
cat /var/log/vmkernel
コマンドの出力で、次のようなエントリを見つけます。

Apr 12 16:18:03 ds-tse-h12 vmkernel: 4:03:31:44.853 cpu7:4109)WARNING: NMP: nmp_UnclaimPath: Physical path "vmhba1:C0:T1:L1" is the last path to NMP device "Unregistered Device".The NMP device has been unregistered.

警告：このようなエントリがある場合は、作業を続けずに、直ちに VMware サポートに連絡してサポートを要請してください。
- Unable to unclaim path vmhba33:C0:T0:L1 on device naa.60a9800050334c424a6f55566d466f31.Some paths may be left in an unclaimed state.You will need to claim them manually using the appropriate commands or wait for periodic path claiming to reclaim them automatically.注： ESX/ESXi 4.x ホストが vCenter Server 5.x に属し、データストアが HA データストアハートビートに属している場合は、このメッセージが表示されることがあります。別のデータストアを使用するように HA を再構成すると、この問題の解決に役立つ可能性があります。詳細については、Configure Datastore Heartbeating を参照してください。
- Apr 12 16:30:51 ds-tse-h12 vmkernel: 4:03:44:33.242 cpu5:4109)ScsiDevice: 1930: Can't unregister device naa.60a9800050334c424a6f55566d466f31 because it is in use.OpenCount:1 RefCount:2
- Apr 12 16:30:51 ds-tse-h12 vmkernel: 4:03:44:33.242 cpu5:4109)WARNING: NMP: nmp_DeviceUnregister: Could not unregister NMP device "naa.60a9800050334c424a6f55566d466f31".Busy
  
  注：場合によっては、hostd が esx.conf ファイルをロックしていると、前述のログのスニペットが表示されます。このためファイルを変更できず、コマンドが失敗します。この問題を解決するには、ホストを再起動します。

手順 4： LUN をアレイから提供解除にする

LUN がすべてのホストからマスキングされた後に、LUN を SAN 側から提供解除にします。詳細については、ストレージアレイのベンダーにお問い合わせください。

注：ホストおよびアレイ上の NAA ID を確認して、適切な LUN が提供解除になっていることを確認してください。

手順 5：すべてのホストを再スキャンする

すべてのホストを再スキャンするには、次の手順を実行します。

vSphere Client を使用して vCenter Server に接続します。
クラスタを右クリックして、データストアの再スキャン をクリックします。

または各ホストで 構成 > ストレージアダプタ > 再スキャン に移動します。
再スキャンが成功したことを確認するには、すべてのホストから次のコマンドを実行します。

ESXi の場合：
cat /var/log/messages |grep -i apd

ESX の場合：
egrep –i apd /var/log/vmkernel

このコマンドから何らかの出力が返された場合は、VMware サポートに直ちに連絡してください。

手順 6：通常の要求ルールをリストアする

通常の要求ルールをリストアするには、LUN に対して表示されていたすべてのホスト、または以前ルールを作成したすべてのホストで、次の手順を実行します。

手順 3 で作成したルールを削除するには、次のコマンドを実行します。

esxcli corestorage claimrule delete --rule 192

この例では、ルール 192 と 193 に対してこのコマンドを実行します。ご使用の環境は、手順 3 で指定した番号に応じて変わります。
要求ルールを再ロードするには、次のコマンドを実行します。

esxcli corestorage claimrule load
次のコマンドを実行して、作成したルールが削除されたことを確認します。

esxcli corestorage claimrule list

出力例：

# esxcli corestorage claimrule list Rule Class Type Plugin Matches 0 runtime transport NMP transport=usb 1 runtime transport NMP transport=sata 2 runtime transport NMP transport=ide 3 runtime transport NMP transport=block 4 runtime transport NMP transport=unknown 101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport 101 file vendor MASK_PATH vendor=DELL model=Universal Xport 65535 runtime vendor NMP vendor=* model=*

注：以前作成したルールは表示されません。

LUN に対して表示されていたすべての ESXi/ESX ホストで再スキャンを実行します。すべてのホストがクラスタ内に存在する場合は、クラスタを右クリックして、データストアの再スキャン をクリックします。以前マスキングした LUN に ESXi/ESX ホストからアクセスできるようになりました。

Additional Information

付録：ターゲット単位のストレージ

一部のアレイでは、LUN 単位ではなくターゲット単位でストレージが使用されます。Clariion や HP EVA などの従来のアレイでは、各コントローラがターゲットであり、個々のボリュームは LUN 番号で指定されます。Equallogic や LeftHand などのターゲットベースのアレイでは、各ボリュームは個別の SCSI ターゲットであり、それぞれに LUN0 が割り当てられています。このようなアレイでは、esxcfg-mpath の出力は次のようになります。

vmhba33:C0:T2:L0 state:active naa.6000eb395d4b82660000000000000010 vmhba33 0 2 0 NMP …
vmhba33:C0:T1:L0 state:active naa.6000eb395d4b82660000000000000012 vmhba33 0 1 0 NMP …
vmhba33:C0:T0:L0 state:active naa.6000eb395d4b82660000000000000014 vmhba33 0 0 0 NMP …

出力の各行では、LUN 0 に対して L0 が、実際の各ボリュームに対して T0/1/2 が表示されています。

この場合、マスキングコマンドは異なり、LUN の代わりにターゲットをマスキングする必要があります。たとえば次のようなコマンドを実行します。

esxcli corestorage claimrule add --rule 192 -t location -A vmhba33 -T 1 -P MASK_PATH

このコマンドでは、ターゲット 1、LUN 0 をマスキングします。

Removing a LUN containing a datastore from VMware ESXi/ESX 4.0 and 4.1

Feedback

thumb_up Yes

thumb_down No