月別アーカイブ: 2018年5月

vSGA調査結果(Quadro4000,FirProW7000 for vSGA ドライバ情報)

今、ESX5.x系でvSGAを使用するためにQuadro 4000を使用しています。

vSGA(Virtual Shared Graphics Acceleration)は、
ESXi仮想マシンの標準GPU(VMware SVGA)をGPUのハードウェアを使用して高速化するものです。
仮想マシンからは普通の「VMware SVGAアダプター」として認識しているが、DirectX9.0cとOpenGL2.1が高速化されます。
なお複数の仮想マシンからは、VGAのメモリが許す限り同時に利用できます。
vMotionなども普通に可能なため、非常に使い勝手のよい技術になります。

なお、いままでコミュニティレベルで実施され、通称「GPUパススルー」とかいわれていた、
VGAをPCI パススルーで仮想マシンに直接接続し、仮想マシンからGPUの全機能を使用可能するものは、VMwareから正式に vDGA(Virtual Dedicated Graphics Acceleration)という名称がつきました。こちらは1GPUごとに1仮想マシンが対応となります。
PCI パススルーを使用しているので、vMotionや電源On中の仮想マシンリソースの拡張等はできなくなります。(ESX6.7でvMotionが出来るようになるかもしれません)。

またこの拡張で、vGPUやMxGPUという技術もありますが、これはGPU側の機能で1枚のGPUを複数の論理GPUとして分割し、論理GPUを仮想マシンに接続できるようにするものです。
こちらもPCI パススルーを使用しているので、vMotionや電源On中の仮想マシンリソースの拡張等は出来ない制限がありますが、ESX6.7でvGPUの場合のvMotionは可能になるようです。

 

Quadro 4000の概要は、以下の通りです。
(Fermiコア,CUDAコア256,メモリ2GBG DDR5,PCI-e 1Slot)
(最大消費電力142 W,電源補助ケーブル必須[シングル6ピン])

 

Quadro 4000 の ESX5.5U3での認識情報

ただ、Quadro4000はすでにVMware Compatibility Guideからも削除されており、NVIDIAのドライバの詳細にも書かれておらず、なかったもの扱いされている状態です。

VMware Compatibility Guide for vSGA ESX5.5U3

 

現在ESXi5.5使用できているQuadro4000用ドライバは 319.65というものです。
NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65.zip

このドライバでサポートしているGPUは以下の通りですが、このバージョン以降はQuadro 4000サポートがなくなっているとの情報もあります。

なお、ESXi5.1の頃は、以下のドライバが使用可能でした。
NVD.NVIDIA_bootbank_NVIDIA-VMware_304.76-1OEM.510.0.0.802205-999851.zip
(NVIDIA-VMware-304.76-1OEM.510.0.0.802205.x86_64.vib)

すでに、Quadro4000はESX6.0用のNVIDIA sVGAドライバでは認識しないとの情報もあることなので、現状Quadro4000は、ESX5.5U3までしか対応していないことになります。

 

ドライバのインストール方法は、この辺とかこの辺とかが参考になります。

現在、ESXi6.0U3へのバージョンアップを検討していますが、Quadro4000が対応していない以上、vSGAをあきらめるか、別のカードを使用するかですが、NVIDIAの対応カードですと最近のビジネス用ハイエンドGPUしか対応しておらず、価格帯も中古でも2桁万円Over、下手すると3桁万円クラスなので、Home Lab用としてはなかなか手が出せません。

こんな情報もありましたが、ちょっと怖いですね。

 

で、色々調査した結果、AMDのFirePro W7000というGPUであれば、
ESX5.5およびESX6.0までの対応であれば比較的入手が楽そうであるとの情報を見つけました。

FirePro W7000 for vSGA情報(VMware Compatibility Guide)

