カテゴリー: VMware

投稿日:

ESXi5.1にすると起動しない仮想マシン

ESXi5.1にアップデートした後、NetApp simulatorがなぜか起動しない。

以下のエラーが出力される。 

ディスク「/vmfs/volumes/～/～/DataONTAP.vmdk」、またはディスク「/vmfs/volumes/～/～/DataONTAP.vmdk」が依存しているスナップショット ディスクの 1 つを開くことができません。 
システムで指定されたファイルを見つかりません
VMware ESX は仮想ディスク「/vmfs/volumes/～/～/DataONTAP.vmdk」を検出できません。パスが有効であることを確認し、もう一度やり直してください。

これに対する回答がNetApp comminityにあった。

「OnTap Simulator 8.1.1 no longer running on ESXi 5.1 free」

原因はESXi5.1以降、標準ではvmkernel multiextent moduleが読み込まれなくなったため。
このモジュールは、巨大な１つのvmdkではなく、そこそこの大きさの複数のファイルでvmdkを構成するときに使うもの。

対処方法はVMware KB:「 Powering on a virtual machine after upgrading to ESXi 5.1 fails with the error: File [VMFS volume] VM-name/VM-name.vmdk was not found」にあるとおりのことをする。

概要: multiextentモジュールを読み込んで、分割形式のvmdkから、単一ファイルのvmdkへ変換する。

2019/12/04 追記:ESXi 6.7ではmultiextentモジュールが無くなっているが、vmkfstoolコマンド自体に機能が追加されており、下記のその２の操作が不要となりました。

その１:状況確認

# ls
DataONTAP-cf-flat.vmdk  DataONTAP-s012.vmdk     DataONTAP.vmdk
DataONTAP-cf.vmdk       DataONTAP-s013.vmdk     DataONTAP.vmsd
DataONTAP-s001.vmdk     DataONTAP-s014.vmdk     DataONTAP.vmx
DataONTAP-s002.vmdk     DataONTAP-s015.vmdk     DataONTAP.vmxf
DataONTAP-s003.vmdk     DataONTAP-s016.vmdk     SimConsType
DataONTAP-s004.vmdk     DataONTAP-s017.vmdk     SimUpdateParameters
DataONTAP-s005.vmdk     DataONTAP-s018.vmdk     cfcard
DataONTAP-s006.vmdk     DataONTAP-s019.vmdk     mtoolsrc
DataONTAP-s007.vmdk     DataONTAP-s020.vmdk     nvram
DataONTAP-s008.vmdk     DataONTAP-s021.vmdk     vmware-1.log
DataONTAP-s009.vmdk     DataONTAP-s022.vmdk     vmware-2.log
DataONTAP-s010.vmdk     DataONTAP-s023.vmdk     vmware.log
DataONTAP-s011.vmdk     DataONTAP-s024.vmdk
#

その２: multiextentモジュール読み込み

この手順はvSphere 6.5とか6.7では不要です。

# vmkload_mod multiextent
Module multiextent loaded successfully
#

その３: 分割vmdkのDataONTAP.vmdkを、単一vmdkのDataONTAP-new.vmdkにコピー

下記はzerodthickにしていますが「thin」指定など他のフォーマットでも大丈夫です。

# vmkfstools -i DataONTAP.vmdk DataONTAP-new.vmdk -d zeroedthick
Destination disk format: VMFS zeroedthick
Cloning disk 'DataONTAP.vmdk'...
Clone: 100% done.
#

その４: DataONTAP.vmdkを削除 

# vmkfstools -U DataONTAP.vmdk
#

その５: ファイル名の変更 

# vmkfstools -E DataONTAP-new.vmdk DataONTAP.vmdk
#

その６: multiextentモジュールの読み込み解除

この手順はvSphere 6.5とか6.7では不要です。 

# vmkload_mod  -u multiextent
Module multiextent successfully unloaded
#

その７: 状況確認 

# ls
DataONTAP-cf-flat.vmdk  DataONTAP.vmxf          vmware-1.log
DataONTAP-cf.vmdk       SimConsType             vmware-2.log
DataONTAP-flat.vmdk     SimUpdateParameters     vmware-3.log
DataONTAP.vmdk          cfcard                  vmware.log
DataONTAP.vmsd          mtoolsrc
DataONTAP.vmx           nvram
#

変換完了後、普通に起動できました。

なお、変換後、ついでに仮想マシンハードウェアバージョンを7から上げるか！と13にあげてみたところ、新しい仮想マシンハードウェアではサポートされないデバイスがあったようで起動できなくなりました・・・

投稿日:

ESXi5.1でIntel NICを認識するけど使えないという事象

SupermicroのマザーボードPDSM4+を使ってvSphere環境を構築中、悩んだ点が１つ。

