長年利用しているノートＰＣである「GALLERIA QF970HG」の調子がすこぶる悪い。

Driver Power State FailureやPage faultが頻発するようになってきた。
Driver Power State Failureは、ドライバの更新でちょっと落ちついたが、その分Page faultが頻発してしまうように。

このＰＣは操作コンソール用なので、調子が悪くなっても再起動すればいいのだが、
（メインサービスは、別部屋で稼働させている別サーバ[Z820 Xen E5-2687W x2 , MEM 256GB のESXi]で処理しているので)
そろそろ、CPU性能2倍になるノートが出始めたので、安定できなさそうであれば新PC購入も検討しないとという段階なのだが、現状性能的に困っていないというのも事実だったりもする。

Windows標準のメモリチェックしても、特に問題は見つからなかったので、難儀していたのだが、Memtest64を1晩回したら特定のパターンでのみエラーを検知。
1枚ずつ調査したら、４枚中２枚でエラーという悲惨な状況でした。

とりあえず、エラーの出たメモリモジュール2枚を外してメモリ16GBで稼働中
現状は安定稼働しているので、新ＰＣ導入はもう少し後になりそうだ・・・。

ただ、このモデルのメモリの交換は結構癖があり、情報がぜんぜん見つからなかったので改めて調査したので健忘録としてメモ。

---

GALLERIA QF970HGのスペックは以下の通り(私の使用しているモデル)
ドスパラの17インチゲーミングノート GALLERIA（ガレリア） QF970HG レビュー

・17.3インチ液晶(1920×1080)
・インテル Core i7-4710MQ (4Core/HT対応/定格2.50GHz/TB時最大3.50GHz)
・32GB DDR3 SO-DIMM (PC3-12800/8GBx4/デュアルチャネル)
・GPU Intel HD 4600 + NVIDIA GeForce GTX970M 6GB
・SSD MSATA 256GBx1
・HDD 2.5インチ 2TBx1
・BD-Reドライブ

色々調べてみると、この機種はMSIのGT70というゲーミングPCをドスパラがカスタマイズイズしたもののようだ。
大きな違いだと、
GT70（20Dモデル）だと、CPUが4700MQ、GPUがGeforce GTX780Mが、
QF970HGの場合は、CPUが4810MG、GPUがGeforce GTX970Mになっています。

これは、ビデオカードがMXM規格という交換可能なモジュールとして搭載されているので、CPUだけでなくいろいろなGPUに対応できるので、ドスパラにもGALLERIA QF970HGの兄弟機として、GTX980Mを搭載した「QF980HG」というモデルもあります。

---

分解方法ですが、MSI GT70としての分解説動画がyoutubeにいくつかあるので、参考になります。

How to Replace Laptop Motherboard | MSI GT70

MSI GT70 MS-1762 disassemble to clean cooling system and detect graphic card problem

MSI GAMING G Series GT70 MS-1763 Laptop dc power jack repair fix charge port broken socket

Take Apart MSI GT70 Gaming Laptop

この機種は比較的メンテナンス性はいいほうですが、メモリ交換についてはちょっと注意が必要です。

このモデルはメモリモジュールが４枚付けられるモデルなのですが、２枚はキーボード裏からアクセス。残り２枚は背面カバーを開けたところからアクセスです。

キーボード裏のメモリは、以下のようにアクセスします。
・背面カバーのキーボードマークがついたねじを外します。
・キーボード上部の境目に５か所ほどくぼみがあるので、そこにマイナスドライバを突っ込んでキーボードの上部にあるのパネル（電源ボタンなどがあるパネル）を外します。
・キーボード上部が５か所のネジで止まっているのネジを外して、上方向にスライドさせると取り外せます（ケーブルを外す必要はありませんが、注意してください）。
・キーボードの裏側にある２枚のシートをめくると、メモリモジュールにアクセスできます。

背面カバー側のメモリは、以下のようにアクセスします。

