奈酢美の部屋　別館

horizon view 環境で、vDGAがちょっとおかしい。

検証環境で、vDGA(以前はVGA Direct Path-Throughといわれていたもの)環境を作成し、Horizon ViewのBlast-ExtermeやPCoIPで接続すると、まれに画面が乱れる現象が発生。特に画面が大きく変動するとおかしくなるようだが、現象が出ないクライアントもあり、原因不明。

環境は、以下の感じ

ハード環境
サーバ：NEC GT110b
CPU：Intel Core i7-860@2.80GHz(4コア8スレッド)
メモリ：16GB
ビデオカード：内蔵VGA,Quadro K2000

VMware環境
vSphare 6.0U3
Horizon View 7.3.2

ゲスト環境
Windows 10 (1809)
CPU 4コア
メモリ 6GB
K2000をDirect Path-Through

で、現象が出るクライアントと出ないクライアントがあり、Horizon Clientのバージョンを疑っていたのですが、どうやら違うみたい。

他に、Horizon Agentを7.3.2から、7.4.0に変更しても同じ・・・・・・

で、原因がやっとわかりました。

それは、Quadro K2000のドライバでした。
弦月時点で最新だった以下のドライバを使用していたのですが、
412.16-quadro-desktop-notebook-win10-64bit-international-whql

今日NVIDIAのサイトを見たら2/5付けで、最新のドライバが上がっていました。
418.81-quadro-desktop-notebook-win10-64bit-international-whql

以下のドライバにしたところ、現象が解決しました。
色々試していたのですが、結局コレが原因だったようです。

改めて調べてみると、最近CPU脆弱性問題で、ドライバの品質に問題が出ていたようで、ちょうどそれにひっかかってしまったようです。

とりあえず、この環境でいろいろ試し中。

（vdgaセットアップ情報）

vSphere側の設定（vSphereは5.1以上推奨）

• K2000のVGAとAudioの２つをDirect Path-Through可能な用に登録（要再起動）
•  「Access Control Services (ACS)」の無効化を有効化（要再起動）　disableACSCheck=True

仮想マシン

• 仮想マシンを作成。
  （HWバージョンは9以上。可能なかぎり最大にしたほうが無難）
• 仮想マシンの作成時に、すべてのメモリを予約。
• PCIデバイスとして、vSGA対応ビデオカードと、そのAudioデバイスを追加。
• 仮想マシンのVMXへ以下の行の追加（メモリを2GB以上割り当てる場合は必須）
  pciHole.start=1200
  pciHole.end=2200
• 仮想マシンのVMXへ以下の行の追加(ESXi 6.0以降は不要らしいですが。)
  pciPassthru0.msiEnabled =”FALSE”
  pciPassthru1.msiEnabled =”FALSE”

セットアップ順序はこんな感じです。

• Windows10インストール
• VMware Tool インストール
• ネットワーク設定
• リモートデスクトップや、Splashtopなどのリモート接続できる環境を構築
  （物理のVGAドライバをインストールすると、VMware SVGAが停止し、vSphereClientのコンソールからアクセスできなくなるため）
• 物理のVGAドライバインストール
  （極力最新版を導入のこと。古いドライバだとHorizon経由で接続で出来ない場合があるようです。）
• リモート接続して、ドライバが入ったことを確認し、View Agent導入。
• リモート接続して、View Agent Direct Connectionを導入（ポートは9443に変更）し、
  「View Agent Direct-Connection Users」ユーザグループに、Horizon Clientから接続可能なユーザを登録
• 仮想マシンをシャットダウンし、仮想マシンのVMXに以下の行を追加
  svga.enableScreenDMA = “True”
• 仮想マシンを起動
• Horizon Clientから、接続テスト。

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

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

どうやら、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に接続している場合は一旦切断されます。)

20190113/rhttpproxyの情報を追加
http://www.getshifting.com/wiki/syslogesxi

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

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

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

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

HP Z820(ESXi5.5U3)に、FirePro W7000を接続して、vSGA環境構築して見ました。
(vSGAについてや、vSGA for Quadro4000 については、こちら)

このHP Z820(ESXi5.5)は既にQuadro 4000でvSGAを使用していましたが、
ESXI6.0になるとQuadro 4000がvSGAデバイスとして使用できなくなりますので、
ESXi5.5の今のうちに動作するかを確認してみます。

なお、HP Z820は公式にFirePro W7000をサポートしているので、そのあたりは安心の構成です。

まずは、ESX5.5を動かしているHP Z820に刺さっているQuadro4000を取り外しし、そのスロットにFirePro W7000に差し替えして、ESXi5.5を起動します。

起動後のW7000の認識は以下の通り

「Module Name: None」となってるので、ドライバは読み込みされていません。
まだ、ドライバを入れていないので当然といえば当然ですが。

では、ドライバを導入します。
メンテナンスモードにして、ESX5.5用のドライバである以下のドライバを導入します。

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

VIBファイル名
「fglrx-12103.1135534-1OEM.550.0.0.1331820.x86_64.vib」

なお、–no-sig-checkをつけないでインストールしようとするとエラーになったので、
オプションをつけて、再実行しています。

再起動は不要となっているようなので、この状態でもう一度ドライバ読み込まれているか確認します。

まだ、ドライバは読み込まれていないようです。
ではインストールしたドライバ名を確認（fglrx）して、強制ロード、再度確認してます。

「Module Name: None」ですので、まだ読み込まれていませんね。
ESXi5.5を再起動してみます。

「Module Name: fglrx」となって、ドライバが読み込まれました。

では、gpuvmで状態を確認してみます。

FirePro W7000はメモリ4GB搭載していますが、ちゃんと認識しています。

ためしにこの状態で仮想マシンを起動して、ログを確認してみます。

仮想マシン起動時に、GPUにアクセスしている形跡がありますね。
ちゃんと、仮想マシンから、vSGAデバイスとして使えているようです。

WebClientから確認してみると、ちゃんとvSGAデバイスとしてGPUを認識しています。
Pitcairn XT GL(AMD)でタイプsharedとなっているのがW7000のようです。
もう一枚NVIDIAQuadro K2000がタイプDirectで認識していますが、後でvDGAで試を予定のものです。この時点では既にESXiカーネルからは切り離されているものです。

これを見て、あれ？っと思った方もいるかもしてませんが、
本来vSGAを使うためには、vSGAで使用するGPUとは別に、ESXiコンソール用にもう一枚VGAカードが必要です。
ただ、この構成でも、ESXiコンソール画面上にちらつきやノイズが出ることがありますが、とりあえず動いているようです。もちろん推奨は出来ませんが。
(Quadro4000のときも同様でした。)

なお、Quadro4000のときと比べると、NVIDIAGPU用のGPUの負荷や温度などを調査出来る「nvidia-smi」コマンドが使用できないため、標準ではこのあたりの情報は取得できないようです。

Web Clientにもそのような項目はないようです。

このあたりはLinux用のコマンドである「aticonfig」や「radeontop」コマンドをESXi用に用意できればもしかしたら取得できるかも知れませんが、現状そのようなものは見つかっていません。もう少し調査してみます。

さて、後はESXiを5.5から6.0にあげれば、なんとか一連の作業は完了しそうです。

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