ESXi5.0だと特に問題なく動くのに、ESXi5.1にすると、オンボードNICがvmnicとして認識するけれども通信ができない、という症状。
MACアドレス認識するし、IPアドレスも普通に設定できるのに通信ができない。

いろいろ調べたら解消するための事例を発見。
「VMWare ESXi, SuperMicro X7SB4, Intel 82573, Network trouble, сетевая проблема」と、その元ネタ「VMWare community」を発見

曰く

・Intel NICのうち82573E/82573Lで認識されているもので発生する
・ESXi 5.1をインストールした後に、ESXi5.0からnet-e1000とnet-e1000eドライバを適用せよ
・ネットワークがつながらないのでUSBメモリでコピーする必要あり
　・USBメモリはFAT32フォーマット不可。FAT16でフォーマットする必要あり
　・ESXiにUSBメモリをさす前に「/etc/init.d/usbarbitrator stop」を実行せよ
・「esxcli software vib install -d /vmfs/volumes/datastore1/ESXi500-201207001.zip -n net-e1000e」というような形でファイルはフルパス指定でコマンド実行

で、実際にためした結果、上記以外に以下の注意点もありました。
・ESXiをUSBメモリにインストールしているんだったらLinuxにマウントして直接コピーしてもよい
・さらに新しいESXi5.0のパッチ「ESXi500-201209001.zip」でもokだった。

また、ESXi5.1に最新のパッチ「ESXi510-201212001.zip」を適用しても通信は不可でした。
パッチ適用後、再度、ESXi5.0のnet-e1000eを適用する必要がありました。

2013/03/08追記

正攻法の突破方法として、対応するドライバをコンパイルして使える様にした、という事例を発見しました。

環境さんぷる「ESXi5.1のドライバを作成してみる(intel 82579LM/82574L編)」と、その更新版の「ESXi5.1のドライバを作成してみる(intel I217/I218/82579LM/82574L編)」

Intelで公開されているドライバソースから作成したとのこと。
こちらは、VMwareの署名が無いドライバのため、インストールにはESXiの設定変更が必要です。

ちなみに、ここの人、他にもドライバを公開していました。
・ESXi5.1のドライバを作成してみる(VIA VT6130/VT6122編)
・ESXi5.0のドライバを作成してみる(Silicon Image 3124/3132/3531編)

投稿日:

ESXi5.xでテープ装置を使う

仮想環境において、ゲストOSからFC接続されているテープ装置を使おうとしたら、認識してないようだったので調べてみた。

結論からいうと、VMware KB2013670:「ESX/ESXi でテープデバイスが間違って ALUA デバイスとして認識されてしまう」が該当していた。
2015/12/18追記:現在は「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (2090103)」で公開されている。
2020/09/28追記:「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (1026157)」

対処方法も、上記KBそのままで大丈夫だった。

実際に実行した例について、以下に紹介する。

1. まず認識しているかどうかを確認する
(1)「esxcli storage core path list」を実行する。

# esxcli storage core path list

＜略＞
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
Runtime Name: vmhba1:C0:T4:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 4
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
＜略＞
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
Runtime Name: vmhba1:C0:T5:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 5
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
＜略＞
#

というような感じで「Plugin: (unclaimed)」というデバイスが認識されいている。

(2) VMware上で使える認識になっているか確認する
「esxcli storage nmp device list」を実行する。

# esxcli storage nmp device list
＜略＞
#


こちらの出力結果には出てこない。

2. 該当デバイスのSCSI inquryを調査
(1) SCSIデバイスのスキャンを実行
「esxcfg-rescan vmhba？」を実行。
今回の場合、「vmhba1」で認識されているので「esxcfg-rescan vmhba1」を実行。

(2) ログに出力されたScsiScanを確認。

# grep "ScsiScan" /var/log/vmkernel.log
＜略＞
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T1:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T1:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1582: Add path: vmhba1:C0:T1:L0
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T2:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T2:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.212Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T2:L0
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T3:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T3:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T3:L0
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T4:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T4:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T4:L0
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T5:L0': Vendor: 'HP ' Model: 'D2DBS ' Rev: 'EL01'
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T5:L0': Type: 0x8, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.214Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T5:L0
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
#

こんな感じで出力されている。
該当するものとしては、以下の３種類となる。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

3. 定義の変更
(1) 該当のデバイスに「VMW_SATP_LOCAL」として動作させる設定として、まず定義を設定。
先ほどの例の場合は以下の３デバイスがある。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

今回の場合は、以下のコマンドを実行した。

# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^Ultrium 4-SCSI*"
# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^D2DBS*"
#

なお、SCSI inquryでは文字列末尾につくスペースも重要であるが、このコマンドでは末尾のスペースは無視してくれるようである。

(2) 次に、各デバイスに対して現状、設定されている定義を解除

# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 0 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 1 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 3 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 4 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 5 -L 0
#

(3) 再スキャンを行い、設定した定義を適用
「esxcfg-rescan vmhba？」を実行する。

