Horizon7になって、TLS1.0が無効なったりして、各セキュリティ対策がされた結果、
シンクライアントやゼロクライアント端末で接続できないケースがあります。

ちょうど手元に以下の端末があったので、いろいろ試してみました。
（今なら秋葉原でADアダプタ付きで500円で買えます。）

・Dell Wyse 5030 PCoIP Zero Client
・Dell Wyse C10LE シンクライアント

Dell Wyse 5030 PCoIP Zero Clientの場合
、
Dell Wyse 5030 PCoIP Zero Clientは、その名前の通り、PCoIP特化のZeroクライアントとなる。
ただし、Horizon 7のConnection Serverには接続できるが、各VDIに接続しようとするとエラーになります。

この場合、最新のファームウェアにアップデートすることでHorizon7環境でもアクセス可能になる。

最新ファームウェア
https://www.dell.com/support/home/jp/ja/jpbsd1/drivers/driversdetails?driverid=v9w0h

tera2_5-5-1_fw-r5_5@46605.zip

更新方法としては、起動後にIPアドレスを確認したうえで、
通常PCのブラウザでそのIPアドレスにアクセスすると、ログイン画面となるのでログインします。
その際のパスワードですが、デフォルトでは「Administrator」となるようです。

その後、Webインターフェイス経由で、ダウンロードしたファームウェアを送信することで、アップデート可能です。

詳しい手順はこちら参照。
Dell Wyse 5030 PCoIP Zero Client User Guide
https://www.dell.com/support/manuals/jp/ja/jpbsd1/wyse-p25/5030_zero_client_ug/system-specifications?guid=guid-c800db16-53df-4471-b734-c22b225c84c0&lang=en-us

Dell Wyse C10LE (Cx0)の場合

ICAやRDP接続接続は可能だが、Horizon 7のConnection Serverに接続しようとする時点で、以下のようなエラーとなり接続できません
「error ERR_SSL_BAD_HEADER_VERSION」

しらべてみるとHorizon 7 対応は、8.3以降の模様（ただし接続はRDPになってしまう模様）

イメージは正式なURLではありませんが、以下からダウンロード可能

https://www.technicalhelp.de/downloads/

・C10LE-8.0_037-128-Merlin (C10LE-8.0_037-128-Merlin (3).zip) 8.0_037 へのUSB Install Image用ファイル
・C10LE 8.0_512(C10_wnos_2)  8.0_512 へのイメージ更新用ファイル
・C10LE 8.3_109 (C10_wnos)     8.3_109 へのイメージ更新用ファイル

7.1_033から8.0_037へのアップグレードは、DellWyseUSBImagingToolでUSBを作成し、OSアップデートします。
https://www.dell.com/support/article/jp/ja/jpdhs1/sln289677/wyse%E3%82%B7%E3%83%B3%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%ABusb%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%82%B9%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95-%E8%8B%B1%E8%AA%9E?lang=ja

参考

DellWyseUSBImagingToolのダウンロード先
https://downloads.dell.com/wyse/USBFT/2.1.0.12/

これ以降の更新、8.0_037から8.0_512、8.0_512から8.3-109に変更する場合は、
以下のドキュメントの通り、FTP経由でのアップデートとなります。
ただし、この更新はシンクライアントの電源を落とすとなくなってしまいますので、注意が必要です。
なお、8.0_037 -> 8.0_512 -> 8.3-109と順番に起動しないと8.3-109更新時に「Invalid File Format」と表示され、OKをクリックすると更新はされて接続できるようになりますが、電源を一度落とすとバージョンが戻ってしまいます

更新手順としては、以下のURLを参照です。
https://vditoolbox.files.wordpress.com/2017/09/wtos-ftp-http-https-ccm-upgrade-methods-rev-k-kb10566.pdf

\wyse\wnos.ini
中身の例としては以下の通りです。
Autoload=2
Signon=0
FactoryDefault=Yes
Language=jp

（wnos.iniの書式については以下が参考になります。）
（https://www.yumpu.com/en/document/read/58947863/wtosdell-wyse-thinos-83-and-thinos-lite-23-hot-fix-rn）

\wyse\wnos\C10_wnos.jp
ダウンロードした8.3_109 へのイメージ更新用ファイルを配置
（ファイル名最後の.jpは日本語キーボードを設定している場合に必要みたいです。）

なお、USBからブートするための変更でC10LEのBIOSの入り方などは以下のような記事が参考になります(BIOSパスワードは「Fireport」のようです。)。
https://pc.watch.impress.co.jp/docs/news/yajiuma/1184754.html

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

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

どうやら、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

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

このツール便利。

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

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

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

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

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

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

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

メインの録画環境を動かしている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

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

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)です。

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

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

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

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液晶だけどなんとかセットアップ完了。

後でいろいろ試す予定。

いつの間にか、タスクスケジューラーを開くとエラーメッセージが出るようになっていたみたい。
「タスク イメージは破損しているか、または変更されています。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つの修復が失敗しました。
失敗したタスクは以下の５つでした。
（複数のマシンで修復を実施しましたが以下の５つは失敗するみたいです）

この５つが、残ったエラーになる原因です。
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での録画環境の設定変更が必要な模様です。
（特にBonDriverを使用した録画環境の場合は必須の模様）

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

某掲示板より

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

BonDriver_PX_Q3PE_S0(PX-Q3PE S0).ChSet2.txt

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

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

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

「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

今、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、下手すると３桁万円クラスなので、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で動かせなくなってしまいます。

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

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

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

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

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

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

• virtualHW.version = “11”

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

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

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

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

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

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

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

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

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

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

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

• 送風機
  電源入れても起動せず
  ->予備機と交換
• サーバ（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になります。

さて換装しよっかな

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

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

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仮想マシンの１台のみ）
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として追加させますが、ここで注意が１つ。
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はまだがんばってもらえそうです。）

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

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

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

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

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

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

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

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

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

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

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

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

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

メインの仮想環境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拡張した後に、
この環境もマージできるように各種単体機能テストをしようかと考えていたのだけど、このタイミングで完全に壊れるとは・・・