現状、AMD GPUでESX6.5以上ではMxGPUで対応する用で、AMDのvSGAサポートががVMware Compatibility Guideでも認証されていない状況のようなのでESX6.5にあげることはできなさそうですが、どうせESX6.5以上になるとvSphere Client(C# Client)が使えなくなるのでまずはESX6.0にあげられるだけでも助かります(ちょっとvvolをつかってみたいので)。

 

というわけで、FirePro W7000 GPUを入手しました。

ちなみに、ドライバは、以下のものが使用できそうです。

 

esxi5.5用
https://support.amd.com/en-us/download/workstation?os=VMware%20vSphere%20ESXi%205.5#pro-driver
vSGA用ドライバ
fglrx-12103.1135534-1oem.550.0.0.1331820.x86_64.zip

esx6.0用
https://support.amd.com/en-us/download/workstation/esxi6
vSGA用ドライバ
vmw-esx-6.0.0-fglrx-12103.1224202-3638089.zip
vDGA用ドライバ
15.20.1041.1004-FirePro-Guest-Windowsx64-Retail.exe

なお、MxGPU対応ソフトウェア郡(S71x0用)のESXi6.0と6.5用のは以下からダウンロードできる模様です。高くて買えないので、情報だけ。

ESX6.0用
https://support.amd.com/en-us/download/workstation?os=VMware%20vSphere%20ESXi%206.0#pro-driver

ESX6.5用
https://support.amd.com/en-us/download/workstation?os=VMware+vSphere+ESXi+6.5#pro-driver

 

とりあえず、Quadro4000が入っているESXi以外は ESX6.0U3にあげたので、
そのうちFirePro W7000に挑戦して、こちらもあげようと思います。

(参考:https://community.spiceworks.com/topic/1749384-vmware-horizon-vsga-amd-w7000)

 

 

ESXiの仮想マシンのハードウェアバージョンのダウングレード

ESXiの仮想マシンで誤ってハードウェアバージョンをあげてしまった場合、
そのとき仮想マシンを動かしていたESXiのバージョン以下のESXiで動かせなくなってしまいます。

公式には、以下の方法でダウングレードするとなってます。

  • 仮想マシン ハードウェアをアップグレードする前に作成したスナップショットに戻す
  • VMware vCenter Converter Standalone を使用して、[ターゲットの指定] ウィザードで必要な仮想ハードウェア バージョンを選択してコンバート
  • 必要なハードウェア バージョンで新しい仮想マシンを作成し、仮想マシンから既存のディスクを接続。

ハードウェアバージョンをあげる前にスナップショットを取っている場合は戻すだけですが、他の2つを選択した場合でも、いままでのログや稼動情報が消えてしまいますし、ダウンタイムがかなりとられます。

この場合の裏技ですが、実は、ハードウェアバージョンをあげる作業というのは、仮想マシンの定義ファイル(.vmx)のあるパラメータを書き換えているだけだったりします。

ですので、.vmxファイルを直接書き換えれば、ダウングレードできてしまいます。

該当するパラメータは、以下とおりです。

  • virtualHW.version = “11”

この”11″を該当するHW番号に書き換えて保存し、
仮想マシンの編集などをせずにそのまま仮想マシンを起動します。

書き換えるハードウェアバージョンは以下のURLが参考になります。

ESXi/ESX ホストおよび互換性のある仮想マシンのハードウェア バージョンのリスト (2020181)

すると、書き換えた内容が認識され、ハードウェアバージョンがダウングレードされて起動します。

アンサポート的な作業ですが、覚えておくといざとなってときに便利です。

 

 

Z800からZ820へのESXi環境移行&リソース増強完了

先月中旬にマザーボード不良で突然死したHP Z800ですが、
後継機種であるHPZ820を調達し、拡張パーツの移植を行い、一旦暫定対応し、
必要なパーツを取り寄せてどうにか、ハード的に復旧&リソース増強が完了しました。

主な仕様と変更点は以下のとおり

HP Z800 WorkStation HP Z820 WorkStation 備考
CPU Xeon x5690  Dual
[Westmere EP]
(6コアx2CPU, 2.7GHz,)
Xeon E5-2687W     Dual
[Sandy Bridge-EP]
(8コアx2CPU, 3.10GHz)
冷却方式 水冷モデル 水冷モデル
MEM 192GB
(DDR3 Registerd 1333MHz 16GB*12)
256GB
(DDR3 Registerd 1333MHz 16GB*16)
ただし、Z820は1333MHzメモリは未サポート
ストレージアダプタ SATA 3Gbps 6ポート
SAS    3Gbps 8ポート
SATA 6Gbps 2ポート
SATA 3Gbps 4ポート
SAS   6Gbos 8ポート
ストレージ
(VMFS領域)
SSD 960GB
SSD 960GB
SSD 240GB
SATA 4TB x 3
SSD 960GB
SSD 960GB
SSD 240GB
SATA 4TB x 3
一部領域をNexentastorでNFS領域として提供
(RSIDZ 2TBx3で実効領域約4TB)
ストレージ
(NFS仮想マシンへ直結)
SAS 300GB x4 SSD 120GB
SSD 120GB
SSD 480GB
SATA 8TB x4
Nexentastoreでnfs領域を提供
RAID10(8TB x4、j実効領域約16TB)
Logデバイスとして120GBx2
Cacheデバイスとして480GB
NIC GB ether x2
Gb ether x1
GB ether x2  (E1000e,E1001e)
Gb ether x1  (E1000)
2ポートは通常ネットワーク用
1ポートはストレージネットワーク用
Graphiceボード Quadro 4000 Quadro 4000
Quadro K2000
Quadro 4000はブート兼、vSGA用
Quadro K2000はvDGA用(予定)
USBポート USB 2.0 (内蔵) USB 2.0 (内蔵)
USB 3.0 (内蔵)
USB 3.0 (増設)
増設USB3.0ボードはUSB3.0RX4-P4-PCIEで、仮想マシンに直結
OS ESXi 5.5U2 ESXi 5.5U2 ESXi 5.5 U3にアップ予定

こんな感じになりました。

Z800とZ820は、後継機種だけあって、内部仕様やベイの数がほぼ同じなので、その点は楽でした。
ただ、ストレージアダプタのうち、SATA4ポートの認識がZ800と異なっており、ESXi上でHDD上のVMFS領域がそのままマウントせずに、調整が必要だったのが少し大変でした。

これで、もう少し戦えます。

 

厄除け & おかいもの (2018/05/01)

なんかここ半月ぐらいで、お家のいろんなものが壊れまくっている

  • 送風機
    電源入れても起動せず
    ->予備機と交換
  • サーバ(HP Z800:メインESX)
    仕事から帰ったら電源落ちてた。どうやらマザーボード不良
    ->HP Z820を購入し、Z800から拡張パーツを移植するニコイチ修理で回復
  • サーバ(NEC GT110b:サブESX)
    Z820への換装完了後再起動したら、OS立ち上がらず。BIOSでSATAコントローラ認識してない。
    ->予備のNEC GT110bを引っ張り出してきて、ニコイチ修理で回復
  • hdd1台(WDC WD40EFRX)
    ZFSによるRAIDで使用していたがエラーがでてFAULTED状態に。業務影響なし。
    ->同型HDDをAmazonで購入し、交代して対策
  • 部屋の上の蛍光灯照明器具
    紐を引っ張っても、明かりが消えず・・・寝たいんですけど。
    ->引越しのときにあまっていた蛍光灯照明器具と交換。

が、一斉にではなく、1つづつ壊れていっている状況。
既に全部復旧済みですが、 あまりに故障がつづくので、ちょっと神田明神にお参りにいって、「招福除災」のお守りもらってきましたのでマシンルームに飾っておきました。

 

ついでに、秋葉原でお買い物

今回の収穫物

 

ついでに、本日5/5頃に到着予定だったメモリが、5枚ほど到着しました。
DDR3 Registerd 16GB(PC3L-10608R-09-11-E2-03)

4枚をいまZ820に入っている8GB 4舞と交換して、残りは予備予定。
これで、Z820のメモリが256GBになります。

 

さて換装しよっかな

 

仮想環境内で実行中のNexentastorのDisk交換(Raidを組んでいないESXIのDisk交換)

うちの仮想環境では、ESXIの仮想マシンとして、NexentastorというストレージOSを実行し、RAIDとNFS機能をESXiに提供しています。

で、いつの間にか1つのプールがデグレートしていたので、確認と対策です。

RAIDZ-SATA-1のc2t1d0の調子が悪いようです。
修復コマンド[zpool clear RAIDZ-SATA-1]も試してみましたが、少し経つとまたデグレートします。

c2t1d0は、ESXiが直接認識しているSATA HDD上のVMFS5上にあるVMDKが実態です。確認してみます。

実際に調子悪いデータストアは、VMSV03-SATA-5のようです。
この情報は控えておきましょう。
特に、HDD番号、ファイルパス、容量、ディスクSCSI IDは控えておきましょう。

VMSV03-SATA-5を丸ごと交換しますので、このデータストアを使用している仮想マシン名と、割り当てしているVMDKを控えておきます。(今回は、Nexenta仮想マシンの1台のみ)
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。

では、ESXiのデータストアで、VMSV03-SATA-5の情報を確認します。

対象ディスクのIDは、naa.50014ee2ba5bb332のようです。
(esxcli storage vmfs extent listコマンドでも確認できます。)

ESXiのコンソールから、naa.50014ee2ba5bb332の詳細情報を確認します。

VMSV03-SATA-5のDisk(naa.50014ee2ba5bb332)の実態は、
“WDC WD40EFRX-68W”
とのことです。

ESXiのストレージアダプタのところで、naa.50014ee2ba5bb332を探すと、
ストレージアダプタが「Patsburg 4-Port SATA Storage Control」で
ランタイム名が「vmhba2:C2:T0:L0」となっています。

Z820でいうと、内蔵SATAポートのうち、3Gbps対応4ポートの3番目に接続されているHDDですね。

できれば交換用パーツも同型番がよいので、WDC WD40EFRXを用意します。
(Amazonの翌日配送すごく便利)

また、今回のように仮想マシン内でRAIDを組んでいるディスクであれば不要ですが、そうでない場合は、できるだけデータストア「VMSV03-SATA-5」上の仮想マシンデータ(vmxやvmdk)を別のデータストアに待避しておきましょう。
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。
(今回はHDDの死に掛け状態でデータの待避する余裕がありましたが、完全にHDDを認識しなくなる場合もありますので、バックアップやRAID化による冗長化をお勧めします。)

交換用パーツが用意できたら、壊れたHDDを交換します。
HDDのホットプラグに対応していなければ、一度PCの電源断が必要です。

交換したら、ESXiのストレージで、対象のDiskがなくなっていることを確認します。もし、まだあるようであれば、違うDISKを交換したということです。
すぐに正しいDIskと交換しましょう。

では、交換したDiskをストレージの追加からESXiに認識させます。
ストレージから、ディスク/LUNとして追加させますが、ここで注意が1つ。
ESXiをvCenterで管理している場合、以前使用していた「VMSV03-SATA-5」というデータストア名は使用できません。(vCenterで以前のデータストア名に仮想マシンが紐付けされてしまっているため)
とりあえず、「VMSV03-SATA-5-2」と名前を変えて、追加します。

新しいディスクをデータストアとして登録できたら、以前のデータストア「VMSV03-SATA-5」に日も図いていた仮想マシンのVMDKを修正していきます。
vCenterで管理していれば、データストアの「VMSV03-SATA-5」に仮想マシンが登録されていますので、順次該当ディスクの割り当てを変更していきます。
該当ディスクかどうかは、仮想マシンの編集から、ハードディスクをクリックして、ディスクファイルが、「VMSV03-SATA-5」で始まっているものを確認します。状態が認識できていないので、サイズが0となっているのでこちらも確認して、削除しします。

そのまま、Diskを新しいデータストア「VMSV03-SATA-5-2」に割り当てします。控えておいた以下の情報を元に、Diskを以前と同様に追加していきます。
(容量、ディスクSCSI IDは必ず一致させましょう。)

 

すべての仮想マシンのディスク割り当てを同様に修正していきます。
データストアに紐ついた仮想マシンがなくなれば、vCenterから以前のデータストア「VMSV03-SATA-5」が削除されます。

以前のデータストア「VMSV03-SATA-5」が削除されたのを確認したら、今回追加した新しいデータストア「VMSV03-SATA-5-2」を「VMSV03-SATA-5」にリネームします。

これで、vSphereとしては、復旧完了です。

 

Nexentastorで実施しているRAID冗長化は、Nexentastorの仮想マシンを起動すれば、自動的に新しいDISKが挿入されたことを確認して、リビルドが開始されます。
(リビルドが実行されない場合は、NexentastorのWeb GUIからreplaceを実施)

約9時間後にリビルド完了

 

 

(余談)
取り外しした調子の悪くなってしまったHDDですが、別のWindows PCにUSBで認識させて「Crystal Disk Info」で確認してみましたが、そんなにひどい状況ではありませんでした。
・代替処理済みのセクタ数         0
・代替処理保留中のセクタ数    3
・回復不可能セクタ数    3

正直、このHDDをVMFS領域として使用するのはためらわれますが、
NTFSで完全フォーマットすれば一時ファイル領域としてはまだつかえそうなので、NTFSでフォーマットしようとしますが、今の状態ですと領域開放でできません。

VMFS5でフォーマットされたディスクはWindowsからは認識できないのと、
「GPT保護パーティション」がかかっているため、ボリュームの削除ができません。

GPT保護パーティションを開場するためには、DiskPartでコマンドを実行する必要があります。

・Diskpartを起動
・list Disk  (対象ディスクを確認)

・select disk 3     (対象ディスクを選択)
・list partition (確認)
・clean       (保護パーティション属性のクリア)

http://www.atmarkit.co.jp/ait/articles/1106/10/news117.htmlWindowsでGPT保護パーティションを削除する

以上の作業で、VFS領域がクリアされます。
後は、完全フォーマットを実施してみて、smart値が正常に戻ればも儲けものです
(完全フォーマット開始から24時間ほどかかって現在61%完了。)
(この時点でsmart値がすべて正常に戻りました。)
(このHDDはまだがんばってもらえそうです。)