読者です 読者をやめる 読者になる 読者になる

Writing Virtual Life

仮想化(VMware)などについて、重箱の隅をつつくタイプのブログ。

仮想マシンメモリのオーバーヘッド

 仮想マシンをパワーオンする際、仮想マシンのメモリ及びvCPU数によってオーバヘッドメモリを消費します。最近はメモリを大量に積める関係であまり意識しないのですが、ちょっと気になった点をご紹介。
 
 vSphere5.5まではオーバーヘッドメモリの一覧表がドキュメントに記載されていました。6.0では一覧表がなくなってしまいましたが、6.5になってまたドキュメントに記載されるようになっていました。
 
vSphere 5.5の場合
 
vSphere 6.0の場合
 
vSphere 6.5の場合
 
 数字としては5.5 - 6.5で変わらないようです。ドキュメントに復帰した理由は不明ですが、ちゃんと記載されることでオーバーヘッドを意識できるようになったのは少し嬉しいですね。
 

仮想マシンの電源操作ボタンの調整

 Web Clientの電源操作を少し調整する点をご紹介。

 
 Web ClientのVMを選択すると使えるアイコン。

f:id:writinglife:20170226212920p:plain

 
 赤い四角ボタンのデフォルトは「シャットダウン」になっています。

f:id:writinglife:20170226212948p:plain

 
 対象仮想マシンを右クリックして「設定の編集」を選択、「仮想マシンのオプション」タブを押した上で「VMware tools」を見るとこんな感じにボタンごとの設定が可能です。

f:id:writinglife:20170226213026p:plain

 
 赤い四角ボタンの内訳は以下。

f:id:writinglife:20170226213038p:plain

 
 じゃあパワーオフに切り替えることがあるのかというと微妙ではありますが。
 これを紹介したのは、C# Clientの印象で赤い四角=パワーオフというイメージが個人的に定着してしまったので、ちゃんとゲストシャットダウンになりますよということを覚えておきたく。
 

vCSA6.0,6.5のsysprep格納場所

 Windows VMのカスタマイズを実施する場合、今ではdeploy.cabを事前設定するWindows OSは減りましたが、古いOS(XPや2003)では設定が必要です。
 基本は以下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まで該当するのか?」という懸念を持ったためです。
 結論として上記ディレクトリにありました。6.0,6.5も指定ディレクトリでsysprepファイルを配置できます。
 ドキュメント/KBに記載がなかったので記録として。

vSphere 6.5導入のVMware 拡張認証プラグイン(Web Client)

 vSphere6.0から6.5にかけて、Web Clientで使用するプラグインが変わっています。
 気になって調べてみました。わかった範囲でのご紹介。
 
・vSphere 6.0 名前:VMware クライアント統合プラグイン
・vSphere 6.5 名前:VMware 拡張認証プラグイン
 
VMware 拡張認証プラグインは、vSphere 6.0 リリース以前のクライアント統合プラグインの後継となる機能です。統合 Windows 認証と Windows ベースのスマート カード機能を提供します。
 
 それぞれの機能例が以下。
 6.0は多くの機能をプラグインにまとめていましたが、6.5だとすっきりしていますね。
 
○クライアント統合プラグイン(6.0)
 ・統合Windows認証
 ・OVF/OVAテンプレートのデプロイ(自端末のファイルから)
 ・仮想デバイスの接続
  ゲストOS に対する、インストール メディアのアップロード など
 ・Web Clientコンソールの一部の特殊操作
  画面最大化 など
 
○拡張認証プラグイン(6.5)
 ・統合 Windows 認証
 ・Windows ベースのスマート カード機能
 
 じゃあ外された機能は使えなくなったのかというと、実際にはプラグインなしで実現できるようになっているようです。例えばOVFテンプレートのデプロイ機能はプラグインなしでも使えます。
OVF および OVA テンプレートのデプロイ
以前のバージョンの vSphere では、OVF または OVA テンプレートのデプロイおよびエクスポートのためにクライアント統合プラグインをインストールする必要がありました。vSphere 6.5 では、OVF または OVA テンプレートのデプロイおよびエクスポートのためにクライアント統合プラグインをインストールする必要はありません。 

 

 ゲストOSに対してisoイメージを認識させる機能についても、ドキュメント記載の前提条件からプラグインの記述が外されています。
 
 クライアント端末にプラグインをインストールすることが少し悩みでしたが、6.5にて改善されたように思いますので、これはうれしい限りです。あとは、アクセスするユーザに対してプラグインインストールをさせる必要がないのなら、インストール要求をしないようにする機能がほしいところ。要確認です。

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のある挙動がこっそり変更されました。
それは、ホスト障害時のパワーオフVMに対するvSphereHA処理(VM再登録)です。
 
従来(~vSphere5.5)、vSphereHA構成のクラスタにおいて、ホスト障害が発生した際、
・パワーオンVM:別のホストで再起動します
・再起動優先順位が"無効"のVMやパワーオフ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