HP Workstaion Z820,Z620,Z420 のファームウェアダウングレード方法

ファームウェアのダウングレードしようとしたら、現在よりもバージョンが古いと更新しようとしても、スルーされてしまい困った。

で色々調べたら、強制的にダウングレードする方法がわかったので、メモです。

どうやら、Fail-safe BootBlock Recovery Modeというものがあるらしく、強制的にUSBメモリ上のBIOSで起動する技あるみたいです。（「Crisis recovery jumper」ジャンパによるモード切替）

https://h30434.www3.hp.com/t5/Business-PCs-Workstations-and-Point-of-Sale-Systems/Crisis-Recovery-Jumper-Z620-Z420-Z820-Revealed/td-p/6658619

Google翻訳の結果だけど、こんな感じです。

１．ZX20ワークステーションには、マザーボードへのBIOS .binファイルのロードを強制するために使用することができるマザーボードヘッダE15があります。この3ピンジャンパの位置は、テクニカルマニュアルに部分的に記載されていますが、Z420 / Z620のほぼ同一のマザーボードの位置は、Z820マザーボードの位置と同じです。 Z220 SFFとCMTのマザーボードには2つの異なる位置があり、それらはマニュアルに文書化されています。再起動とコールドブートには大きな違いがあります（電源が完全に切られた状態から）。以下の指示に正確に従ってください。
２．ワークステーションの電源を切り、電源コードを抜きます。
３．ジャンパ位置をブリッジピン1-2（デフォルトの状態）からブリッジピン2-3（危機の回復位置）に変更します。 Z420 / Z620 / Z820では、E15マザーボードヘッダは一番下のPCIホワイトコネクタと次に上のPCIeブラックコネクタの間にあります。 1番ピンは左端（ワークステーションのバックプレーンに向かって）です。［注意：ピンの状態について修正しています］
４．ターゲットのBIOS .binファイルがドライブの最上位にある非NTFSフォーマットの小型USB2ドライブを用意し、それをワークステーションの最前面のUSB2ポートに差し込みます。後部のUSB2ポートも使用できます。 USB3ポートを使用しないでください。 Z420 / Z620バージョン1および2ワークステーション用の現在の4/18 BIOSの場合、BIOSは3.92で、サムドライブにある.binファイルはJ61_0392.binという名前になります。これは、BIOS SoftPaqから自動的に解凍し、Cドライブのルートレベルに作成されたSWSetupフォルダに移動してから、SWSetupに作成されたソースSP84163フォルダに移動し、そのDOSフォルダに移動することによって取得できます。そこにあり、その.binファイルをコピーします。フォルダ表示タブのコントロールパネルで、既知のファイルタイプの拡張子を隠すのをやめて、見つけやすくすることができます（この設定は常にオフになっています）。
５．電源コードを接続し、電源を入れて、しばらくお待ちください。USBスティックが点滅し、ワークステーションから7つの赤いランプが点滅するのを確認します。今待って….ワークステーションは自動的に再起動します、何も触れないでください！
６．再起動してUSBスティックが点滅し、赤いライトが点滅します（ただし今回は8）。その後数秒後にワークステーションのライトが青くなり、BIOSがオンになります。まだタッチしないでください。
７．ワークステーションが再起動し、BIOS画面が表示されます。今すぐUSB STICK OUTを引くと、BIOSファームウェア自体がフラッシュします。
８．これでワークステーションは自動的に再起動し、9回点滅してから自動的に自動的に終了します。
９．電源コードを抜き、忘れずにリカバリージャンパーをデフォルトの位置に戻します（ピン2-3を繋ぐ）。つまり、プロセスを開始する前に見つけたピンの一番右端に戻します。
10.電源コードを接続し、電源を入れてBIOSの設定を復元すると、BIOSは正常に動作するようになります。

注意としては、USB2.0のUSBメモリを利用すること。USB3.0のUSBメモリだとうまくいきませんでした。あと、FATかFAT32でフォーマットしてください。

また、上記にも書かれていますが、ワークステーションの最前面のUSB2ポート（３つあるうちの一番上）にUSBメモリを刺す必要があります。USB3.0だと認識しません。

それと、ビデオカードを複数枚さしている場合は、１枚にしてやったほうがよさそうです。
Step7で画面にUSBメモリに入れたBIOSで起動し、その後そのバージョンでBIOS更新が行われます。私の場合、電源OFF後に自動的に起動してしまうため、画面で確認したいと、電源OFFするタイミングがわからなくなります。

参考
https://www.manualslib.com/manual/626336/Hp-Z220-Sff.html?page=45#manual

MeltdownとSpectre対策のチェック方法

コメントを残す

https://volx.jp/inspectre-user-guide

このツール便利。

主導での制御方法はこちら参照

https://support.microsoft.com/ja-jp/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

ESXiのSYSLOG設定するためのメモ

コメントを残す

ESXiのSYSLOG送信設定するためのメモです。

GUIでも出来ますが、
今回はコマンドライン(SSH)で実施します。

また、デフォルトでは、すべてのメッセージをSYSLOGに送信してしますので送信レベルを”Warning”に変更しています。

syslog送信先は、192.168.29.105:512を想定しています。

設定後の反映には、サービスの再起動が必要になります。
(vSphereClientで直接ESXiに接続している場合は一旦切断されます。)

The ESXi Shell can be disabled by an administrative user. See the

vSphere Security documentation for more information.

[root@VMSV02:~] esxcli system syslog config set —loghost=‘udp://192.168.29.105:514’

[root@VMSV02:~] esxcli network firewall ruleset set —ruleset–id=syslog —enabled=true

[root@VMSV02:~] esxcli network firewall ruleset list | grep syslog

syslog true

[root@VMSV02:~] vi /etc/vmware/hostd/config.xml

<!— default log level —>

<level>verbose</level><!— <level/> —>

↓

<!— default log level —>

<level>warning</level><!— <level/> —>

[root@VMSV02:~] cd /etc/vmware/vpxa/

[root@VMSV02:/etc/vmware/vpxa] ls –al

total 16

drwxr–xr–x 1 root root 512 Jul 18 13:05 .

–r—r—r–T 1 root root 3503 Mar 8 07:20 .#vpxa.cfg

drwxr–xr–x 1 root root 512 Jul 21 06:59 ..

–rw–r—r–T 1 root root 0 Mar 8 07:20 dasConfig.xml

–r—r—r— 1 root root 2013 Jul 18 13:05 vpxa.cfg

[root@VMSV02:/etc/vmware/vpxa] chmod +w vpxa.cfg

[root@VMSV02:/etc/vmware/vpxa] vi vpxa.cfg

<log>

<level>verbose</level>

↓

<log>

<level>warning</level>

[root@VMSV02:/etc/vmware/vpxa] esxcli system syslog reload

[root@VMSV02:/etc/vmware/vpxa] /etc/init.d/hostd restart

watchdog–hostd: Terminating watchdog process with PID 34242

hostd stopped.

Ramdisk ‘hostd’ with estimated size of 303MB already exists

hostd started.

[root@VMSV02:/etc/vmware/vpxa] /etc/init.d/vpxa restart

watchdog–vpxa: Terminating watchdog process with PID 34872

vpxa stopped.

[root@VMSV02:/etc/vmware/vpxa]

異常発生しているOS-HDDの交換

コメントを残す

メインの録画環境を動かしているHP Micro Server N54LでOSの入っているHDDで、結構な異常ステータスが見られました。

現状、普通に動かすには問題ないようですが、
一部フォルダをコピーしようとするとエクスプローラが応答を停止したり、
イメージバックアップをとろうとしても途中でとまってしまってバックアップできなかったりと
結構危なげな状況です。

Smartを取得してみると、回復不能セクタが0x37(55)となっているのに、
代替処理中のセクタ数が1と結構ヤバイです。

イメージバックアップが取れないので、普通な方法では別のHDDにリストアできずに、ＯＳ再構築しかないかと思ったのですが、最近はエラーセクターがあっても、クローンが取れる装置が入手できるようになったので、試してみました。

AOK-CLONE-U3
https://www.amazon.co.jp/gp/product/B01MDTXXAA/ref=oh_aui_detailpage_o05_s01?ie=UTF8&psc=1

通常はHDD(2.5インチ、3.5インチ)を２つ接続できるUSB3.0スタンド(UASP対応)として使えますが、エラースキップ対応のクローン機能を持っています。

USB3.0スタンドとしては、USB3.0でPCと接続して、電源を入れれば使えますが、
クローン機能を使う場合は、ちょっと手順が必要です。

注意としては、クローン元のドライブ容量に対してクローン先のドライブ容量は同等または、それより大きい必要があります。また、クローン元、先でAFTと非AFTディスクは合わせたほうがいいです。

１．電源OFF状態でPC未接続にする。
２．クローン元のHDDをHDD1スロットに挿入
３．クローン先のHDDをHDD2スロットに挿入（入れ間違えると、大惨事になるので注意）
４．電源ON（アクセスランプ１，２が青く点滅します。）
５．クローンボタンを５秒間長押しする。（アクセスランプがすべて点滅します）
６．一度クローンボタンを離して、再度押すと、クローンが開始されます。

25%　 50% 　　100%
00～25％　・・　青点滅　消灯　　消灯
25～50％　・・　青点灯　青点滅　消灯
50～75％　・・　青点灯　青点灯　青/緑点滅
75～100% ・・　青点灯　青点灯　緑点灯/青点滅
100%　　　・・　青点灯　青点灯　緑点灯/青点灯　・・・　完了

