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