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

Writing Virtual Life

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

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

ESXi 6.0 インストール時のエラー

評価用としてNestedでESXi 6.0環境を構築した際に起きたエラーを記載します。
下記エラーはメモリ不足によるもの。最低4GBは振る必要があります。

f:id:writinglife:20150715211225j:plain

次にインストールチェック中、ErrorとWarningが1個ずつ表示されています。
前者はCPUコアが2個以上ないときに表示されるメッセージ。
後者はCPUに仮想化支援機能Intel VT-x / AMD RVIをx64CPUで有効にしていないと表示されます。

f:id:writinglife:20150715211314j:plain

その後問題なくインストールができたと思ったら、以下のようなパープルスクリーンが。
インストール後のリブート後、DCUI画面のサービス起動が終わりそうなタイミングで発生しました。

f:id:writinglife:20150715211355j:plain

Could not start pcpu 1; TSC sync timed out
ESXinVM cr0=0x8001003d cr2=0x0 cr3=0x100082000 cr4=0x12c
*PCPU0:32768/bootstrap
PCPU  0: SIS
Code start: 0x418014e00000 VMK uptime: 0:00:02:01.587

ESXinVMとあるので、VM上だということが既にばれているようです。

上記PSODは結局リブートしたら直ってしまったので原因については不明でしたが。

 

これからESXi 6.0の更新点について少しずつ遊んでみます。

VMware製品のうるう秒問題の影響(2015年版)続報

下記記事の続報があったので記載。

writinglife.hatenablog.com


KBに記載される、うるう秒の影響製品の項目が増えました。

VMware Product support of leap seconds (2115818)
http://kb.vmware.com/kb/2115818

以前からあったvCenter Server Appliance 5.0,5.1に加え、vCNSやNSXvCOps/vROpsなど注意すべき製品が増えています。

対策としてはNTP設定をSlewモードに切り替えればよく大きな作業にならないので、まずは対応製品とそのバージョンの確認、そして迅速に設定をしてもらうのがよいかと。
残り10日なのでお早めに。

-------------------------------------

2015/6/24 追記

今現在でも調査が進行中なのか、vCOps/vROpsが「影響なし製品」にカテゴリされるようになっていた。

影響しない製品のリストは以下KBに。

VMware KB: VMware products unaffected by the Leap Second change