なお、途中でエラーセクターがあった場合は、25%ランプが赤くなります。
75-100%時と完了時が少しわかりにくいですが、100%ランプでちらつきがなくなれば完了です。

WD20EZRXの2TBから、WD20EARXの2TBへのコピーでだいたい8時間弱かかりました。

後は、コピー先のHDDをＰＣに接続して起動できればＯＫです。

PCのマザーボードによっては、BIOSのDISKの起動順序が入れ替わったりする場合があるので、
その場合は再設定が必要です。
(N54Lの場合は、F10でBIOSセットアップでBoot Orderを再設定)

今回はこの段階で、うまくブートしてくれました。

それでも起動しない場合は、OSの起動ディスクで起動して、ブート領域の際インストールで直る場合もあります。

Windows 7の場合は、インストールディスクで起動してコマンドプロンプトを立ち上げて
以下のコマンドを実行します。

bootrec.exe
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd

これでだめなら、ＯＳの上書きインストールですかね。
新規インストールよりはちょっとは復旧が楽になります。

GPDWin2 届きました。

コメントを残す

GPDwinを使用していましたが、GPDWin2が届きました。
ちょっとだけ触ってみましたが、GPDWinをさらにGame様に特化したような進化をしていますね。

主な変更点
・全体的な高速化（CPU:Core m3,Memory:8GB,SSD:128GB）
・Displayが5.5インチから６インチに変更(解像度は変更なし)
・キーボードが５段から６段に変更
・WSDAキーのキートットの形が変わっていて、感触でわかるようになっている
・L3,R3キーが背面に移動（L3キーはキーボードにも存在）
・スピーカーがキーボード上にステレオで配置され、音がちゃんとステレオで聞こえます。
・Micro HDMIインターフェイス追加

ただ気になった点は以下の通り
・FAN音が結構うるさい（FAN停止スイッチなし）
・満充電時にさらに充電していると、コイル泣き音あり
・Enterキーが横長のため、周りのキーが少し膨らんでいる感じがあり、比較的膨らんでいないように感じるEnterキーが少し押しづらいかも
・一回り大きくなった様に見えるが、ヒンジのでっぱりがなくなってるため、大きさはほとんど変わりません。
・ジョイパットのDirectInputモードがなくなっている
・ジョイパットのマウスモードはちょっとした癖あり（おまけに記載）。
・GPDWinでは、マウスモードでキーボード上のL3,R3がマウスの左右クリックに対応していたため背面ボタン使わないでも操作できたが、GPDWin2では背面ボタン必須

私のように、GAME用途ではなく、リモートコンソール端末として使うような用途だと
一部微妙な点もありますが、正常進化ではないでしょうか。

一応La-mulana2は楽しみにしているのだけれども、
今年7-8月にホントに出るんでしょうか。。。。

おまけ

GPDWin2 ジョイパットのマウスモードの割り当て

左スティック(上,下,左,右)=(w,s,a,d)
十字キー(上,下,左,右)=(上スクロール、下スクロール、PageDown、左キー)
YAXBボタン=(上キー,下キー,左キー,右キー)
左ステック=マウス移動
L1=マウス左クリック
L2=マウス中クリック
L3=ENDキー
R1=マウス右クリック
R2=マウス移動ブースト
R3=下キー

L3,R3,十字キー右あたりはかなり変則的。
おそらくゲームでは便利そうな割り当てなのでしょう。

R3(下キー)は、R1(マウス右クリック)を押してメニューを出してR3(下キー)で選択あたりを想定しているのかな？

十字キー右(左キー)は、左右キーを左手(十字キー右)、右手(Bボタン)で分けて押せるように配慮？

あと、個人的は、L3キーのENDキー割り当ては、ブラウザなどで誤爆しそうなのでやめてほしかったです。

割り当ては、JoyTiKeyあたりで自分でマッピングも手ですね。

コメントを残す

vsphere(ESXi)で仮想マシンが応答なくなって、どうしてもとまらないときの最終手段

一歩間違えると、別のプロセス落としてしまって、取り返しのつかなくなることもあるので、本気で最後の手段

ESXiのコンソールに入って、以下のように操作

最初にPSコマンドで親プロセス番号を確認（麗では、仮想マシン名がwalbrix）。
psで親プロセス番号を確認しますが、２つ目の数字が親プロセス番号(2189879)です。

[root@VMSV02:~] ps |grep vmx |grep walbrix

2190073 2189879 vmx–vthread–7:walbrix

2190074 2189879 vmx–vthread–8:walbrix

2190075 2189879 vmx–vthread–9:walbrix

2190076 2189879 vmx–mks:walbrix

2190077 2189879 vmx–svga:walbrix

2190078 2189879 vmx–vcpu–0:walbrix

2190079 2189879 vmx–vcpu–1:walbrix

親プロセス番号を探したら、kill <親プロセス番号>でプロセスを殺します。

1	[root@VMSV02:~] kill 2189879

EVCを設定していない環境でvMotionとかやると、
コレじゃないと回復できないことがあります。

SXi ホストで仮想マシンをパワーオフできない (2075271)
https://kb.vmware.com/s/article/2075271

PCNETのブラックマーケットで記念にThinkPad L430のジャンク品ＧＥＴ！！

コメントを残す

PCNETのブラックマーケットで記念にTHinkPad L430のジャンク品をＧＥＴ！！

お値段2000円也

とりあえず選んだ理由はUSB3.０インターフェースが１つついていたことのみ。
現地で起動するのは確認できたけど、power-onパスワードがかかっていたので、
それ以上の情報はわからず。

もう一台USB3.0インターフェイスが３つもついていたノートPCがあったけど、
こちらは電源は入るけど、ディスプレイや外部モニタの応答がなかったのであきらめました。

別途Lenovoの電源アダプタ（20Ｖ3.25A）を用意して復活の儀です。
復活できる可能性は五分五分といったところですが、試してみます。

L430のメンテナンスマニュアルを確認してみます。
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/l430_l530_hmm_en_0b48570_02.pdf

power-on passwordの解除は、BIOS Supervisor Passwordがかかっているかどうかで
出来るかどうかが変わります。

Supervisor Passwordがかかっている場合は、パスワードがわからないとどうしようもありません。
（実はマザーボードが見えるまで分解して、とあるチップの足をショートさせることでクリアできるらしい。）

Supervisor Passwordがかかっていなければ、復活の可能性ありです。
作業的には、以下の通り

・電源OFF
・AC Adapterの取り外し
・バッテリパック取り外し
・内蔵のバックアップバッテリの取り外し
・AC Adapterの取り付けと、電源ON

・power-on passwordの解除を確認

・電源OFFとAC Adapterの取り外し
・内蔵のバックアップバッテリの取り付け
・バッテリパック取り付け
・AC Adapterの取り付けと、電源ON
・BIOS 設定のデフォルト設定の保存

以上で復活完了です

大変なのは、「内蔵のバックアップバッテリ取り外し」です。
内蔵のバックアップは、キーボードを取り外したところにあるのですが、
キーボードを取りはずしするには背面カバー（HDDのところ）をはすして、キーボード固定のビスを２本を抜き、キーボードをスライドさせて取り外すとあります。

で、ジャンクのL430の状態ですが、
CPU:Celeron B830 1.8GHz (Sandy Bridge世代:Mobile:DualCore)
MEM:DDR3 メモリ 2GB(キーボード裏。背面側は未搭載)
HDD:抜き取り済み

といった感じでした、ジャンク品にしてはめずらしくメモリが抜かれていませんでしたが、
キーボードの裏側のほうだったので、確かに取り外すほうが大変かもしれませんね。

さて、問題はこのノートの使い道ですが、
ファイルサーバの代わりにするか、
ChromeOS(CloudReady)あたりを試すか悩みます。

Oculus Goを水曜日に公式サイトから注文したらもう届いた。すごい届くの早いな。ただ、セットアップにAndroid5.0以上が必要で、唯一対応していたスマートウォッチのFinow X5でセットアップを実施。400×400のRound液晶だけどなんとかセットアップ完了。後でいろいろ試す予定。

コメントを残す

Oculus Goを水曜日に公式サイトから注文したらもう届いた。
すごい届くの早いな。

ただ、セットアップにAndroid5.0以上が必要で、唯一対応していたスマートウォッチのFinow X5でセットアップを実施。400×400のRound液晶だけどなんとかセットアップ完了。

後でいろいろ試す予定。

Windows7でタスクスケジューラでエラー（Windows7から一度Windows10にアップグレード後に元に戻した環境でご注意を）

コメントを残す

いつの間にか、タスクスケジューラーを開くとエラーメッセージが出るようになっていたみたい。
「タスクイメージは破損しているか、または変更されています。HRESULTからの例外:0x80041321)」

調べてみると、Windows7から一度Windows10にアップグレード後に元に戻した環境で起こるらしい。（何年気づかなかったんだろう・・）

この状態だと、タスクもうまく動いていないみたいだし、再度Windows10にアップグレードする際に問題になりそうなので、今のうちに修正。

修正は、１つ１つ修正していく方法もあるみたいだけど、手順が複雑＆レジストリもいじるみたいなので、ツールを探して対応します。

