仮想マシンメモリのオーバーヘッド
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が動作して「？」ということになりかねないので、ご参考までに。
"core"から始まる名前のVMのStorage vMotionが失敗する現象
先日公開されたKBで面白かったものをご紹介。
Storage migration of a virtual machine with a name beginning with core fails with the error: Relocate virtual machine coreXX Cannot complete the operation because the file or folder coreXX-XXXXX.hlog already exists (2130819)
http://kb.vmware.com/kb/2130819
ESXi 6.0上で動作するVM名の最初が「core」から始まる場合、Storage vMotionが失敗してしまいます(例：core01)。
原因はhostdが移行対象のファイルをcoreファイルとして認識してしまうためだそうです。コアダンプファイルのことでしょうか。
対策はVMをクローンして別の名前のVMを作成すること。要するにVMをただリネームしただけでは内部のファイル名までは修正されないので、確実に全ファイルで変更されるようクローンが必要なのでしょう。
使用するOSによってはこのネーミングパターンになる可能性もありますので、ご参考までに。
なお同様の現象がESXi 5.5で昨年発生していますが、こちらは既に対応パッチが出ています。
Moving a virtual machine file with a name beginning with the word core using powered off migration or with storage vMotion fails with the error: A general system error occurred: Error naming or renaming a VM file (2069480)
http://kb.vmware.com/kb/2069480