# esxcfg-rescan vmhba1
#


4. 認識が変わったことを確認
「esxcli storage nmp device list」を実行

# esxcli storage nmp device list
naa.XXXXXXXXXXXXc8
Device Display Name: HP Fibre Channel Medium Changer (naa.XXXXXXXXXXXXc8)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T5:L0;current=vmhba1:C0:T5:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T5:L0

naa.XXXXXXXXXXXX0a
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0a)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T2:L0;current=vmhba1:C0:T2:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T2:L0

naa.XXXXXXXXXXXX0c
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0c)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T3:L0;current=vmhba1:C0:T3:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T3:L0

naa.XXXXXXXXXXXX0e
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0e)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T4:L0;current=vmhba1:C0:T4:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L0

＜略＞

naa.XXXXXXXXXXXX08
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX08)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T1:L0;current=vmhba1:C0:T1:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T1:L0
#
投稿日:

クライアント端末にディスクイメージを配布するVMware MIRAGE

VMwareから新しい仮想デスクトップ向けのプロダクト「VMware MIRAGE」というのが登場。

・・・いや、詳細を見ていくと「仮想デスクトップ」と言えるかは、かなり微妙なんだけど、とりあえずVDIというくくりになるとは思う。

概要をみると、だいたいやりたい方向性としてはCitrix Xen Clientと似てる。
（Xen Clientは、ハードウェア制限が結構きびしいけど、これはどうなんだろうか？）

さて、とりあえず、ざらっと見た感じの特徴。

・VMware ViewはESXi上で実際のマシンが動いていたけど、これはクライアント端末上で動かす感じ
・クライアント上で仮想マシンを動かしているわけではない
　クライアント上でHypervisorを動かし、その上でクライアントOSを動作させている訳ではなく、ディスクイメージから直接Windows OSを起動している
・ディスクイメージ自体は仮想化技術の応用をしている
・クライアントとして使用できるのは以下のOS
　「XP SP2」「XP SP3」「Windows 7」
・Windowsライセンス上は各クライアントの物理マシンで直接Windowsが動作、という感じ

・各個別のクライアント端末上に存在するディスクイメージは以下に分割される
　・ベースOS部分(Driver Library Layer/Base Layer/Departmental Application Layper)
　・各ハードウェア固有差分(Machine Identify Layer)
　・ユーザ固有のアプリケーション差分(User Application Layer)
　・ユーザ固有の個人情報/デスクトップ情報など(User Data Settings Layer)
・上記のディスクイメージは、VMware Mirage Serverに転送され管理される
・OSパッチ/アプリケーション追加などはMirage Serverから行い、
　差分情報だけがクライアント端末に配布される。
・クライアント端末のハードウェアが複数あっても共通化可能

・Mirage ServerはWindows Server 2008R2上に立てる
　物理/仮想はどちらでも良い

不明な点
・クライアント端末のハードウェア制約
・導入によるクライアント端末のパフォーマンス低下の度合い
・プレインストールのクライアント端末が大量にある場合のMirage環境へのマイグレート手法

投稿日:

NetAppの仮想ストレージData ONTAP Edge

NetAppから「Data ONTAP Edge」というプロダクトが出てきた。

vSphere5環境で動作する仮想マシンとしてNetAppを動かして、NAS共有ストレージとして利用する、というもの。

ぶっちゃけ、これまでず～っとあった、検証用に提供されていたData ONTAP Simulatorを製品化しちゃったようなもの。
使い続けるためには有償となるようだが、コストに関しての記述が無かったので詳細不明。

利用可能ストレージサイズの最大が「5TB」なので、利用用途は大規模環境ではない感じ。

Data ONTAP Edgeを要求要件
・仮想マシンに2CPU以上割り当て（可能な限り占有させること）
・メモリは4GB以上（可能な限り占有させること）
・OS領域は57.5GB必要
・仮想ディスクを置く領域はキャッシュがバッテリーバックアップされたRAID上のVMFS3/VMFS5であること
・１本の仮想ディスクサイズは50GB～2TBまでを選択できる。
(何本まで増加できるか明記は無し）

特色
・Data ONTAP的にはクラスタモード(旧来の7-Modeではない)
・標準ライセンスに重複排除/SnapVault/SnapRestore/FlexCloneが含まれている
→ 小規模リモートオフィスにEdgeを置いて、中央のNetAppでバックアップ、的な感じ

いままでのSimulatorでもいい感じで使えてたので、Edgeになったからといって、特段かわりそうもないですが、とりあえず評価版の入手が可能です。

評価版はData ONTAP Edge Evaluationから入手できますが、NetApp Nowのアカウントが必要です。

また、NetAppのコミュニティーにData ONTAP Edgeに関する掲示板も出来ています。
Welcome to the Data ONTAP Edge CommunityにていろんなQ&Aを確認することができます。