ツールは、RepairTasksというもので、以下からダウンロードできます。
https://github.com/Dijji/RepairTasks/releases

上記リンクから、以下のものをダウンロードしておきます
・RepairTasks.zip
・Windows7.Tasks.zip

次にツールで修復します。
まずは、RepairTasks.zip　を解凍します。

では、「RepairTasks.exe」を管理者として実行します。

RepairTasksが起動しますので、「Scan」をクリックすると、現在の状態を調査します。

44個の問題が見つかりました。
「Backup Tasks」でバックアップを取った後で、
「Repair」で修復します。

44個のうち、39個が修復され、5つの修復が失敗しました。
失敗したタスクは以下の５つでした。
（複数のマシンで修復を実施しましたが以下の５つは失敗するみたいです）

Recovery of task Microsoft\Windows\PerfTrack\BackgroundConfigSurveyor failed with ‘エラー: タスク XML に、書式設定が正しくない値または範囲外の値が含まれています。(2,8):version:1.5’

Recovery of task Microsoft\Windows\RAC\RacTask failed with ‘エラー: タスク XML に、書式設定が正しくない値または範囲外の値が含まれています。(2,8):version:1.5’

Recovery of task Microsoft\Windows\Shell\WindowsParentalControls failed with ‘エラー: タスク XML に、書式設定が正しくない値または範囲外の値が含まれています。(2,8):version:1.5’

Recovery of task Microsoft\Windows\Tcpip\IpAddressConflict1 failed with ‘エラー: タスク XML に、書式設定が正しくない値または範囲外の値が含まれています。(2,8):version:1.5’

Recovery of task Microsoft\Windows\Tcpip\IpAddressConflict2 failed with ‘エラー: タスク XML に、書式設定が正しくない値または範囲外の値が含まれています。(2,8):version:1.5’

この５つが、残ったエラーになる原因です。
Windowsのtasksフォルダ[C:\Windows\System32\Tasks\]から階層をたどって、
エラーになったすべてのタスクのファイルを削除（もしくは移動）します。

「Microsoft\Windows\PerfTrack\BackgroundConfigSurveyor」であれば、
「C:\Windows\System32\Tasks\Microsoft\Windows\PerfTrack\」フォルダの
「BackgroundConfigSurveyor.で始まるファイルになります」

エラーになったタスクファイルが削除したら、
タスクスケジューラを起動します。

今度はエラーは出ないはずです。（もし出たら、別のことが原因かも知れません。）

一旦、これで修復は完了ですがエラーになったタスクは削除していますので、
必要に応じて再登録します。
今回エラーになった５つのタスクであれば、Windows7の初期タスクですので、
「RepairTasks.zip」と一緒にダウンロードした「Windows7.Tasks.zip」を解凍し、
エラーになったタスクを「タスクのインポート」からインポートします。
(実は５つのうち２つ（1つ目と３つ目）は無効状態のなので、インポートしなくても問題ないのですが、念のため）

ダウンロードしたファイルは.xmlファイルではないので、インポート時のファイル選択時に、すべてのファイル(*.*)にして表示させる必要があります。

タスクが読み込まれますので、そのまま「OK」を押して登録します。

タスクが登録されました。他のタスクも同様に登録します。

これで、復旧完了です。

BSデジタル周波数再編(トランスポンダ変更)に対応したPCでの録画環境設定変更(5/28更新分反映)

コメントを残す

BSデジタル周波数再編(トランスポンダ変更)の影響で、PCでの録画環境の設定変更が必要な模様です。
（特にBonDriverを使用した録画環境の場合は必須の模様）

BS JAPANは普段とっていないので気づきませんでしたが、
5/9夜にNHK BSプレミアム関連でEDCB 9xでエラーウィンドウが出ているので気づきました。
EDCB 10系では、特に何もエラーダイアログは出ていませんでしたが、録画には失敗するようです。
5/22もなんとか、対応完了。
一般に言われていた新しいTSIDが予想と違っていたため、
直前の情報収集が必要でした・・・

某掲示板より

資料(4–TR–B15v6_9–3p4.pdf 7–51頁)によると

トラポン移動で変化するのは、

BSxx = bit8～4 (チャンネル)

TSx = Bit2～0 (TMCC信号内の相対TS番号)

その他のbitは変化しないので、

ディズニーチャンネル

BS07/TS2 -> BS03/TS2

0x4672 -> 0100 011 00111(7:BS07) 0 010(2:TS2)

0x4632 <– 0100 011 00011(3:BS03) 0 010(2:TS2)

BSアニマックス

BS07/TS1 -> BS13/TS2

0x4671 -> 0100 011 00111(7:BS07) 0 001(1:TS1)

0x46D2 <– 0100 011 01101(D:BS13) 0 010(2:TS2)

となるそうだ。

4月16日（火曜）BS JAPAN　完了
5月8日（火曜）NHKBSプレミアム完了
5月22日（火曜）ディズニー・チャンネル、BS アニマックス完了
5月28日（月曜）スターチャンネル 2、スターチャンネル 3 完了

ただ、対策はチャンネルスキャンするだけではだめで、
少なくともBondriverの定義ファイルをいじらないと受信できないらしい。
定義ファイルのないBondriverの場合は、BonDriverを直接バイナリエディタでの変更が必要みたいです。

おそらく、修正内容は以下の通り。
(20180522:ディズニー・チャンネル,BSアニマックスのTSIDが誤っていたため、修正)

(1)BSジャパン（2018年4月16日～）
周波数：11765.840→11727.480
名称　：BS03/TS1→BS01/TS2
TSID　：0x4031(16433)→0x4012(16402)

(2)BSプレミアム（2018年5月8日～)
周波数：11996.000→11765.840
名称　：BS15/TS2→BS03/TS1
TSID　：0x40f2(16626)→0x4031(16433)

(3)ディズニー・チャンネル（2018年5月22日～)
周波数：11842.560→11765.840
名称　：BS07/TS2→BS03/TS2
TSID　：0x4672(18034)→0x4632(17970)　　　[~~TSID　：0x4672(18034)→0x4032(16433)~~]

(4)BSアニマックス（2018年5月22日～)
周波数：11842.560→11957.640
名称　：BS07/TS1→BS13/TS2
TSID　：0x4671(18033)→0x46d2(18130) [~~TSID　：0x4671(18033)→0x40d2(16594)~~]

(5)スターチャンネル2（2018年5月28日～) 予想（TSIDについては、別途確認の必要あり）
周波数：11842.560→11996.000
名称　：BS07/TS0→BS15/TS2
TSID　：0x4470(17520)→0x40f2(11996)

(6)スターチャンネル3（2018年5月28日～) 予想（TSIDについては、別途確認の必要あり）
周波数：11842.560→11996.000
名称　：BS07/TS0→BS15/TS2
TSID　：0x4470(17520)→0x40f2(16626)

家で使用しているBSCSチューナは以下の通り
PX-W3U2：Bon Driverの定義ファイル(.ini)にて対応化・・・・・・・・(1)
PX-Q3PE：Bon Driverの定義ファイル(.ini)にて対応化・・・・・・・・(1)
PX-BSCS：定義ファイルがないため、バイナリの直接変更が必要・・・(2)

(1)はBon Driverごとに用意されたiniファイルの中身を更新するだけです。

BSジャパン（2018年4月16日～）
CH004=BS3/TS1,171,11765840,0×4031
↓
CH004=BS1/TS2,171,11727480,0×4012

NHK BSプレミアム（2018年5月8日～)
CH011=BS15/TS2,103,11996000,0x40f2
↓
CH011=BS3/TS1,103,11765840,0×4031

ディズニー・チャンネル（2018年5月22日～)：確定版
CH024 = BS7/TS2,0,11842560,0×4672
↓
CH024 = BS3/TS2,0,11765840,0×4632

BSアニマックス（2018年5月22日～)：確定版
CH017 = BS7/TS1,0,11842560,0×4671
↓
CH017 = BS13/TS2,0,11957640,0x46d2

スターチャンネル2,3（2018年5月28日～)：確定版
CH016 = BS7/TS0,0,11842560,0×4470
↓
CH016 = BS15/TS2,0,11996000,0x40f2

(2)は、Bon Driver(.Dll）を直接バイナリエディタで書き換えが必要です。
[https://mevius.5ch.net/test/read.cgi/avi/1521541943]

●BSジャパン（2018年4月16日～）：確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;BSJ 周波数変更 BS3/11766(0x2DF6) → BS1/11727(0x2DCF)
022A38: F6 CF
;BSJ TSID変更 16433(0x4031) → 16402(0x4012)
022A3C: 31 12

●BSプレミアム（2018年5月9日～）：確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;NHK P 周波数変更 BS15/11996 (0x2EDC) → BS03/11766 (0x2DF6)
022918: DC F6
022919: 2E 2D
;NHK P TSID変更 16626 (0x40f2) → 16433 (0x4031)
02291C: F2 31
02291D: 40 40

●ディズニー・チャンネル（2018年5月22日～)：確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;ディズニー・チャンネル周波数変更 BS07/11843 (0x2E43) → BS03/11766 (0x2DF6)
022DE0: 43 F6
022DE1: 2E 2D
;ディズニー・チャンネル TSID変更 18034 (0x4672) → 17970 (0x4632)
022DE4: 72 32
022DE5: 46 46

●BSアニマックス（2018年5月22日～)：確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;BSアニマックス周波数変更 BS07/11843 (0x2E43) → BS13/11958 (0x2EB6)
022D98: 43 B6
022D99: 2E 2E
;BSアニマックス TSID変更 18033 (0x4671) → 18130 (0x46d2)
022D9C: 71 D2
022D9D: 46 46