• 背面カバーのネジを外すと、メモリモジュールスロットが見えます
  ただし、GPUのヒートパイプが邪魔をして、メモリモジュールの取り外しができませんので、以下の手順でGPUのヒートシンクと、CPUのヒートシンクを外す必要があります。
  • ファンモジュールがあるので、ネジを１つ外して、ファンモジュールを取り外します（ケーブルも外します）。
  • GPUのヒートシンクネジ（４つ）とCPUのヒートシンクネジ（３つ）を外すと、GPU,CPUのヒートシンクが外れます（GPUだけでも外れますが耐熱ゴムでくっついているので一緒に取り外したほうがいいです）。
  • これで、メモリモジュールの取り外しができます。
    （元に戻す際は、GPU,CPUの塗り直しをしたほうがいいかもしれません。）

---

その他保守情報

背面カバー＆ファンモジュール取り外し後の状態：

BIOS設定画面表示：
PC起動直後にDEL連打

起動メディア選択：
PC起動直後にF11連打

バッテリの型番：
BTY-M6D　（まだAmazonなどで入手できます）

メモリモジュール種類：
DDR3L 1600(12800) SODIMM (1.35V) 最大４枚まで(8GBｘ4=32GB)

MSATAスロット：
３つまで搭載可？

2.5インチHDD：
1つまで搭載可

ファンモジュール：
PABD19735BM-N273

MXM GPUモジュール：
AMAZONに、GT70用のGTX1060のMXMモジュールがありました（GPU性能は1.4倍くらいになるようだけど・・・）
ただ、BIOS側のサポートも必要になるようなので、動くかどうかは賭けですね。

vSphere esxi5.5, 6.0, 6.5等にCPUの脆弱性の対策パッチを適応すると、CPUの脆弱性（Spectre、Meltdown、及びL1 Terminal Fault）の対策（緩和策）が実施されます。
これは、投機的実行の制御メカニズムを利用するためのフレームワーク、またはCPUのマイクロコードにて対策用の命令を追加することで対応しているようです。
（詳細：ブランチ ターゲット インジェクションに対するハイパーバイザーアシストによるゲストの軽減 (52085)）

• ESXi 6.5：ESXi650-201803401-BG* および ESXi650-201803402-BG**
• ESXi 6.0：ESXi600-201803401-BG* および ESXi600-201803402-BG**
• ESXi 5.5：ESXi550-201803401-BG* および ESXi550-201803402-BG**

* これらの ESXi パッチは、ゲスト OS が新しい投機的実行の制御メカニズムを利用するためのフレームワークを提供します。これらのパッチにはマイクロコードは含まれません。

**これらの ESXi パッチは、Sandy Bridge DTからKaby Lakeのマイクロコードの更新を適用します。これらのパッチには、前述のフレームワークは含まれていません。

ただし、vMotionを利用する場合などで、EVCを定期していても対策済のESXiと未対策のESXiとの間で稼働中のVMを移動したりする場合はうまく移行ができないときがあります。
（送信元ホストに Spectre/Meltdown の緩和のためのパッチが適用されており、試行された宛先ホストにはパッチが適用されていない場合等で発生します。）

また、vCenter 5.5U3h, vCenter 6.0U3e, vCenter6.5U1g以降などでは、対策済で、
同一クラスター内で対策済のESXiと未対策のESXiが混在している場合は、脆弱性の緩和策を無効化することで不具合が起こりにくいようになっているようです。

ただし、複数のクラスタを作成している場合や、拡張リンクモードなどを利用している場合等は、緩和策が有効になっているものと無効になっているものが混在する可能性があり、結果vMotionが正しくできない場合があります。

このため強制的に、パッチが適応されたＥＳＸでも、脆弱性緩和策を無効化する方法があったので紹介します。（もちろんお勧めしません）

あと、あまりに古いCPU（Sandy Bridgeより前のCPU世代等）を利用している場合には、対策パッチを適応しても効果がない可能性もあるので、その場合にも有効かもしれません。
（OSの速度低下デメリット解消にも使えるかもしれません）

あとこの脆弱性緩和策（Hypervisor-Assisted Guest Mitigation）は、VMのHWバージョンが9以上出る必要があるようです。

　

VM単位で設定する場合

対象VMのVMXに以下の行を追加します。

