VMware HCI アセスメント（Live Optics）のすすめ

VMware HCI アセスメント（HCI Assessment） ってご存知でしょうか？

今年の5月にVmware公式ブログで紹介され、従来のアセスメントツールに代わる新しいツールとして利用が始まっていますが、もっと利用されていても良さそうなので今回ご紹介します。

Announcing the new VMware HCI Assessment（Vmware公式ブログ）
https://blogs.vmware.com/virtualblocks/2018/05/01/vmware-hci-assessment/

ちなみに、Vmware ハンズオンラボ（HOL）でもHCIアセスメントに触れることが出来ます。
HOL-1908-01-HCI - vSAN v6.7 - Getting Started
https://labs.hol.vmware.com/HOL/

HOL-1908-01-HCI - vSAN v6.7 - Getting Started のドキュメント
http://docs.hol.vmware.com/HOL-2019/localization/manuals/ja/hol-1908-01-hci_html_ja/

※本投稿は vExperts Advent Calendar 2018 の 12/15 参加分のナレッジとなります。

※ 2019/7 更新 : オフライン アセスメントモードの際の最長データ収集時間が従来の 24時間から 7日間に拡大されました。

vSAN各バージョン毎の設定によるストレージ消費量について比べてみました

vSANを利用している時に、VMストレージポリシーの冗長設定やデプロイ時のThinかThickかの設定によって仮想マシンが消費するストレージ量が異なり、定期的に質問されるので、2018年末時点で現役の各vSANバージョンでの違いをまとめてみました。

特にバージョン毎でOVFテンプレートのデプロイ時の挙動に差があるのと、Flash Web Client と HTML5 vSphere Clientでの挙動の差が意図しない容量消費につながる場合がありそうなので一読いただけると幸いです。

※本投稿は vExperts Advent Calendar 2018 の 12/8 参加分のナレッジとなります。（日時間違えてて12/9投稿となってしまいました…）

※ また、DellEMC でトレーナーをしている Sakai さん が本投稿の続編となる詳細確認を記事にまとめましたので、そちらも併せて参照ください。
vSAN上の仮想マシンのディスク消費量の確認
https://lab8010.com/vsan-disk-usage-check/


今回確認したバージョンは以下の3バージョン。

• vSphere 6.0u3 (vSAN 6.2)
• vSphere 6.5u2 (vSAN 6.6.1)
• vSphere 6.7u1 (vSAN 6.7u1)

それぞれで、VMストレージポリシーでFTT0（冗長無し）、FTT1（RAID1）※vSAN Default Storage Policy、FTT1+100%予約（RAID1）の違い、
vDiskの形式をThinpro、Thick LazyZeroed、Thick EagerZeroedによる違い、
OVFをデプロイする時のvDiskの形式設定の違いとFlash Web Client と HTML5 vSphere Clientでの違いなど、いろいろ比べてみました。

vCenter 6.xの各バージョンの証明書インポート

vCenter Web Clientを利用する際、検証環境での利用がメインだったので
Web Clientを利用する際はいつも証明書の警告を無視して利用していましたがイベントのデモ用でお客様の目に触れる環境を久々に作った際に、6.5以降で証明書がだいぶ親切になっていたので覚え書き。

※証明書インポートしておかないと、データストアブラウザでのファイルアップロードに失敗したりもするので適用しておくことが推奨です。

手順の基本は以下KB参照（KBでは6.0.xの記載ですが6.5以降も基本同じで、一部親切仕様になっています）。
vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

まずはvCenter 6.0.xの画面から。
「▲保護されていない通信」が目立ちます。
証明書のダウンロードは右下の「信頼されたルート CA 証明書をダウンロード」をクリック。

vCenter 6.5では「vSphere Client (HTML5) - 一部の機能」のリンクが追加されていますが基本的に同じです。

vCenter 6.7u1ではHTML5 vSphere Clientにフル機能が実装されたのでメインがHTML5、Flash版はFLEXという名称でサブになっています。
証明書のダウンロード手順は同じです。

ダウンロードしたZIPファイルを解凍すると、vCenter 6.0.xの時はKBの記載通り、
certフォルダに、 xxxxxxx.0 と xxxxxxx.r1 というファイルがあります。

 ここでは
xxxxxxx.0  -> xxxxxxx.0.crt
xxxxxxx.r1  -> xxxxxxx.r1.crl
と拡張子をそれぞれ追加します。

変更後は以下のようになります。

この拡張子の変更作業、vCenter 6.5以降ではZIPファイルを解凍するとWindows用にはフォルダ分けされていてすでに拡張子が適用された状態となり、即利用可能です。
だいぶ親切になりました。

 証明書のインポート手順は各バージョン同じで、crtファイル -> crlファイルの順でインポートします。
Windowsの場合はファイルを右クリックから「証明書のインストール」を選択。

保存先は作業端末なので他のユーザーも利用できるようにローカルコンピュータとしました。

「証明書をすべて次のストアに配置する」にチェックを入れ、「参照」から証明書ストアを選択します。

ここでは「信頼されたルート証明書機関」を選択します。

 「次へ」をクリックし、

「完了」をクリックすれば終わりです。

この操作を、crtファイル、crlファイルにそれぞれ行い、
複数のvCenterなどインポート対象がいくつかある場合は、同様の作業を繰り返します。

証明書のインポート後はWebブラウザを再起動すれば以下のようにすっきりとした画面が開きます。
※接続時にはIPアドレスではなく、FQDNでアクセスしてください。

vCenterもバージョンが進むにつれ、ちょっとしたところが改善されていますね。
お客様に見せる環境などでは見栄えも大事なので証明書は作業端末にインポートしておきましょう。

vCenter6.5のrootアカウントパスワードの失効とvCenter Server Applianceのアップグレード失敗