●スターチャンネル2,3（2018年5月28日～)：予想（TSIDについては、別途確認の必要あり）
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;スターチャンネル2,3 周波数変更 BS07/11843 (0x2E43) → BS15/11996 (0x2EDC)
022BE8: 43 DC
022BE9: 2E 2E
;スターチャンネル2,3 TSID変更 17520 (0x4470) → 16626 (0x40f2)
022BEC: 70 F2
022BED: 44 40

上記修正のあとは、チャンネルスキャンで移動したチャンネルが認識されます。
もし、Spinel経由でチューナーを使っている場合も、Spinelサーバ側のBonDriverで修正すればOKのようです。

もし、チャンネルスキャンをしない場合は、チューナーごとのファイルを書き換えてもよいですが、チャンネルスキャンをお勧めします。

EDCB 9.x系であれば、\EpgTimerBonフォルダ内のBSCSチューナのChSet.txt、ChSet2.txtファイルを書き換えます（チャンネルスキャンをした場合は不要）。
（例）

BonDriver_PX_Q3PE_S0(PX-Q3PE S0).ChSet.txt

BS3/TS1 0 3 0

↓

BS1/TS2 0 3 0

——————–

BS15/TS2 0 10 0

↓

BS3/TS1 0 10 0

——————–

BS7/TS1 0 16 0

↓

BS13/TS2 0 16 0

——————–

BS7/TS2 0 23 0

↓

BS3/TS2 0 23 0

BonDriver_PX_Q3PE_S0(PX-Q3PE S0).ChSet2.txt

ＢＳジャパン 0 3 171 16433 4 1 1

ＢＳジャパン２ 0 3 172 16433 4 1 1

ＢＳジャパン３ 0 3 173 16433 4 1 1

臨時サービス 0 3 179 16433 4 161 1

株価情報 0 3 777 16433 4 192 1

ＢＳジャパン７７８ 0 3 778 16433 4 192 1

↓

ＢＳジャパン 0 3 171 16402 4 1 1

ＢＳジャパン２ 0 3 172 16402 4 1 1

ＢＳジャパン３ 0 3 173 16402 4 1 1

臨時サービス 0 3 179 16402 4 161 1

株価情報 0 3 777 16402 4 192 1

ＢＳジャパン７７８ 0 3 778 16402 4 192 1

—————————–

ＮＨＫＢＳプレミアム 0 10 103 16626 4 1 1

ＮＨＫＢＳプレミアム 0 10 104 16626 4 1 1

↓

ＮＨＫＢＳプレミアム 0 10 103 16433 4 1 1

ＮＨＫＢＳプレミアム 0 10 104 16433 4 1 1

—————————–

ＢＳアニマックス 0 16 236 18033 4 1 1

↓

ＢＳアニマックス 0 16 236 18130 4 1 1

—————————–

ディズニーチャンネル 0 23 256 18034 4 1 1

↓

ディズニーチャンネル 0 23 256 17970 4 1 1

「ChSet3.txt」も同様に変更が必要です。
（チャンネルスキャンした場合でも、昔の情報が残っているので削除推奨）
作業後は、EDCBの設定から「EPGデータ取得設定」で、変更したチャンネルがEPG取得対象になっていることを確認してください。

EDCB 10.x系であれば、\Settingフォルダ内のBSCSチューナのChSet4.txtファイルを書き換えます。
（チャンネルスキャンをした場合は不要）
（例）

BonDriver_Spinel_BCUD0(Spinel：PXBCUD_0／S0).ChSet4.txt

BS3/TS1 ＢＳジャパン BS Digital 0 3 4 16433 171 1 0 1 0

BS3/TS1 ＢＳジャパン２ BS Digital 0 3 4 16433 172 1 0 1 0

BS3/TS1 ＢＳジャパン３ BS Digital 0 3 4 16433 173 1 0 1 0

BS3/TS1 臨時サービス BS Digital 0 3 4 16433 179 161 0 0 0

BS3/TS1 株価情報 BS Digital 0 3 4 16433 777 192 0 0 0

BS3/TS1 ＢＳジャパン７７８ BS Digital 0 3 4 16433 778 192 0 0 0

↓

BS3/TS1 ＢＳジャパン BS Digital 0 3 4 16402 171 1 0 1 0

BS3/TS1 ＢＳジャパン２ BS Digital 0 3 4 16402 172 1 0 1 0

BS3/TS1 ＢＳジャパン３ BS Digital 0 3 4 16402 173 1 0 1 0

BS3/TS1 ＢＳジャパン臨時 BS Digital 0 3 4 16402 179 161 0 0 0

BS3/TS1 株価情報 BS Digital 0 3 4 16402 777 192 0 0 0

BS3/TS1 778ch BS Digital 0 3 4 16402 778 192 0 0 0

———————————–

BS15/TS2 ＮＨＫＢＳプレミアム BS Digital 0 10 4 16626 103 1 0 1 0

BS15/TS2 ＮＨＫＢＳプレミアム BS Digital 0 10 4 16626 104 1 0 1 0

↓

BS15/TS2 ＮＨＫＢＳプレミアム BS Digital 0 18 4 16433 103 1 0 1 0

BS15/TS2 ＮＨＫＢＳプレミアム BS Digital 0 18 4 16433 104 1 0 1 0

———————————–

BS7/TS1 ＢＳアニマックス BS Digital 0 16 4 18033 236 1 0 1 0

↓

BS7/TS1 ＢＳアニマックス BS Digital 0 7 4 18130 236 1 0 1 0

———————————–

BS7/TS2 ディズニーチャンネル BS Digital 0 23 4 18034 256 1 0 1 0

↓

BS7/TS2 ディズニーチャンネル BS Digital 0 8 4 17970 256 1 0 1 0

「ChSet5.txt」も同様に変更が必要です。
（チャンネルスキャンした場合でも、昔の情報が残っているので削除推奨）
作業後は、EDCBの設定から「EPG取得」で、変更したチャンネルがEPG取得対象になっていることを確認してください。

家は結構いろんなチューナを使っているので、対策が結構大変。

とりあえず、修正はコレで完了ですが、
既に予約している番組は対応チューナーがなくなったと認識されているので無効化推奨です。
自動予約していない場合は、手動での登録が必要です。
（EDCB10.0系の場合一括置換することも出来るようです。）

また、自動予約を対象のチャンネルで登録している場合は、こちらも修正が必要です。
（EDCB10.0系の場合一括置換することも出来るようです。）

とりあえず、メインの録画環境だけ修正したので、現在様子見中
残すは後一回。5/28にもやらないといけませんね。

参考
http://soranikakaruhashi.blog.fc2.com/blog-entry-379.html
http://heikin.hatenablog.com/entry/BS_Restruct2018
https://nyanshiba.hatenablog.com/entry/2018/04/16/193910
https://mevius.5ch.net/test/read.cgi/avi/1521541943

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での認識情報

~ # lspci|grep NVIDIA
0000:05:00.0 Display controller: NVIDIA Corporation NVIDIAQuadro 4000 [vmgfx0]
0000:05:00.1 Multimedia controller: NVIDIA Corporation GF100 High Definition Audio Controller
~ #
~ # lspci -v
0000:05:00.0 VGA compatible controller Display controller: NVIDIA Corporation NVIDIAQuadro 4000 [vmgfx0]
 Class 0300: 10de:06dd
~ #
~ # esxcli hardware pci list -c 0x0300 -m 0xf
000:005:00.0
   Address: 000:005:00.0
   Segment: 0x0000
   Bus: 0x05
   Slot: 0x00
   Function: 0x00
   VMkernel Name: vmgfx0
   Vendor Name: NVIDIA Corporation
   Device Name: NVIDIAQuadro 4000
   Configured Owner: Unknown
   Current Owner: VMkernel
   Vendor ID: 0x10de
   Device ID: 0x06dd
   SubVendor ID: 0x103c
   SubDevice ID: 0x0780
   Device Class: 0x0300
   Device Class Name: VGA compatible controller
   Programming Interface: 0x00
   Revision ID: 0xa3
   Interrupt Line: 0x0b
   IRQ: 11
   Interrupt Vector: 0x57
   PCI Pin: 0x64
   Spawned Bus: 0x00
   Flags: 0x0221
   Module ID: 4199
   Module Name: nvidia
   Chassis: 0
   Physical Slot: 2
   Slot Description: SLOT 2
   Passthru Capable: true
   Parent Device: PCI 0:0:3:0
   Dependent Device: PCI 0:0:3:0
   Reset Method: Bridge reset
   FPT Sharable: true