featMask.vm.cpuid.stibp = “Max:0”
featMask.vm.cpuid.ibrs = “Max:0”
featMask.vm.cpuid.ibpb = “Max:0”
featMask.vm.cpuid.stibp = “Max:0”
featMask.vm.cpuid.fcmo = “Max:0”

なお、vSphere Clientからだと、仮想マシンを右クリックし、[設定の編集(Edit Settings)] > [仮想マシン オプション(VM Options)] > [詳細(Advanced)] > [構成パラメータ(Configuration Parameters)] – [構成の編集(Edit Configuration)] の順にクリックすることでも設定可能です。
（この場合、設定値は、Max:0 と””を外したものを設定します。）

ESXi単位で設定する場合

対象ESXにSSHなどでコンソールに入り、/etc/vmware/config ファイルに以下の行を追記または該当行を修正します。

featMask.evc.cpuid.IBPB = “Val:0”
featMask.evc.cpuid.IBRS = “Val:0”
featMask.evc.cpuid.STIBP = “Val:0”
featMask.evc.cpuid.SSBD = “Val:0”
featMask.evc.cpuid.FCMD = “Val:0”

なお、vCenterでEVCが有効になったクラスタにESXiを追加、削除したときには、この設定が上書き（または削除）される可能性がありますので、ご注意ください。
また、ESXiを再起動しても、vCenterから接続されてクラスタに追加された段階で設定が元に戻りますので、再設定が必要です。（永続的にできるかどうかは未確認）
クラスタにあるESXiがすべて対策済パッチ適応済の場合のみ、脆弱性緩和策が有効になります。（なお脆弱性緩和策が有効になったクラスタには、対策済パッチ未適応のESXiは追加できません。）

また、脆弱性緩和策を無効化したESXiの場合は、ESXiのサマリに警告が表示される場合があるようです。この場合は、ESXiのシステムの詳細設定で以下のように設定します。
名前　：UserVars.SuppressHyperthreadWarning
設定値：1

参考

ブランチ ターゲット インジェクションに対するハイパーバイザーアシストによるゲストの軽減 (52085)

同じ構成の ESXi ホストの EVC クラスタ間での vMotion による移行が失敗する (67666)

8.1 CPUの脆弱性への対応 – 8.1.4 留意事項

いつの間にかESXIのHYpervisorのパスワードポリシーが厳しくなっていたようです。
ひさびさにパスワード再設定して気づきました。

パスワードの複雑性として「数字、アルファベット小文字、アルファベット大文字。記号」のうち３種類を含んだものでないと、変更できなくなっていました。

調べてみると、以下の方法で、パスワードポリシーを変更できるようです。

ESXiのWeb GUIにログインし
ナビゲータメニューより、「管理」→「詳細設定」をクリック
「Security.PasswordQualityControl」の値を変更することでポリシーを緩めることができる

デフォルト設定値は以下のようになっていました。

minのフォーマットはmin=N0,N1,N2,N3,N4で、各項目の意味は以下の通りとのことです。

項目	対象	意味	既定値
N0	パスワード	文字クラス1の場合の長さ	disabled
N1	パスワード	文字クラス2の場合の長さ	disabled
N2	パスフレーズ	全体の長さ	disabled
N3	パスワード	文字クラス3の場合の長さ	7
N4	パスワード	文字クラス4の場合の長さ	7

N0,N1,N2,N3,N4の設定時には、N0≧N1≧N2≧N3≧N4の条件を満たす必要があります。
(Disabledは2147483647相当)

文字クラスとは、パスワードが何種類の文字で構成されているかを示すもので、
文字を以下の4種類に分けられている模様。

・数字
・アルファベット小文字
・アルファベット大文字
・その他 (記号など)

そのため、
passwordは小文字のみなので、文字クラス1、
P@sswordは小文字と記号の２種類なので文字クラス2となる。

今回は文字種制限をゆるくすることにして、1種類のみでも設定できるように変更しました。
（パスワード文字長は最短7文字で設定）
以下の設定値に変更することでパスワードポリシーを変更すればOKです。

変更後

参考
ESXi Passwords and Account Lockout