vCSA6.5アプライアンス シェルのAPI
vCSAをコンソールで開くと、まず始めにアプライアンス シェル画面が表示されます。
vCenter Server Appliance シェルの API コマンドvCenter Server Appliance の API コマンドを使用すると、vCenter Server Appliance のさまざまな管理タスクを実行できます。これらの API コマンドは、vCenter Server Appliance のアプライアンス管理サービスによって提供されます。時刻同期設定の編集、プロセスとサービスの監視、SNMP 設定のセットアップなどを実行できます。
例:
・com.vmware.appliance.version1.system.version.get
アプライアンスのバージョンを取得します。
・com.vmware.appliance.version1.system.time.get
システム時刻を取得します。
また、割と統計情報や健全性情報をCUIで得られるのがポイント高めです。その紹介は後日。
仮想マシンメモリのオーバーヘッド
vSphere5.5まではオーバーヘッドメモリの一覧表がドキュメントに記載されていました。6.0では一覧表がなくなってしまいましたが、6.5になってまたドキュメントに記載されるようになっていました。
vSphere 5.5の場合
vSphere 6.0の場合
vSphere 6.5の場合
数字としては5.5 - 6.5で変わらないようです。ドキュメントに復帰した理由は不明ですが、ちゃんと記載されることでオーバーヘッドを意識できるようになったのは少し嬉しいですね。
仮想マシンの電源操作ボタンの調整
vCSA6.0,6.5のsysprep格納場所
基本は以下KBを元に設定すれば良いと思います。
Sysprep file locations and versions (1005593)
ただ気になったのはvCenter Server Appliance。
Virtual Appliance 5.x and later /etc/vmware-vpx/sysprep/
何故vCenter Server Applianceを抽出したかというと、「5.x laterは果たして6.0,6.5まで該当するのか?」という懸念を持ったためです。
ドキュメント/KBに記載がなかったので記録として。
vSphere 6.5導入のVMware 拡張認証プラグイン(Web Client)
vSphere6.0から6.5にかけて、Web Clientで使用するプラグインが変わっています。
気になって調べてみました。わかった範囲でのご紹介。
それぞれの機能例が以下。
6.0は多くの機能をプラグインにまとめていましたが、6.5だとすっきりしていますね。
○クライアント統合プラグイン(6.0)
・統合Windows認証
・OVF/OVAテンプレートのデプロイ(自端末のファイルから)
・仮想デバイスの接続
ゲストOS に対する、インストール メディアのアップロード など
・Web Clientコンソールの一部の特殊操作
画面最大化 など
○拡張認証プラグイン(6.5)
・統合 Windows 認証
・Windows ベースのスマート カード機能
OVF および OVA テンプレートのデプロイ
ゲストOSに対してisoイメージを認識させる機能についても、ドキュメント記載の前提条件からプラグインの記述が外されています。
ESXi 6.0U1b上でカスタマイズが失敗する現象
WindowsのゲストOSをカスタマイズする時に、Sysprepのカスタマイズエラーが出て困った件。
Guest OS customization of a Windows virtual machine fails to complete on a ESXi 6.0 Update 1b host (2142982)
https://kb.vmware.com/kb/2142982
・あるESXiを6.0 update 1bへアップグレードする
・その上のWindowsOSのVMware toolsを、ESXiの最新バージョンにアップデートする
上記の状態だとVMクローン実行時設定できるゲストカスタマイズが失敗します。これはvSphereだけでなくHorizonのsysprep利用時にも起こるかと(検証していないのでquickprepは不明)。
Sysprepが失敗するからWindowsの中の話のみと思いきや、Toolsが原因してたなんて・・・と思った次第。
ワークアラウンドとしては、VMware toolsをアップグレードではなく再インストールすることで対処できます。
現状パッチはありませんが、局所的な問題であるはずなので今後改善されるのでしょうね。
vSphere 6.0におけるvSphereHAのパワーオフVMの挙動について
vExpert Advent Calendarに触発されて何か1件出してみようかと思い投稿です。
私は今年もブログ月一更新を達成できず・・・残念・・・。
vForum2015のあるセッションでも一部話が出ていたのですが、vSphere 6.0になってHAのある挙動がこっそり変更されました。
従来(~vSphere5.5)、vSphereHA構成のクラスタにおいて、ホスト障害が発生した際、
・パワーオンVM:別のホストで再起動します
という挙動になっておりました。
ですが、vSphere6.0での場合、後者VMは別ホストに再登録されるようになります(再起動は実施されません)。
この処理は計画的なホストシャットダウンでも発生する可能性があるため、不用意にホストを停止させようものなら想定していないVMまでvSphereHAが動作しホスト間移行してしまうということになります。
この挙動、公式ドキュメントにはどう記載されているのかなと思い確認したところ、vSphere6.0ドキュメントの可用性ガイドに以下の文言が追加されているのを見つけました(5.5の同ガイドには記載ありませんでした)。
ホストに障害が発生すると、vSphere HA は、パワーオンされていて再起動の優先順位設定が無効になっている仮想マシン、またはパワーオフされている、影響を受ける仮想マシンをアクティブなホストに登録しようとします。
vSphere 6.0 ドキュメントセンター - ホスト問題に対する対応の判断
vSphere 5.5 ドキュメントセンター - ホスト問題に対する対応の判断
ある詳細パラメータを設定することで、この挙動を5.5以前のものに戻すことができるそうですが、Webでは見つかりませんでした。詳しくはお近くのVMware社SEさんにご確認いただくのがよろしいかと。
HAを組んでいる以上移行しても問題ない構成になっているとは思いますが、この挙動変更を知っておかないと、気づかないうちにHAが動作して「?」ということになりかねないので、ご参考までに。