~ #
~ # vmkload_mod -l
Name       Used  Size (kb)
nvidia     104   9644
~ #
~ # grep -A 40 -i "Loading module nvidia" /var/log/vmkernel.log
2018-05-05T08:05:05.515Z cpu26:35548)Loading module nvidia ...
2018-05-05T08:05:05.522Z cpu26:35548)Elf: 1861: module nvidia has license NVIDIA
2018-05-05T08:05:05.614Z cpu26:35548)module heap: Initial heap size: 8388608, max heap size: 68476928
2018-05-05T08:05:05.614Z cpu26:35548)vmklnx_module_mempool_init: Mempool max 68476928 being used for module: 4199
2018-05-05T08:05:05.614Z cpu26:35548)vmk_MemPoolCreate passed for 2048 pages
2018-05-05T08:05:05.614Z cpu26:35548)module heap: using memType 2
2018-05-05T08:05:05.614Z cpu26:35548)module heap vmklnx_nvidia: creation succeeded. id = 0x41140ef22000
NVRM: vmk_MemPoolCreate passed for 4194304 pages.
2018-05-05T08:05:05.864Z cpu26:35548)PCI: driver nvidia is looking for devices
2018-05-05T08:05:05.865Z cpu26:35548)PCI: driver nvidia claimed device 0000:05:00.0
2018-05-05T08:05:05.865Z cpu26:35548)PCI: driver nvidia claimed 1 device
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.65 Wed Oct 9 22:51:48 PDT 2013
2018-05-05T08:05:05.865Z cpu26:35548)Mod: 4780: Initialization of nvidia succeeded with module ID 4199.
2018-05-05T08:05:05.865Z cpu26:35548)nvidia loaded successfully.
2018-05-05T08:05:07.323Z cpu30:35697)Enabling MSI for dev 0000:05:00.0
2018-05-05T08:05:07.323Z cpu30:35697)IntrVector: 288: Vector 0x57 allocated, 149 vectors available
2018-05-05T08:05:07.323Z cpu30:35697)VMK_PCI: 720: device 0000:05:00.0 allocated 1 interrupts (intrType 2)
2018-05-05T08:05:07.323Z cpu30:35697)IRQ: 540: 0x57 <nvidia> exclusive, flags 0x10
2018-05-05T08:05:07.323Z cpu30:35697)VMK_VECTOR: 218: Registered handler for interrupt 0xff57, flags 0x10
~ #
~ # /etc/init.d/xorg status
Xorg is running
~ #
~ # gpuvm
Xserver unix:0, PCI ID 0:5:0:0, GPU maximum memory 2076672KB
 pid 40452, VM "Win7-RDPSV", reserved 131072KB of GPU memory.
 pid 41854, VM "Win7-TVMW5", reserved 131072KB of GPU memory.
 pid 41875, VM "Win7-TVMW6", reserved 131072KB of GPU memory.
 pid 41979, VM "Win10-RDPSV", reserved 131072KB of GPU memory.
 pid 42021, VM "Win7-Z800", reserved 131072KB of GPU memory.
 pid 46112, VM "Win10-64-VDI01", reserved 131072KB of GPU memory.
 pid 46181, VM "DELLWin764", reserved 131072KB of GPU memory.
 GPU memory left 1159168KB.
~ #
~ # nvidia-smi
Sun May 6 02:19:59 2018
+------------------------------------------------------+
| NVIDIA-SMI 5.319.65 Driver Version: 319.65           |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Quadro 4000         Off  | 0000:05:00.0     Off |                  N/A |
| 36%   62C   P12    N/A /  N/A |      454MB /  2047MB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Compute processes:                                               GPU Memory |
|  GPU       PID  Process name                                     Usage      |
|=============================================================================|
|  No running compute processes found                                         |
+-----------------------------------------------------------------------------+
~ #

100

101

102

103

~ # lspci|grep NVIDIA

0000:05:00.0 Display controller: NVIDIA Corporation NVIDIAQuadro 4000 [vmgfx0]

0000:05:00.1 Multimedia controller: NVIDIA Corporation GF100 High Definition Audio Controller

~ #

~ # lspci -v

0000:05:00.0 VGA compatible controller Display controller: NVIDIA Corporation NVIDIAQuadro 4000 [vmgfx0]

Class 0300: 10de:06dd

~ #

~ # esxcli hardware pci list -c 0x0300 -m 0xf

000:005:00.0

Address: 000:005:00.0

Segment: 0x0000

Bus: 0x05

Slot: 0x00

Function: 0x00

VMkernel Name: vmgfx0

Vendor Name: NVIDIA Corporation

Device Name: NVIDIAQuadro 4000

Configured Owner: Unknown

Current Owner: VMkernel

Vendor ID: 0x10de

Device ID: 0x06dd

SubVendor ID: 0x103c

SubDevice ID: 0x0780

Device Class: 0x0300

Device Class Name: VGA compatible controller

Programming Interface: 0x00

Revision ID: 0xa3

Interrupt Line: 0x0b

IRQ: 11

Interrupt Vector: 0x57

PCI Pin: 0x64

Spawned Bus: 0x00

Flags: 0x0221

Module ID: 4199

Module Name: nvidia

Chassis: 0

Physical Slot: 2

Slot Description: SLOT 2

Passthru Capable: true

Parent Device: PCI 0:0:3:0

Dependent Device: PCI 0:0:3:0

Reset Method: Bridge reset

FPT Sharable: true

~ #

~ # vmkload_mod -l

Name Used Size (kb)

nvidia 104 9644

~ #

~ # grep -A 40 -i "Loading module nvidia" /var/log/vmkernel.log

2018-05-05T08:05:05.515Z cpu26:35548)Loading module nvidia ...

2018-05-05T08:05:05.522Z cpu26:35548)Elf: 1861: module nvidia has license NVIDIA

2018-05-05T08:05:05.614Z cpu26:35548)module heap: Initial heap size: 8388608, max heap size: 68476928

2018-05-05T08:05:05.614Z cpu26:35548)vmklnx_module_mempool_init: Mempool max 68476928 being used for module: 4199

2018-05-05T08:05:05.614Z cpu26:35548)vmk_MemPoolCreate passed for 2048 pages

2018-05-05T08:05:05.614Z cpu26:35548)module heap: using memType 2

2018-05-05T08:05:05.614Z cpu26:35548)module heap vmklnx_nvidia: creation succeeded. id = 0x41140ef22000

NVRM: vmk_MemPoolCreate passed for 4194304 pages.

2018-05-05T08:05:05.864Z cpu26:35548)PCI: driver nvidia is looking for devices

2018-05-05T08:05:05.865Z cpu26:35548)PCI: driver nvidia claimed device 0000:05:00.0

2018-05-05T08:05:05.865Z cpu26:35548)PCI: driver nvidia claimed 1 device

NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.65 Wed Oct 9 22:51:48 PDT 2013

2018-05-05T08:05:05.865Z cpu26:35548)Mod: 4780: Initialization of nvidia succeeded with module ID 4199.

2018-05-05T08:05:05.865Z cpu26:35548)nvidia loaded successfully.

2018-05-05T08:05:07.323Z cpu30:35697)Enabling MSI for dev 0000:05:00.0

2018-05-05T08:05:07.323Z cpu30:35697)IntrVector: 288: Vector 0x57 allocated, 149 vectors available

2018-05-05T08:05:07.323Z cpu30:35697)VMK_PCI: 720: device 0000:05:00.0 allocated 1 interrupts (intrType 2)

2018-05-05T08:05:07.323Z cpu30:35697)IRQ: 540: 0x57 <nvidia> exclusive, flags 0x10

2018-05-05T08:05:07.323Z cpu30:35697)VMK_VECTOR: 218: Registered handler for interrupt 0xff57, flags 0x10

~ #

~ # /etc/init.d/xorg status

Xorg is running

~ #

~ # gpuvm

Xserver unix:0, PCI ID 0:5:0:0, GPU maximum memory 2076672KB

pid 40452, VM "Win7-RDPSV", reserved 131072KB of GPU memory.

pid 41854, VM "Win7-TVMW5", reserved 131072KB of GPU memory.

pid 41875, VM "Win7-TVMW6", reserved 131072KB of GPU memory.

pid 41979, VM "Win10-RDPSV", reserved 131072KB of GPU memory.

pid 42021, VM "Win7-Z800", reserved 131072KB of GPU memory.

pid 46112, VM "Win10-64-VDI01", reserved 131072KB of GPU memory.

pid 46181, VM "DELLWin764", reserved 131072KB of GPU memory.

GPU memory left 1159168KB.

~ #

~ # nvidia-smi

Sun May 6 02:19:59 2018

+------------------------------------------------------+

| NVIDIA-SMI 5.319.65 Driver Version: 319.65 |

|-------------------------------+----------------------+----------------------+

| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |

| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |

|===============================+======================+======================|

| 0 Quadro 4000 Off | 0000:05:00.0 Off | N/A |

| 36% 62C P12 N/A / N/A | 454MB / 2047MB | 0% Default |

+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+

| Compute processes: GPU Memory |

| GPU PID Process name Usage |

|=============================================================================|

| No running compute processes found |

+-----------------------------------------------------------------------------+

~ #

ただ、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

~ # esxcli software vib list
 Name Version Vendor Acceptance Level Install Date
 ---------------------------------- ------------------------------------- --------------- ------------------ ------------
 NVIDIA-VMware_ESXi_5.5_Host_Driver 319.65-1OEM.550.0.0.1331820 NVIDIA VMwareAccepted 2017-09-09

~ # esxcli software vib list

Name Version Vendor Acceptance Level Install Date

---------------------------------- ------------------------------------- --------------- ------------------ ------------