ここ数年のvCenter Server Appliance(vCSA) 5.5 や 6.0をデプロイすると、初期状態ではrootアカウントのパスワード期限が90日に設定されていました。
90日間越えてしまうとrootアカウントがロックされてしまいVAMI UIやSSHでのログインが不可となります。

この際は以下KBを参照し、LinuxOS側にシングルモードでコンソールログインしてrootアカウントのパスワードを初期化する必要がありました。
vCenter Server Appliance の root アカウントにログインできない (2069041)

vCSA 6.5からは初期状態のrootアカウントのパスワード期限が365日に延長されました。
私も油断していたのですが、検証環境のvCSA6.5が初期状態のままで365日経過してしまいましたが、その時に気づいた今までとの違いをご紹介します。
vCenter 6.5 root ユーザーのパスワードおよびパスワード有効期限の設定の変更

まず、vCSA 6.5の場合、パスワードの期限が切れてもアカウントロックされる事はなく、VAMI UI(https://<vCSA_IP-FQDN>:5480/)や、SSHでのrootログインが可能でした。
この辺りは以前のバージョンに比べるとだいぶ緩くなっています。

ただ、ログイン可能なのですが、VAMIのアカウント管理画面では以下のように、パスワードが過去の時間に切れたことが表示されます。

そして、パスワードの期限が切れている場合はVAMIでのパスワード再設定や、有効期限の無効化の設定は弾かれてしまいます。

先日はこの画面を確認せず、rootアカウントのパスワードが有効なものと思いこんで、vCenterのバージョンアップを実行したところ、以下のようなエラーで失敗しました。

最初はDB容量や空き容量のひっ迫などを疑ったのですが、色々調査するとrootアカウントがおかしいのでは？となり、確認したら有効期限が切れていました。
SSHにもVAMIにもrootでログインできたので気付くのに遅れてしまいました。

vCSA 6.5で有効期限の切れた状態のrootアカウントのパスワード変更は、VAMI UIからは実行できず、SSHかローカルコンソールでvCSAのLinux側にログインしてCLIで passwd
コマンドを投入して再設定します。

再設定後は問題なくvCSAのバージョンアップも成功し、VAMI UIでパスワードの再設定、有効期限の設定変更も可能になりました。

vCSAのバージョンアップ前にはrootアカウントの有効性を確認する事をお勧めします。

vSAN 6.6.x、vSAN 6.7.0環境でResync動作時にVMDKを拡張すると不整合が起きる不具合(KB58715)について

9/18にアナウンスされていたvSAN 6.6.x、vSAN 6.7.0における、
「vSAN Resync動作時にVMDKの拡張作業を行うとデータの不整合が起きる」問題に対応したパッチが提供されました。
最新のvSAN環境でVMDKの拡張したかも？という方はご注意ください。

それぞれESXi 6.5u2 EP7 と、ESXi 6.7 EP9で、以下のKBで詳細は記載されています。

Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation (58715)
https://kb.vmware.com/kb/58715

vSAN 6.7 - Express Patch 4 Release:
http://kb.vmware.com/kb/58848
ESXi670-201810001 Build 10176752

vSAN 6.6 - Express Patch 9 Release:
http://kb.vmware.com/kb/58852
ESXi650-201810001 Build 10175896


元々、回避策として以下のオプションの無効化が指示されていましたので、
今回のパッチ適用の前に、オプションは無効化しておいた方が良さそうです。
・VMDK のサイズを増やしたことのない場合は
　/VSAN/ClomEnableInplaceExpansion オプションを無効（0）に設定。

・VMDK のサイズを拡張した、または拡張したか分からない場合は
　/VSAN/ClomEnableInplaceExpansion オプションを無効（0）に設定し、
　今回リリースされたESXi 6.5u2EP9、6.7 EP4を適用する。

KBでは丁寧にクラスタに対して全ホスト一括で設定できる様にPowerCLIの1Line scriptも公開されておりました。

1	Foreach ($VMHost in (Get-Cluster -Name (Read-Host "Cluster Name") |Get-VMHost)) {Get-AdvancedSetting -Entity $VMHost -Name VSAN.ClomEnableInplaceExpansion | Set-AdvancedSetting -Value '0' -Confirm:$false}

とりあえず、VMDKの拡張を実施していない環境であれば急いでパッチを当てる必要は無さそうですが、リスクを排除するために対象バージョンの修正パッチ以降にバージョンアップするまでは、/VSAN/ClomEnableInplaceExpansion は 0 に変更しておくべきです。

また、vSAN 6.6.1、6.7のどちらも修正パッチ適用後は /VSAN/ClomEnableInplaceExpansion は 1 に戻すことが可能です。
全てのホストの修正パッチ適用後は、以下のようなPowerCLIで一括適用が出来ます。

1	Foreach ($VMHost in (Get-Cluster -Name (Read-Host "Cluster Name") |Get-VMHost)) {Get-AdvancedSetting -Entity $VMHost -Name VSAN.ClomEnableInplaceExpansion | Set-AdvancedSetting -Value '1' -Confirm:$false}

CVE-2018-3646 : ESXi サイドチャネル対応スケジューラの有効化 とその影響

vCenter を 6.0 U3hまたは6.5 U2c、6.7d 以上にアップグレードした環境では、
ESXiホストに対しCVE-2018-3646の対策(ESXi サイドチャネル対応スケジューラ)が有効化されていない場合に、

「このホストにはCVE-2018-3646で記述されている問題に対する脆弱性があります。 詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください」

といった警告メッセージがvSphere Client、Web Client上に出力されます。

対策方法は以下KBに記載がありますが、関連KBが複数あること、
全ESXiで「ESXi サイドチャネル対応スケジューラの有効化」する必要があり、
されには、Vmwareはこの設定の有効化でパフォーマンスが数%低下するとの指標を示しています。
※現状でCPU利用率がひっ迫している環境ではパフォーマンス低下が20%を超える可能性もあるようです。

■ 投機的実行に関連して発生するセキュリティ問題の概要

Intel プロセッサの「L1 Terminal Fault」(L1TF) 投機的実行の脆弱性に対する VMware の対応の概要 CVE-2018-3646、CVE-2018-3620、CVE-2018-3615 (55636)
https://kb.vmware.com/kb/55636?lang=ja

■vSphere環境への「ESXi サイドチャネル対応スケジューラの有効化」手順の説明

vSphere 用 Intel プロセッサにおける「L1 Terminal Fault」(L1TF - VMM) 投機的実行の脆弱性に対する VMware の対応 CVE-2018-3646 (55806)
https://kb.vmware.com/kb/55806?lang=ja

■「ESXi サイドチャネル対応スケジューラの有効化」手順
▼WebClient、HostClientで各ホストの詳細設定で変更する場合

VMkernel.Boot.hyperthreadingMitigation  => true に変更（デフォルトはfalse）

▼ESXCLIで設定する場合
確認方法

esxcli system settings kernel list -o hyperthreadingMitigation

設定方法

esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE

▼PowerCLIで設定する場合
※PowerCLIでの設定方法は確認方法と合わせて以下KBで説明されています。

HTAware 軽減策ツールの概要および使用法 (56931)
https://kb.vmware.com/kb/56931?lang=ja

■「ESXi サイドチャネル対応スケジューラの有効化」した場合の性能影響について

「L1 Terminal Fault - VMM」(L1TF - VMM) の軽減策によって VMware が受けるパフォーマンス面の影響の説明 CVE-2018-3646 (55767)
https://kb.vmware.com/kb/55767?lang=ja

CPUに余裕がある環境では影響は数%だが、CPU利用率が70%を超える環境では20%近いアプリケーションの性能低下が見られます。

■ アセスメントについて

上記KB55806の文中に、利用中の環境がどの程度の影響を受けるかアセスメントするツールがKB56931で公開されているので、
事前に調査する場合は以下を参照ください。

HTAware 軽減策ツールの概要および使用法 (56931)
https://kb.vmware.com/kb/56931?lang=ja

※調査と合わせて、「ESXi サイドチャネル対応スケジューラの有効化」をPowerCLIで有効化する手順が説明されています。

このKBに添付されているZIPフィアルを解凍し、PowerCLIのモジュールとして追加する事で実行しますが、色々とソースを読むと勉強になるPowerShellスクリプトなのでお勧めです。

vSphere6.7U1と vSAN 6.7U1の発表

ラスベガスで開催中のVMworld 2018でvSphere 6.7u1が正式に発表され、公式ブログなどにも情報が出てきました。個人的に気になったものを拾ってみました。

vSphere 6.7u1関連の公式Blog

• Introducing vSphere Platinum and vSphere 6.7 Update 1!
• Under the Hood – vSphere 6.7 Update 1
• Under the Hood – vSphere Platinum

vSAN 6.7u1関連の公式Blog

• What’s New in vSAN 6.7 Update 1
• Announcing vSAN 6.7 Update 1

VMworld 2018のセッション動画は以下URLに順次公開が始まっているようです。

• https://videos.vmworld.com/searchsite/2018

それぞれ、個人的に気になる機能が強化されていましたので、実際に触ってみるのが楽しみです。

リリース時期に関しては

In conjunction with the announcement of vSphere Platinum we also have announced vSphere 6.7 Update 1 (note: general availability will be later this year).

とあるので、もう少し後になりそうです。

気になる強化された機能はざっと以下になります。

• vSphere Client(HTML5)の強化
  以下のように、すべての管理機能がHTML5のvSphere Clientに統合されたようです。 

All administrative functions have now been completed for the vSphere Client

• クラスタ クイックスタート(Cluster Quickstart)
  今までのようにHA、DRS、vSAN、vDSなど機能ごとに有効にして、設定をしていかなければならなかったvSAN Ready Nodesのセットアップも、6.7u1で実装される Cluster Quickstart で VxRailなどのHCIアプライアンスに近いクイックセットアップが実現できそうです。vDSへの移行もサポートしてくれるのは運用のハードルが大幅に下がりそうです。
  クイックスタート機能はESXiホストの拡張時も活用できるようなので、これもVxRailのようにESXiがインストールされたホストをネットワークに接続すれば数分でvSANクラスタへの組み込みが完了してくれるようです。
• vSphere HA、vSphere DRS、vSANなどのクラスタサービスの設定
• ホストの追加 - 複数のホストの同時追加
• vSAN展開タイプの指定
• vDSを含むネットワーク構成
• ディスクグループの設定
• 重複排除と圧縮/暗号化などのデータサービスの設定

This configuration includes HA & DRS, Enhanced vMotion Compatibility (EVC), a vSAN datastore, and networking including a Virtual Distributed Switch (VDS). With Cluster Quickstart you can go from zero to fully functioning cluster in a matter of minutes. And, when it is time to expand the cluster, there is a simple workflow to add new hosts and configure them using the cluster settings used during initial setup.

This new workflow also includes a cluster validation that can be used to ensure all settings have been properly configured on all hosts and will report any discrepancies.

• Update Managerの機能拡張
  Update ManagerでもvSANクラスタの更新時にコントローラドライバ、ファームウェアの更新を適切に実施してくれるように機能が改善されました。
• vSANキャパシティレポートの改善
• vSANでTRIM / UNMAPサポート
  地味にこのTRIM / UNMAPのサポートが長期的なvSANデータストアの運用では嬉しい機能実装と考えています。
• サポート診断の機能強化

HTML5のvSphere Clientがメインになる事で、恐らくそれに合わせてくるVxRail 4.7も新しいUIで機能を実装してくると思われますし、

vSAN Ready Nodes自体も、VxRailに負けないくらいの自動化機能が標準で利用できるようになるのはとても面白そうです。

vSphere Platinum、その他のアップデートはもう少し情報を精査してからまとめたいと思います。

Cheero Power Deluxe 20100mAh のレビュー

少し前ですが、5月末にモバイルバッテリーのCheero Power Deluxe 45W 20100mAh（CHE-094）を購入したのでご紹介。

Cheero Power Deluxe 45W 20100mAh（CHE-094）

元々、USB Type-cコネクタで充電するThinkpad X1 Carbon 2017を外出先で充電可能な大容量バッテリーが欲しいと思い探していたので、この製品を購入しました。

ほぼ同時期に発売された「Lenovo USB Type-C ノートブックパワーバンク(14000mAh)」と悩んだのですが、パワーバンクの売りであると思った「パワーバンクを充電しながらPCにも給電可能」というのが、Thinkpadの角コネクタで充電しながら、Type-cでPCへ出力という仕組みだったので、今さら各コネクタのACアダプタ持ち歩かないし、Cheeroに比べて容量少なくて値段は3倍だったので却下となりました。
ちなみに私が購入した時はAmazonで4,480円でした。

以下、使ってみた感想。

パッケージはシンプル。

同梱物は45cmくらいのType-C - Type-C のケーブルのみ。

起動中のX1 Carbonに接続してみると約45Wで給電されます。

終日開催のセミナーなどに参加して、スマフォでテザリングしながらPCでVDIしていると16時くらいにはどちらもバッテリー残容量が0に近くなりますが、このCheeroがあるとぷらす時間くらい分は充電されるので重宝します。

ThinkpadのType-C 65Wのアダプタで充電すると45W前後で充電されます。2時間もあれば満充電できます。
本体横に記載されている定格は以下の通り。
Input :
  [Type-C PD] 5-20V=45W max
  [Micro USB] 5V=2.1A max
Output:
  [Type-C PD] 5-20V=45W max
  [USB-A] 5V=3A max、9V=2A Auto-IC

満充電に近くなると低速充電になりました。

ACアダプタから充電中のX1 CarbonからType-CケーブルでつないでCheeroを充電しようとしても残念ながら充電はできません。
また、Type-Cの口は一つだけなのでCheeroを充電しながらPCへの給電も不可です（Type-Aから携帯電話などの充電は可能）。

コネクタ接続口はこの様な感じ。
In専用のマイクロUSBの口が不要だからType-Cの口を2つ揃えて欲しかった。

充電中、給電中は側面の青色LEDが点灯、点滅。

8/1からvSphere ESXiのバージョンの呼称が変わった？ (8/2修正:イメージ名が併記されるように修正されまました)

※日本時間8/2の夜にKBが再修正され、バージョン名(ESXi 6.7 EP 02a)、リリース名(ESXi670-201807001)、Build番号が併記されるようになったようです。

vSphere 6.7.0c、6.0u3gがリリースされたのでパッチなどをDLしつつ、バイナリのBuildバージョンと名称のマッチングを確認しようとしたところ、
どうも昨日のKBの更新で、ESXiのパッチリリースに関してはGAバージョン、Updateバージョン以外のパッチバージョンは、「6.7.0c」や「6.0u3g」などの名称を無くし、My Vmwareからダウンロードした際のイメージ名称である「ESXi670-201807001」「ESXi600-201807001」などに呼称を変更したようです。 ※ 8/2に併記されるように変更されていました。

8/2更新のKB
Build numbers and versions of VMware ESXi/ESX
https://kb.vmware.com/kb/2143832

個人的にはMy VMwareのパッチDLページ(https://my.vmware.com/jp/group/vmware/patch#search) で落としたファイル名がそのまま紐づくので、ファイル名 - Build番号 - バージョン名称 と三つを管理しなくてよくなり、かつ日付ベースのバージョン呼称がKBに掲載され、間違い難くなったかなと思います。

ちなみに、8/1更新のKBは以下のような表組で、バージョン名称が削除されていました。
焦ってBlogに一報を載せた次第です。

vCenterなどは従来通り、「6.7.0c」などの名称なので、8/2の更新でESXiがどのvCenterバージョンと同等か判断しやすくなりました。
Build numbers and versions of VMware vCenter Server
https://kb.vmware.com/kb/2143838

Vmware全製品のBuild番号とバージョンの整合は以下のKB参照
Correlating build numbers and versions of VMware products
https://kb.vmware.com/kb/1014508

ちなみに、ここ一年近く更新されていない、日本語版のKBの方は従来の名称のみが掲載されています。
VMware ESXi/ESX のビルド番号とバージョン

https://kb.vmware.com/kb/2147399

お客様向けの導入成果物やパラメータシートに決め打ちの記載がある場合は修正が面倒ですね..

SyntaxHighlighter v4のBlogSpotへの導入と常時HTTPS化

ふと検索結果から自分のブログへアクセスしたところ、PowerShellのコード表示に使っていたSyntaxHighlighterが崩れているのに気づき、
http://alexgorbatchev.com/SyntaxHighlighter/ でお借りしていたv3ではなく、そろそろ自分でv4を用意して、ついでにBlogspotのHTTPS化をすることにしましたので、その際の覚え書きです。

※ Blogspotの常時HTTPSを有効にすると、SyntaxHighlighterのスクリプトをお借りしていたhttp://alexgorbatchev.com/ へのリンクがHTTPだったため、Chromeでは警告が上がりそのままではスクリプトが動作しないため、今までブログ自体はHTTPのままにしていました。

今回たまたま記事の中身がhtmlそのまま出力されていた事に気付き、こりゃまずいと類似事例を探すと昨年末くらいから幾人かが実施していたので、それを模倣しました。

SyntaxHighlighter v4

SyntaxHighlighter v4は現在はGitHubで公開されており、自分でBuildする必要があります。

https://github.com/syntaxhighlighter/syntaxhighlighter

Build方法もサイトにあります。

https://github.com/syntaxhighlighter/syntaxhighlighter/wiki/Building

Photon OS 2.0でBuild環境を作る

Windows 10 のWSLでBuildするか、何か違うもので実施するかを考え、せっかくなのであまり使っている人がいないPhoton OS (v2)で試してみました。

Photon OSもGitHubで公開されているVmwareが開発主導のクラウドネイティブ・コンテナプラットフォームとしての利用を前提とした軽量Linuxです。
vCSA6.5以降など、Vmwareの仮想アプライアンス製品のベースにもなっています。

https://vmware.github.io/photon/

ISOイメージインストーラの他、最小構成で組まれたOVAがいくつか公開されています。
今回はVmware Workstationにデプロイし、SyntaxHighlighterのBuild環境にしました。

※Photon OSのセットアップ、SSHの有効化などは省略します。

Photon OS v2ではgitコマンドは最小構成でも最初から使えます

SyntaxHighlighter v4のBuild

公式のBuild手順に沿って、進めていきます。
https://github.com/syntaxhighlighter/syntaxhighlighter/wiki/Building

1 2 3

$ git clone https://github.com/syntaxhighlighter/syntaxhighlighter.git $ cd syntaxhighlighter $ npm install

npmコマンドはインストールされていないので、nodejsをリポジトリから落としてきます。
※Photon OSはyum互換のtdnfがパッケージ管理ツールとなっています。

nodejsがインストール出来たら、npm install を実行します。

続いてのsetup-projectでFailします。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

root@photon-01 [ ~/syntaxhighlighter ]# ./node_modules/gulp/bin/gulp.js setup-project [12:40:50] Failed to load external module @babel/register [12:40:50] Requiring external module babel-register [12:40:51] Using gulpfile ~/syntaxhighlighter/gulpfile.babel.js [12:40:51] Starting 'setup-project:clone-repos'... [12:40:51] 'setup-project:clone-repos' errored after 1.15 ms [12:40:51] TypeError: loadReposFromCache(...).error is not a function     at loadRepos (/root/syntaxhighlighter/build/setup-project.js:39:48)     at Gulp.<anonymous> (/root/syntaxhighlighter/build/setup-project.js:48:5)     at module.exports (/root/syntaxhighlighter/node_modules/orchestrator/lib/runTask.js:34:7)     at Gulp.Orchestrator._runTask (/root/syntaxhighlighter/node_modules/orchestrator/index.js:273:3)     at Gulp.Orchestrator._runStep (/root/syntaxhighlighter/node_modules/orchestrator/index.js:214:10)     at Gulp.Orchestrator.start (/root/syntaxhighlighter/node_modules/orchestrator/index.js:134:8)     at /root/syntaxhighlighter/node_modules/gulp/bin/gulp.js:129:20     at _combinedTickCallback (internal/process/next_tick.js:131:7)     at process._tickCallback (internal/process/next_tick.js:180:9) (node:2815) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: ENOENT: no such file or directory, open '/root/syntaxhighlighter/.projects-cache.json' (node:2815) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. </anonymous>

ググると先人達の幾人かがBlogにアップしていて、以下のスレッドで回避用のリポジトリが用意されていたのでそちらを利用してやり直しました。
https://github.com/karljacuncha/syntaxhighlighter.git

参照スレ
https://github.com/syntaxhighlighter/syntaxhighlighter/issues/428#issuecomment-360562686

元々標準テーマで利用していたのと、v4からはブラシが1つにまとめられたので、ブラシの指定はAllにしました。
./node_modules/gulp/bin/gulp.js build --brushes=all --theme=default

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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

root@photon-01 [ ~ ]# git clone https://github.com/karljacuncha/syntaxhighlighter.git Cloning into 'syntaxhighlighter'... remote: Counting objects: 3507, done. remote: Total 3507 (delta 0), reused 0 (delta 0), pack-reused 3507 Receiving objects: 100% (3507/3507), 5.93 MiB | 2.45 MiB/s, done. Resolving deltas: 100% (1772/1772), done. root@photon-01 [ ~ ]# cd syntaxhighlighter root@photon-01 [ ~/syntaxhighlighter ]# npm install npm WARN deprecated babel-preset-es2015@6.24.1: ?                                                    Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!   ~省略~   npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})   added 985 packages in 131.415s root@photon-01 [ ~/syntaxhighlighter ]# ./node_modules/gulp/bin/gulp.js setup-project [12:52:06] Failed to load external module @babel/register [12:52:06] Requiring external module babel-register [12:52:06] Using gulpfile ~/syntaxhighlighter/gulpfile.babel.js [12:52:06] Starting 'setup-project:clone-repos'... (node:4077) [DEP0013] DeprecationWarning: Calling an asynchronous function without callback is deprecated. git clone https://github.com/syntaxhighlighter/SyntaxHighlighter-Site.git git clone https://github.com/syntaxhighlighter/syntaxhighlighter-match.git git clone https://github.com/syntaxhighlighter/opts-parser.git     ~省略~   oot@photon-01 [ ~/syntaxhighlighter ]# ./node_modules/gulp/bin/gulp.js build --brushes=all --theme=default [12:53:00] Failed to load external module @babel/register [12:53:00] Requiring external module babel-register [12:53:00] Using gulpfile ~/syntaxhighlighter/gulpfile.babel.js [12:53:00] Starting 'build'... [12:53:02] Theme: default [12:53:02] Brushes: applescript, as3, base, bash, coldfusion, cpp, csharp, css, delphi, diff, erlang, groovy, haxe, java, javafx, javascript, perl, php, plain, powershell, python, ruby, sass, scala, sql, swift, tap, typescript, vb, xml [12:53:02] Hash: cdcdfc450da96aec935d   ~省略~      [52] ./~/domready/ready.js 1.13 kB {0} [built]    [53] ./src/dasherize.js 526 bytes {0} [built] [12:53:02] Finished 'build' after 2.27 s root@photon-01 [ ~/syntaxhighlighter ]# root@photon-01 [ ~/syntaxhighlighter ]# root@photon-01 [ ~/syntaxhighlighter ]# root@photon-01 [ ~/syntaxhighlighter ]# ls dist/ index.html  syntaxhighlighter.js  syntaxhighlighter.js.map  theme.css

無事にファイルが"dist"フォルダに作成されたので、CSSとJSファイルをHTTPSを有効にした個人の別のスペースにアップし、BlogSpotのテーマファイルにリンクを追記します。

これで SyntaxHighlighter の表示も正常になり、BlogSpotの常時HTTPS化も問題なく動作しました。

vCSA 6.5GA から 6.5U1までのデプロイが2018/7/1以降は不可なのでご注意を

最近いくつかvCSAがデプロイ出来ないのだが、という質問を受けているので改めて以下の不具合（？）のご紹介。

Vmware KB 52673 : vCenter Server Appliance 6.5 GA または U1 リリースへのデプロイ、アップグレード、移行、またはリストアが失敗する

vCSA 6.5.0 ～ 6.5u1 のテンプレートに組み込まれた初期のrootアカウントのパスワードが365日でexpireする事が原因で、新規のvCSA 6.5のデプロイ、アップグレードなど失敗します。

デプロイはGUIでもCLIの場合でも失敗します。

この不具合はvCSA 6.5u1cで改修されていますので、今後も順次6.5u1a、6.5u1bもリリースから一年経過後に新規展開は出来なくなります。
vCenter 6.5u1c リリースノート

ここで注意が必要なのが、「リストア」の時です。

現在のvCSAはVAMI画面からのファイルベースバックアップがサポートされていますが、

取得したバックアップデータをリストアする際、本来はバックアップを取得したバージョンで戻すべきですが、同一バージョンに戻せなくなってしまう場合があります。

例）vCSA 6.5.0でバックアップを取得したが、vCSA 6.5u1cに戻す必要がある、など。

ドキュメントを読む限りはESXiのコンフィグリストアと異なり、厳密にBuild番号まで揃えなくても良さそうですが、vCSAが壊れてしまった非常時に安心してリストアするためにもvCenterはなるべく不具合修正された最新版で運用する事が推奨されます。

vCenter 6.5u2で修正されたvCenter 6.0 から 6.5u1 にかけてのクリティカルな不具合とPostgreSQLのDB破損のリスク

5月にリリースされたvCenter 6.5u2のリリースノートに、
いくつか組み込みDBのPostgreSQLが壊れる問題の修正について記載がありましたが、
それとは別に、ちょっと普通のKBとは異なる事象について書かれたKBがいくつかリリースされています。
不具合が確認されている対象が6.0～6.5u1と幅広いので、可能な限りvCenter 6.5u2へ更新したほうが良さそうです。

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html

vCenter 6.5u2で修正されたDB破損の不具合その1

The embedded vCenter Server Appliance database might be corrupted during a full backup
The VMware PostgreSQL database in the vCenter Server Appliance might be corrupted during a file-based full backup if the backup runs in parallel with a quiesced snapshot. The backup generates a backup_label file in /storage/db/vpostgres that corrupts the database if you revert to this specific snapshot. This fix prevents full backups to run during a quiesced snapshot.
This issue is resolved in this release.

vCenter 6.5u2で修正されたDB破損の不具合その2

The embedded vCenter Server Appliance database might be corrupted due to inconsistent snapshots of virtual machines
The PostgreSQL database in the vCenter Server Appliance might be corrupted due to inconsistent snapshots of virtual machines if the database runs on multiple partitions. This fix adds pre-freeze and post-thaw scripts to freeze filesystem partitions while taking a snapshot.
This issue is resolved in this release.

どちらもバックアップとスナップショットの取得で、バックアップしたDBやスナップショットが破損する場合があるとのことです。

上記の修正済みの不具合とは別で、リリースノートに記載はないが6.5u2で修正されたことになっている少し重そうなKBが出ていたので共有します。

一つ目はvCenter 6.5u2のリリースと同じ5/4に出された
vpxd crashes intermittently with an error "Signal 11 received, si_code 1, si_errno 0"
https://kb.vmware.com/kb/52472
2018/05/04

二つ目は6/19に出された
VPXD stops responding and reports error: "Double register of key: 'vm-XXX' and name:" (56353)
https://kb.vmware.com/kb/56353
2018/06/19

どちらもVPXDがクラッシュしてvCenterが運用不可になるというもので、KBの中に復旧方法などの記載は無く、事象が起きた時のログのサンプルと、

Resolution
This issue is resolved in VMware vCenter Server 6.5 Update 2

という記載があるだけです。
恐らく、起きてしまったら復旧は不可の問題かと思われます。

起きてからでは大変なので、定期的なvCenterのバックアップは取りつつ、早めにvCenter 6.5u2への更新が推奨されるようです。

ご参考まで。

vCenter 6.7 での組み込みPSC（Enbedded PSC）が（強く？）推奨されるようです

vSphere 6.7がGAされ2か月ほど過ぎましたが、改めて今後のvCenterのデプロイをどうしようか考える機会があり調べてたところ、Vmwareの公式ドキュメントの中でvCenter 6.7でのEmbedded PSCがやたらと強く推されていたのでご紹介します。

HTML5 vSphere Clientのエンハンスメントの話が多くて陰に隠れてしまいがちですが、
vCenter 6.7では上の図のように、vCenter組み込みの（Embedded）PSCでのリンクモードがサポートされるようになったのと、拡張などの制限が無くなりました。
PSC関連の変更点は以下の様なものとなります。

• 組み込みPSCのvCenterでも最大10台のvCSAとリンク可能
• vCenterHigh Availability (vCenterHA)も併用可能
• 従来のESXi 8台以上は外部PSCの推奨は無しに
• 6.0・6.5からのアップグレードの際に組み込みPSCへの変更が可能
• 5月にリリースされたvSphere 6.5u2にも6.7の組み込みPSCのポリシーは適用

このEmbedded PSCでのリンクモード、従来のvSphere 6.0、6.5では以下のKBに記載があるように非推奨となっていて、VCAP6-DCVのDesign試験などにも普通に出てくる"仕様"でした。

※ 6.0がリリースされた当時はこんな制限なかったのですが、いつからか非推奨になってしまいました。

List of recommended topologies for VMware vSphere 6.0 (2108548)

https://kb.vmware.com/kb/2108548

Supported and deprecated topologies for VMware vSphere 6.5 (2147672)

https://kb.vmware.com/kb/2147672

vCenter 6.7（vCenter 6.5u2も）からはこの制限が無くなり、Embedded PSCが自由に使えるようになる程度に考えていたのですが、
ドキュメントを読んでいくとVMwareがかなりEmbedded PSC構成を推している事が分かりました。

むしろ180度方針転換してExternal PSCを非推奨にしているようにも見えます。

公式ドキュメントに以下の記載があります。
vCenter Server および Platform Services Controller のデプロイ タイプ

■Embedded PSCについて

Embedded PSCの項目には「Platform Services Controller が組み込まれている vCenter Server をインストールすることには、次のようなメリットがあります」と、メリット推しの説明。

• vCenterとPSC間のWebClient利用時の接続性と名前解決の問題が無い
• 管理する仮想マシンが少なくて済む
• バックアップもvCenterのみで良い

等のメリットがあります。

■External PSCについて

一方、External PSCの説明の項は、メリットの説明は無くデメリットの説明のみ…
「外部 Platform Services Controller を使用する vCenter Server をインストールすることには、次のようなデメリットがあります」

今までExtenal PSCをあれだけ推奨していたのに、180度方針が変わったようです。
vSphere 6.7の新規導入の他、バージョンアップ、移行を検討されている場合は、そのタイミングでEmbedded PSCタイプに変更も可能ですので今後は管理をシンプルにするためにEmbedded PSCでの運用を検討されては如何でしょうか？

vSphere 6.5 Update2 のリリースと気になった修正点

GWの最中、検証環境のバージョンアップを予定していたのですが、日本時間の5/4にvSphere 6.5 Update2がリリースされたので6.5u1環境に適用してみました。

アップデート内容の詳細、適用方法などはリリースノートと公式ブログを参照してください。vSpehre 6.7の新機能などが後方適用されてたりします。
vCenterとしてのバックアップ・リストアの不具合など結構重要な修正が入っているので、今後vSphere 6.7は考えているけど、今すぐメジャーバージョンアップは、、、という方は当面は6.5u2を適用したほうがよさそうです。

※Vmware Blogの記事は以下参照
vSphere 6.5 Update 2 Now Available

リリースノートに詳細がありますので合わせて参照ください。
[英語] https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html

[日本語] https://docs.vmware.com/jp/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html


以下に、個人的に「お、ようやく直ったか」という地味なアップデートと、注意事項がありましたのでご紹介します。

■ vSphere 6.5u2 へのアップグレードとvSphere 6.7へのアップグレードの注意

-- リリースノートからの抜粋 --

本リリースのアップグレードに関する注意点
重要：vCenter Server 6.5 Update 2 から vCenter Server 6.7 へのアップグレードおよび移行パスはサポートされていません。

----

→ 6.5u2より前にリリースされた6.7GAへのアップグレードはサポートされないので、6.5u2を適用した場合は、次の6.7.x や、6.7u1が出てからのアップグレードが必要となるようです。

-- リリースノートからの抜粋 --

外部の vCenter Single Sign-On を使用する 環境でvCenter Server 5.5 Update 3b より前のバージョンから、外部の Platform Services Controller を使用する vCenter Server 6.5 Update 2 へのアップグレードまたは移行はサポートされていません。たとえば、外部の vCenter Single Sign-On を使用する vCenter Server 5.5 を外部の Platform Services Controller を使用する vCenter Server 6.5 Update 2 へアップグレードまたは移行する場合、先に vCenter Server 5.5 Update 3b へアップデートしてから、vCenter Server 6.5 Update 2 へのアップグレードまたは移行を実行する必要があります。
vCenter Server 5.5 Update 3b のビルド番号は次のとおりです。
vCenter Server 5.5 Update 3b ビルド 3252642
vCenter Server Appliance 5.5 Update 3b ビルド 3255668
組み込みの vCenter Single Sign-On を使用する vCenter Server 5.5 以降から、組み込みの Platform Services Controller を使用する vCenter Server 6.5 Update 2 へのアップグレードまたは移行はサポートされています。

----

→ 5.5u3b 以前の外部SSOを利用するvCenter環境は、6.5u2への直接アップグレードはできないので、5.5u3b以降に更新してから6.5u2を適用します。
今年の8月でvSphere 5.5のGeneral Supportが終了するのでこれから更新を検討する方は多いかと思いますが注意点となります。

■ESXiホストの電源ユニットの片系断状態を正しく検知してアラームが上がるようになりました。

経験ある方ならわかるかと思いますが、以前のバージョンではESXiホストの電源が冗長化されていて、2系統で電源供給されているときに片系落ちると、ハードウェアステータスとしては電源断が判定されるけど、アラームが上がらない（WebClientでの視認やメールなどの通知ができない）問題がありました。

それがようやく修正されたようです。
お客様先でシステム導入時の障害検証で正しく検知されない、といったこともなくなります。

-- リリースノートからの抜粋 --

vSphere Web Client で、一部のハードウェア健全性ステータス アラームが失われ、センサーが誤ったグループに表示される可能性がある
ハードウェア センサーからの問題、または接続されていない電源などのハードウェアの問題によって、vSphere Web Client の [ハードウェア ステータス] タブでアラームがトリガされない可能性があります。ハードウェア センサーが、誤ったカテゴリに表示される可能性があります。たとえば、ストレージからのセンサーが電圧グループに表示される可能性があります。
本リリースで、この問題は修正されました。

----

ただ、検証環境やデモ環境などで設備の制限で片系しか給電できなかった環境では、
6.5u2適用と同時に一斉にホストにレッドアラームが表示されてしまい、非常に見た目が悪くなってしまいます。

アラーム自体は「ホストのハードウェアの電源状態」という、vCenterのトップ階層に設定されたデフォルトアラーム定義なので、これを無効化すればアラームは表示されなくなりますが、本来のアラームの目的とは真逆の設定なのでご注意ください。
※個別のホスト、クラスタでアラームを無効化したい場合は逆のカスタムアラームを作成すれば打ち消せるかもしれませんが、少し面倒そうなので時間ができたら試します。

vSphere 6.7 のリリースと vSphere Replication 6.7のリリース

先週あたりからvROpsやLogInsightの新しいバージョンがリリースされ始めてましたが、
日本時間の昨夜ようやくvSphere 6.7がGAされ、併せていろいろな関連コンポーネントもダウンロード可能になりました。

My Vmwareを確認すると Enterprise Plusだとこの辺りが現時点での公開状況です。

vSphere 6.7のリリースノートは以下参照。
https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vsphere-esxi-vcenter-server-67-release-notes.html

vSphere 6.7の新機能は最終的にどうなった？と思ってリリースノートを見ると
公式ブログ見てくれの一行のみでした…
https://blogs.vmware.com/vsphere/launch


個人的に気になったのは、vSphere Replication。これだけ Ver 8.1と飛んでます。
以前にAWSとのReplication対応用にSRMの前バージョンを合わせて8.0と飛んでしまっていたので、そちらにバージョンを合わせたようですが、従来のvSphere Replication 8.1は大きく変わったところがあります。

vSphere Replicationのリリースノートは以下参照
https://docs.vmware.com/en/vSphere-Replication/8.1/rn/vsphere-replication-81-release-notes.html

こちらは新機能のサマリがまとまっています。まとめると、

• UIがvCenter 6.7に合わせてHTML5に
• ベースOSがPhotonOS 2.0ベースになってよりセキュアに軽快に
• 複数のVMware vSphereバージョンをサポート（！）、6.0u3以降をサポート

• Support for multiple VMware vSphere on-premises versions. vSphere Replication 8.1 is compatible with VMware vSphere 6.0 Update 3 and later, including 6.7. For interoperability with the releases of VMware vSphere, see the Compatibility Matrices for vSphere Replication 8.1.

今までのvSphere Replicationだと、必ずvSphere(vCenter+ESXi)のバージョンと、vSphere Replicationのバージョンは1:1でしか対応していなかったのが不満で、
本番サイトとバックアップサイトの両方を同時にバージョンアップしないと、Replicationが維持できないという残念な制限がありました。

今回のvSphere Replication 8.1からはとうとうその制限がとれ、最近のバージョン（6.0u3以降）をマルチにサポートするようになったようです。

しかし、さっそくVMware Product Interoperability Matricesで確認すると、
？？
今日の時点ではまだ反映されていないのか？vCenterとは1世代のサポート、
ESXiとの組み合わせには表示が選べませんでした…

※ 2018/4/20 Update
Interoperability Matrices がアップデートされ、vSphere Replication 8.1、SRM 8.1のそれぞれについてリリースノート通りに更新されておりました。

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&2=
【before】

【after】

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&1=
【before】

【after】

4/18時点では確認できませんでしたが、リリースノート通りにマルチvSphereバージョンをサポートしてくれるとかなり強力な機能強化になりそうです。

ちなみに、Site Recovery Managerの方も、リリースノートには以下の様なWhat's Newが記載されており、こちらもマルチvSphereバージョンをサポートする様ですが、同じように4/18時点ではまだそのサポマトは反映されておりませんでした。
https://docs.vmware.com/en/Site-Recovery-Manager/8.1/rn/srm-releasenotes-8-1.html

• VMware Site Recovery Manager 8.1 is compatible with VMware vSphere 6.7. In addition, Site Recovery Manager 8.1 introduces backward compatibility with previous versions of vCenter and vSphere, as detailed in the Compatibility Matrixes for VMware Site Recovery Manager 8.1
• Streamlined HTML 5 user interface. New HTML 5 UI enhances the overall user's experience by simplifying the deployment and usage, and enabling streamlined workflows - unified replication and protection, site pairing, and more.

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&7=&2=

↑ SRM 8.1はvSphere 6.0u3から6.7まで広くサポートされています。

※vSphere Replication と SRM は基本的に8.x同士で組み合わせます。
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&7=

【before】

【after】

SRMの1代サポートにはだいぶ悩まされてきたので、これが改善されると非常に助かります。

サポマトの更新に期待です。 → 4/20 更新されました。