NVIDIA-VMware_ESXi_5.5_Host_Driver 319.65-1OEM.550.0.0.1331820 NVIDIA VMwareAccepted 2017-09-09

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

    NVIDIA GPU product                    Device PCI ID*
    ----------------------------------    ----------------------------------
    Quadro 6000                           0x06D8       
    Quadro 5000                           0x06D9       
    Quadro 4000                           0x06DD       
    Tesla M2070-Q                         0x06DF       
    GRID K1                               0x0FF2       
    GRID K2                               0x11BF

NVIDIA GPU product Device PCI ID*

---------------------------------- ----------------------------------

Quadro 6000 0x06D8

Quadro 5000 0x06D9

Quadro 4000 0x06DD

Tesla M2070-Q 0x06DF

GRID K1 0x0FF2

GRID K2 0x11BF

なお、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までしか対応していないことになります。

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

~ # vim-cmd hostsvc/maintenance_mode_enter
~ # esxcli software vib install -d /vmfs/volumes/VMSV03-SSD-2/NVIDIA-vib/NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65-1OEM.550.0.0.1331820.vib
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65-1OEM.550.0.0.1331820
   VIBs Removed:
   VIBs Skipped:
= # vim-cmd /hostsvc/maintenance_mode_exit
= # /etc/init.d/xorg start

~ # vim-cmd hostsvc/maintenance_mode_enter

~ # esxcli software vib install -d /vmfs/volumes/VMSV03-SSD-2/NVIDIA-vib/NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65-1OEM.550.0.0.1331820.vib

Installation Result

Message: Operation finished successfully.

Reboot Required: false

VIBs Installed: NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65-1OEM.550.0.0.1331820

VIBs Removed:

VIBs Skipped:

= # vim-cmd /hostsvc/maintenance_mode_exit

= # /etc/init.d/xorg start

現在、ESXi6.0U3へのバージョンアップを検討していますが、Quadro4000が対応していない以上、vSGAをあきらめるか、別のカードを使用するかですが、NVIDIAの対応カードですと最近のビジネス用ハイエンドGPUしか対応しておらず、価格帯も中古でも2桁万円Over、下手すると３桁万円クラスなので、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以上になるとｖSphere 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 を使用して、[ターゲットの指定] ウィザードで必要な仮想ハードウェアバージョンを選択してコンバート
必要なハードウェアバージョンで新しい仮想マシンを作成し、仮想マシンから既存のディスクを接続。

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

この場合の裏技ですが、実は、ハードウェアバージョンをあげる作業というのは、仮想マシンの定義ファイル(.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への換装完了後再起動したら、ＯＳ立ち上がらず。BIOSでSATAコントローラ認識してない。
->予備のNEC GT110bを引っ張り出してきて、ニコイチ修理で回復
hdd１台（WDC WD40EFRX）
ZFSによるRAIDで使用していたがエラーがでてFAULTED状態に。業務影響なし。
->同型HDDをAmazonで購入し、交代して対策
部屋の上の蛍光灯照明器具
紐を引っ張っても、明かりが消えず・・・寝たいんですけど。
->引越しのときにあまっていた蛍光灯照明器具と交換。

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

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

今回の収穫物

SSD(128GB) 2台
SSD128G-TLC-BULC (Grenn Houseパイソン)
店舗情報:バルク品（１年保障。最大読み込み500MB/s、最大書き込み400MB/s
-> Z820のZFS-LOG(Zil)用。Mirror構成のため２つ。
SSD(480GB) 1台
TS480GSSD220S(Transend)
店舗情報:Trancend:?年保障。最大読み込み550MB/s、最大書き込み450MB/s、80000IOPS
-> Z820のZFS-L2ARC(Cache)用
5インチベイ1つに2.5″HDD&SSDを6枚搭載できるドック
6Bay 2.5″ SATA HDD&SSD Backplane Cage(MB996SP-6SB)
->上のSSDを搭載するために既存の2.5″x4 in 5″bayとリプレース予定
トラックボール付ミニワイヤレスキーボード
(DN-915040 DN-Wireless tacking ball keybord with mouse KB-WL06)
マルチメディアワイヤレスキーボード
(DN-915265 タッチパッド搭載 2.4GHz ミニワイヤレスキーボード/Rii mini i15)
UASP対応内蔵3.5インチSATA HDD,SSD用ハードディスクケース x2
(HDE-08)
IDE->USB変換アダプタ
キャリーバックにもなるボストンバック
USBスピーカ
LED拡大鏡

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

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

さて換装しよっかな

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

コメントを残す

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

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

root@NS003:/volumes# zpool status | more
 pool: RAIDZ-SATA-1
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
 Sufficient replicas exist for the pool to continue functioning in a
 degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
 repaired.
 scan: resilvered 3.18G in 0h3m with 0 errors on Sun Apr 29 22:42:59 2018
config:

NAME STATE READ WRITE CKSUM
 RAIDZ-SATA-1 DEGRADED 0 0 0
 raidz1-0 DEGRADED 0 0 0
 　c2t0d0 ONLINE 0 0 0
 　c2t1d0 FAULTED 0 0 0 too many errors
 　c2t2d0 ONLINE 0 0 0
 logs
 　c2t6d0 ONLINE 0 0 0
 cache
 　c2t5d0 ONLINE 0 0 0

errors: No known data errors

root@NS003:/volumes# zpool status | more

pool: RAIDZ-SATA-1

state: DEGRADED

status: One or more devices are faulted in response to persistent errors.

Sufficient replicas exist for the pool to continue functioning in a

degraded state.

action: Replace the faulted device, or use 'zpool clear' to mark the device

repaired.

scan: resilvered 3.18G in 0h3m with 0 errors on Sun Apr 29 22:42:59 2018

config:

NAME STATE READ WRITE CKSUM

RAIDZ-SATA-1 DEGRADED 0 0 0

raidz1-0 DEGRADED 0 0 0

　c2t0d0 ONLINE 0 0 0

　c2t1d0 FAULTED 0 0 0 too many errors

　c2t2d0 ONLINE 0 0 0

logs

　c2t6d0 ONLINE 0 0 0

cache

　c2t5d0 ONLINE 0 0 0

errors: No known data errors

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

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

#Nexentastor上の認識
c2t1d0 sd6 disk 2.00 TB RAIDZ-SATA-1 mpt VMware, Rev. 1.0

#nexentastor仮想マシン上の認識
ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1)

#Nexentastor上の認識

c2t1d0 sd6 disk 2.00 TB RAIDZ-SATA-1 mpt VMware, Rev. 1.0

#nexentastor仮想マシン上の認識

ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1)

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

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

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

VMSV03-SATA-5
標準
Local ATA Disk (naa.50014ee2ba5bb332):1
非 SSD
3.64 TB
1.01 TB
VMFS5
2018/04/30 9:02:04
有効
無効
不明

VMSV03-SATA-5

標準

Local ATA Disk (naa.50014ee2ba5bb332):1

非 SSD

3.64 TB

1.01 TB

VMFS5

2018/04/30 9:02:04

有効

無効

不明

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

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

/etc/init.d # esxcli storage core device list -d naa.50014ee2ba5bb332
naa.50014ee2ba5bb332
 Display Name: Local ATA Disk (naa.50014ee2ba5bb332)
 Has Settable Display Name: true
 Size: 3815447
 Device Type: Direct-Access
 Multipath Plugin: NMP
 Devfs Path: /vmfs/devices/disks/naa.50014ee2ba5bb332
 Vendor: ATA
 Model: WDC WD40EFRX-68W
 Revision: 0A82
 SCSI Level: 5
 Is Pseudo: false
 Status: on
 Is RDM Capable: false
 Is Local: true
 Is Removable: false
 Is SSD: false
 Is Offline: false
 Is Perennially Reserved: false
 Queue Full Sample Size: 0
 Queue Full Threshold: 0
 Thin Provisioning Status: unknown
 Attached Filters:
 VAAI Status: unknown
 Other UIDs: vml.020000000050014ee2ba5bb332574443205744
 Is Local SAS Device: false
 Is USB: false
 Is Boot USB Device: false
 No of outstanding IOs with competing worlds: 32
/etc/init.d #

/etc/init.d # esxcli storage core device list -d naa.50014ee2ba5bb332

naa.50014ee2ba5bb332

Display Name: Local ATA Disk (naa.50014ee2ba5bb332)

Has Settable Display Name: true

Size: 3815447

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/naa.50014ee2ba5bb332

Vendor: ATA

Model: WDC WD40EFRX-68W

Revision: 0A82

SCSI Level: 5

Is Pseudo: false

Status: on

Is RDM Capable: false

Is Local: true

Is Removable: false

Is SSD: false

Is Offline: false

Is Perennially Reserved: false

Queue Full Sample Size: 0

Queue Full Threshold: 0

Thin Provisioning Status: unknown

Attached Filters:

VAAI Status: unknown

Other UIDs: vml.020000000050014ee2ba5bb332574443205744

Is Local SAS Device: false

Is USB: false

Is Boot USB Device: false

No of outstanding IOs with competing worlds: 32

/etc/init.d #

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として追加させますが、ここで注意が１つ。
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は必ず一致させましょう。）

#nexentastor仮想マシン上の認識（控えていた情報）
ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1)

1 2	#nexentastor仮想マシン上の認識（控えていた情報）ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1)

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

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

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

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

root@NS003:/volumes# zpool status RAIDZ-SATA-1
 pool: RAIDZ-SATA-1
 state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
 continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scan: resilver in progress since Tue May 1 03:19:50 2018
 34.7G scanned out of 2.28T at 15.3M/s, 42h38m to go
 11.5G resilvered, 1.49% done
config:

NAME STATE READ WRITE CKSUM
 RAIDZ-SATA-1 DEGRADED 0 0 0
 raidz1-0 DEGRADED 0 0 0
 c2t0d0 ONLINE 0 0 0
 replacing-1 DEGRADED 0 0 0
 c2t1d0/old FAULTED 0 0 0 too many errors
 c2t1d0 ONLINE 0 0 0 (resilvering)
 c2t2d0 ONLINE 0 0 0
 logs
 c2t6d0 ONLINE 0 0 0
 cache
 c2t5d0 ONLINE 0 0 0

errors: No known data errors

root@NS003:/volumes# zpool status RAIDZ-SATA-1

pool: RAIDZ-SATA-1

state: DEGRADED

status: One or more devices is currently being resilvered. The pool will

continue to function, possibly in a degraded state.

action: Wait for the resilver to complete.

scan: resilver in progress since Tue May 1 03:19:50 2018

34.7G scanned out of 2.28T at 15.3M/s, 42h38m to go

11.5G resilvered, 1.49% done

config:

NAME STATE READ WRITE CKSUM

RAIDZ-SATA-1 DEGRADED 0 0 0

raidz1-0 DEGRADED 0 0 0

c2t0d0 ONLINE 0 0 0

replacing-1 DEGRADED 0 0 0

c2t1d0/old FAULTED 0 0 0 too many errors

c2t1d0 ONLINE 0 0 0 (resilvering)

c2t2d0 ONLINE 0 0 0

logs

c2t6d0 ONLINE 0 0 0

cache

c2t5d0 ONLINE 0 0 0

errors: No known data errors

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

root@NS003:/usr/sbin# zpool status
 pool: RAIDZ-SATA-1
 state: ONLINE
 scan: resilvered 676G in 8h32m with 0 errors on Tue May 1 11:52:26 2018
config:

NAME STATE READ WRITE CKSUM
 RAIDZ-SATA-1 ONLINE 0 0 0
 raidz1-0 ONLINE 0 0 0
 c2t0d0 ONLINE 0 0 0
 c2t1d0 ONLINE 0 0 0
 c2t2d0 ONLINE 0 0 0
 logs
 c2t6d0 ONLINE 0 0 0
 cache
 c2t5d0 ONLINE 0 0 0

errors: No known data errors

root@NS003:/usr/sbin# zpool status

pool: RAIDZ-SATA-1

state: ONLINE

scan: resilvered 676G in 8h32m with 0 errors on Tue May 1 11:52:26 2018

config:

NAME STATE READ WRITE CKSUM

RAIDZ-SATA-1 ONLINE 0 0 0

raidz1-0 ONLINE 0 0 0

c2t0d0 ONLINE 0 0 0

c2t1d0 ONLINE 0 0 0

c2t2d0 ONLINE 0 0 0

logs

c2t6d0 ONLINE 0 0 0

cache

c2t5d0 ONLINE 0 0 0

errors: No known data errors

（余談）
取り外しした調子の悪くなってしまった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はまだがんばってもらえそうです。）

ESXiでsmart値の確認

コメントを残す

ESXiでDiskのSmart値を確認するには、以下の方法があります。

方法１.esxcliコマンドを使用する方法

データストアのプロパティからも、該当デバイス名を確認します。

データストアの一覧の画面からデータストアを選択して、右クリック->「クリップボードにコピー」からも確認できます。

VMSV03-SSD960-1
標準
Local ATA Disk (t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________):4
SSD
799.75 GB
346.49 GB
VMFS5
2018/04/30 9:32:05
有効
無効
不明

VMSV03-SSD960-1

標準

Local ATA Disk (t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________):4

SSD

799.75 GB

346.49 GB

VMFS5

2018/04/30 9:32:05

有効

無効

不明

また、esxcli storage core device listからも、ストレージのDevice名を確認できます。

# esxcli storage core device list

t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________
 Display Name: Local ATA Disk (t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________)
 Has Settable Display Name: true
 Size: 915715
 Device Type: Direct-Access
 Multipath Plugin: NMP
 Devfs Path: /vmfs/devices/disks/t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________
 Vendor: ATA
 Model: SanDisk Ultra II
 Revision: X412
 SCSI Level: 5
 Is Pseudo: false
 Status: on
 Is RDM Capable: false
 Is Local: true
 Is Removable: false
 Is SSD: true
 Is Offline: false
 Is Perennially Reserved: false
 Queue Full Sample Size: 0
 Queue Full Threshold: 0
 Thin Provisioning Status: yes
 Attached Filters:
 VAAI Status: unknown
 Other UIDs: vml.0100000000313731383136343233343832202020202020202053616e446973
 Is Local SAS Device: false
 Is USB: false
 Is Boot USB Device: false
 No of outstanding IOs with competing worlds: 32

# esxcli storage core device list

t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________

Display Name: Local ATA Disk (t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________)

Has Settable Display Name: true

Size: 915715

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________

Vendor: ATA

Model: SanDisk Ultra II

Revision: X412

SCSI Level: 5

Is Pseudo: false

Status: on

Is RDM Capable: false

Is Local: true

Is Removable: false

Is SSD: true

Is Offline: false

Is Perennially Reserved: false

Queue Full Sample Size: 0

Queue Full Threshold: 0

Thin Provisioning Status: yes

Attached Filters:

VAAI Status: unknown

Other UIDs: vml.0100000000313731383136343233343832202020202020202053616e446973

Is Local SAS Device: false

Is USB: false

Is Boot USB Device: false

No of outstanding IOs with competing worlds: 32

Device名を確認したら、esxcli storage core device smart get -d <デバイス名>でSmart値を確認します。

# esxcli storage core device smart get -d t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482____
____
Parameter Value Threshold Worst
---------------------------- ----- --------- -----
Health Status OK N/A N/A
Media Wearout Indicator 100 0 100
Write Error Count N/A N/A N/A
Read Error Count N/A N/A N/A
Power-on Hours 100 0 100
Power Cycle Count 100 0 100
Reallocated Sector Count 100 0 100
Raw Read Error Rate N/A N/A N/A
Drive Temperature 68 0 63
Driver Rated Max Temperature N/A N/A N/A
Write Sectors TOT Count 100 0 100
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count 100 0 100

# esxcli storage core device smart get -d t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482____

____

Parameter Value Threshold Worst

---------------------------- ----- --------- -----

Health Status OK N/A N/A

Media Wearout Indicator 100 0 100

Write Error Count N/A N/A N/A

Read Error Count N/A N/A N/A

Power-on Hours 100 0 100

Power Cycle Count 100 0 100

Reallocated Sector Count 100 0 100

Raw Read Error Rate N/A N/A N/A

Drive Temperature 68 0 63

Driver Rated Max Temperature N/A N/A N/A

Write Sectors TOT Count 100 0 100

Read Sectors TOT Count N/A N/A N/A

Initial Bad Block Count 100 0 100

なお、ストレージやインターフェイスがSmart取得をサポートしていない場合は、以下のように表示されるようです。

Device: naa.50014ee261268576
Errors:
Error getting Smart Parameters: GET param bundle error

Device: naa.50014ee261268576

Errors:

Error getting Smart Parameters: GET param bundle error

方法２．VMware support取得ツールの一部である Smartinfo.sh を利用する方法

こちらは、ストレージ上のデバイス全部のSmart値を一括表示できます。

~ # cd /usr/lib/vmware/vm-support/bin
/usr/lib/vmware/vm-support/bin # ./smartinfo.sh
SMART Information for disks.

Device: t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________
Parameter Value Threshold Worst
-----------------------------------------------------
Health Status OK N/A N/A
Media Wearout Indicator 100 0 100
Write Error Count N/A N/A N/A
Read Error Count N/A N/A N/A
Power-on Hours 100 0 100
Power Cycle Count 100 0 100
Reallocated Sector Count 100 0 100
Raw Read Error Rate N/A N/A N/A
Drive Temperature 68 0 63
Driver Rated Max Temperature N/A N/A N/A
Write Sectors TOT Count 100 0 100
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count 100 0 100


Device: naa.50014ee261268576
Errors:
Error getting Smart Parameters: GET param bundle error

~ # cd /usr/lib/vmware/vm-support/bin

/usr/lib/vmware/vm-support/bin # ./smartinfo.sh

SMART Information for disks.

Device: t10.ATA_____SanDisk_Ultra_II_960GB__________________171816423482________

Parameter Value Threshold Worst

-----------------------------------------------------

Health Status OK N/A N/A

Media Wearout Indicator 100 0 100

Write Error Count N/A N/A N/A

Read Error Count N/A N/A N/A

Power-on Hours 100 0 100

Power Cycle Count 100 0 100

Reallocated Sector Count 100 0 100

Raw Read Error Rate N/A N/A N/A

Drive Temperature 68 0 63

Driver Rated Max Temperature N/A N/A N/A

Write Sectors TOT Count 100 0 100

Read Sectors TOT Count N/A N/A N/A

Initial Bad Block Count 100 0 100

Device: naa.50014ee261268576

Errors:

Error getting Smart Parameters: GET param bundle error

Z820にESXi 5.5用e1001eドライバ (Intel 82579LMドライバ) を組み込む

コメントを残す

Z820は、マザーに２つのNICが実装されています。
・82574L Gigabit Ethernet Controller (通称 intel E1000e)
・82579LM Gigabit Ethernet Controller (通称 intel E1001e)

このうち、82579LMは、ESX5.5U3からは標準で認識しますが、
それ以前ですと認識しません。この場合は、個別でvibをインストールしないといけません。

ドライバの入手先は、以下のサイトで可能です。

https://vibsdepot.v-front.de/wiki/index.php/Net-e1000e

実際のインストールは以下の手順になります。

login as: root
Using keyboard-interactive authentication.
Password:
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ #
~ # esxcli software acceptance set --level=CommunitySupported
Host acceptance level changed to 'CommunitySupported'.
~ # esxcli software vib install -v /vmfs/volumes/VMSV03-SSD960-3/VIB/intel82579L
M/net-e1000e-3.1.0.2-glr2.x86_64.vib
Installation Result
 Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
 Reboot Required: true
 VIBs Installed: GLRoman_bootbank_net-e1000e_3.1.0.2-glr2
 VIBs Removed: VMware_bootbank_net-e1000e_1.1.2-4vmw.550.1.15.1623387
 VIBs Skipped:
~ #

Using keyboard-interactive authentication.

Password:

The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools. Please

see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the

vSphere Security documentation for more information.

~ #

~ # esxcli software acceptance set --level=CommunitySupported

Host acceptance level changed to 'CommunitySupported'.

~ # esxcli software vib install -v /vmfs/volumes/VMSV03-SSD960-3/VIB/intel82579L

M/net-e1000e-3.1.0.2-glr2.x86_64.vib

Installation Result

Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

Reboot Required: true

VIBs Installed: GLRoman_bootbank_net-e1000e_3.1.0.2-glr2

VIBs Removed: VMware_bootbank_net-e1000e_1.1.2-4vmw.550.1.15.1623387

VIBs Skipped:

~ #

他にもいくつかのドライバーやツールなどがこのサイトにはありますね。
https://vibsdepot.v-front.de/wiki/index.php/Welcome

5/9のWindows Update

コメントを残す

5/9のWindows UpdateでCVE-2018-0886の更新が予定されていますが、この更新、業務影響大きい気がするのに、全然騒ぎになっていない気がする。
簡単に言うと、以下の運用の場合は、5/9以降クライアントからサーバ側へRDPで接続出来なくなる可能性があります。
・サーバはWindowsUpdateしない運用
・クライアントは自動でWindows Updateがかかるようにしている、

https://blogs.technet.microsoft.com/jpntsblog/2018/04/20/cve-2018-0886/

https://support.microsoft.com/ja-jp/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

さらに仮想環境用サーバ壊れました（gt110bサーバ）

コメントを残す

メインの仮想環境Z800->Z820の暫定修復が終わったと思ったら、
３台ある残り２台の仮想環境のうちの1台の、一番いろんな実験をしていたサーバも、
物理的に死にました。

このサーバでやってた変態的いや、いろいろな運用の例
・USBブートESXi [一様公式だけど、本番運用では普通しない]
・安鯖[NEC Express5800/GT110b]にCPU i7 870 & 32GBメモリ交換での運用
・筺体内ストレージ仮想マシンによる自作自演NFSストレージ(2TB*4 RAID5 & 2TB) [今で言うVSAN的運用]
・Radeon 5570をVMDirectPathでWin7仮想マシンに直結　[今で言うvDGA運用]
・USB3.0インターフェイスをVMDirectPathでWindowsストレージサーバに直結してのファイルサーバ（管理Disk容量約65TB）
・Xen on ESXiによる仮想 on 仮想環境

元々、一度電源を落とすと５,６回、多いときだと十数回、電源OFF.ONを繰り返さないと起動できない状況　&　マザー搭載VGA機能死亡状態で
３年ぐらいだましだまし使っていたのですが、
電源OFF.ONを繰り返しているうちに、
起動用USBにダメージを受けてしまった＆色々試行錯誤しているうちに、マザーボードのストレージコントローラを完全に見失っていて、ジ・エンドとなりました。

ただ、GT110bは発売からすでに10年経っている機種なので、何かあったときに入手困難となる可能性があったので、
共食い修理用の同型機種を２台ほど確保済みだったので、この予備サーバを使って復旧実施。

・保管してあった予備サーバに、CPU,メモリ、ストレージ、起動用USBメモリを移植
・ESXiのアップグレードインストール(ESXi 5.0->5.5、以前のコンフィグを継承するため)

いままで、なかなかふんぎりつかなくて、交換できていなかったのですが、
いざ始めてみたら、交換開始からさくっと２－３時間ぐらいで復旧。
（まったくの同一機種なので、移植は非常に楽。）

ちょうど、GWぐらいに先日暫定復旧したZ820環境にDISK拡張した後に、
この環境もマージできるように各種単体機能テストをしようかと考えていたのだけど、このタイミングで完全に壊れるとは・・・

突然死したZ800の復旧(Z820へのリプレース)

コメントを残す

突然死したZ800ですが、交換用のZ820が到着しました。

到着したのは、
HP Z820 水冷モデル
CPU :E5-2687W @3.10 x 2
MEM:32GB(RDIMM 1600メモリ 8GB x4)
GPU :Quadro K2000

とりあえず故障したのZ800からパーツを移植
・メモリ192GB (RIMM 16GB x12)
・Quadro4000 x1
・Intel CT NIC x1
・ストレージ系(SSD 960 x2,SDD 128 x1,4TB SATA HDD x3,300GB SAS HDD x4)

特にZ820サポート外のDDR3 RIMM 1333メモリを搭載したけど、普通に認識してメモリチェックもOK
メモリはZ820についていた32GBも追加して、現状224GBという中途半端な容量に。

ただ、Quadro4000とIntel CT NICを搭載したらBIOSのメモリオーバーエラーがでてしまったのでBIOSでbootに必要な誘うなNIC系のBIOSを切る必要がありました。

とりあえず、既存のSSDに入っていたESXiは普通に起動

ただ、SATA 6ポートのうち、6Gbpsのポート２つに挿したSSD2つは認識してVMFS領域もマウントできたけど、
残りの4ポート(3Gbps)が、ブロックSCSI扱いではなく、SCSI扱いになっていて、認識はするけどVMFS領域マウントせず。
どうやらvCenterに昔のVMFS領域のシグネーチャが残っていて、
接続がブロックSCSIからSCSI扱いに変わっている影響で同じシグネーチャでも、違うものとして認識しまったのに、すでに同じVMFS領域名が登録されているため、マウントできない模様

とりあえず以下をしたら、マウントできました。
・vCenterに残っているVMFS領域の名前を変更
・既存のVMFS領域のシグネーチャを更新してマウント
ただ、VMFS領域においてあった仮想マシン&VMDKは再登録する羽目になりましたが（仮想マシン２つ＆VMDK6個だけでしたが）。

なお、vCenterに昔のVMFS領域が残っていたのは、その領域を使用している仮想マシン&VMDKが登録されていたためだったようで、それを消したら、昔のVMFS領域は消えました。

もしかしたら、以下の手順のほうが簡単に復帰できたかも知れず・・・
・昔のVMFS領域を使用している仮想マシンをvCenterのインベントリから削除
・DISKを再マウント
・インベントリから削除した想マシンの再登録

とりあえず、これでストレージ系の復旧は完了。データ欠損なし。

あとはNICのMACアドレスが変わっているので念のため以下のコマンドを実行
# esxcfg-advcfg -s 1 /Net/FollowHardwareMac
（ESXは、ESXのインストールを実施したときにNICのMACアドレスをシステムに登録してしまって、NICが変更されても依存のMACアドレスで通信するため）
ただ、コレをやると、仮想マシンごとにを最初に立ち上げるときに「移動」したか、「コピー」したかを聞かれてしまうので、ハードをしないのであれば、しなくてもいいかも。

とりあえず、暫定復旧は完了。
あとは、ちょっとしたグレードアップとして
流用したRIMM 8GBメモリx4を、追加購入予定の16Gメモリx4に変更して合計メモリを256GBにするのと、
SAS 300GBx4を、SATA 8TBx4に置き換えを計画するくらいですかね。RAIDは5にするか10にするかは迷っていますが。

奈酢美の部屋　別館

another NSB's room Blog [http://www.amy.hi-ho.ne.jp/masuda/]

HP Workstaion Z820,Z620,Z420 のファームウェアダウングレード方法

MeltdownとSpectre対策のチェック方法

ESXiのSYSLOG設定するためのメモ

異常発生しているOS-HDDの交換

GPDWin2 届きました。

PCNETのブラックマーケットで記念にThinkPad L430のジャンク品ＧＥＴ！！

Windows7でタスクスケジューラでエラー（Windows7から一度Windows10にアップグレード後に元に戻した環境でご注意を）

BSデジタル周波数再編(トランスポンダ変更)に対応したPCでの録画環境設定変更(5/28更新分反映)

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

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

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

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

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

ESXiでsmart値の確認

方法１.esxcliコマンドを使用する方法

方法２．VMware support取得ツールの一部である Smartinfo.sh を利用する方法

Z820にESXi 5.5用e1001eドライバ (Intel 82579LMドライバ) を組み込む

5/9のWindows Update

さらに仮想環境用サーバ壊れました（gt110bサーバ）

突然死したZ800の復旧(Z820へのリプレース)

月	火	水	木	金	土	日
« 5月
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31