Writing Virtual Life

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

ESXi 6.0U1b上でカスタマイズが失敗する現象

VMware

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の挙動について

VMware vSphere6.0
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が失敗する現象

VMware

先日公開された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 インストール時のエラー

VMware vSphere6.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年版)続報

VMware

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

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やNSX、vCOps/vROpsなど注意すべき製品が増えています。

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

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

2015/6/24 追記

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

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

VMware KB: VMware products unaffected by the Leap Second change

 

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

VMware

2015年7月1日に起きるうるう秒問題。
実際には2006年から3年おきに発生しており、その都度対応されている。
VMwareが現在うるう秒に対して述べているKBは以下。

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

2015/5/21時点の修正対象製品：
vCenter Server Appliance
・5.0
・5.0U1b     →5.0U2以降にアップグレード
・5.1.0a
・5.1.0b     →5.1U1a以降にアップグレード

ただしこのKBは情報が入り次第都度更新されるため、定期的に確認しておくとよい。
また、いきなりKBが消される可能性もあるのでVMware KBでの検索も必要。
(別の方がまとめられていた以下記事のKBが気づけば削除されてたり･･･いきなり消されると問題あったのかって不安になりますね)

vSphereへのうるう秒調整の影響
http://qiita.com/tsukamoto/items/5bbecd29ac40ac16e039

一応ご留意しておいたほうがいい情報でした。

仮想化ベンダにおけるVENOMの影響

VMware

5月13日に公開されたセキュリティ脆弱性「VENOM」。
古くから知られるエミュレータQEMUの持つ仮想フロッピーディスクコントローラ(FDC)のバグが原因となっており、影響としては仮想マシン上からホストOSに対してコードを実行させることができるという。
FDCが脆弱性の原因となっているが、VMおよびホストがFDを接続していない場合でも関連する。なぜならFDCコードはQEMUの中に残っており、VMを追加する際にデフォルトで追加されてしまうため、脆弱性の影響を受けてしまう。

なお、この脆弱性を使って悪意のコードを流すのはなかなか困難であるらしく、事例は挙がっていない。
影響のある製品については情報と同時に脆弱性対応パッチが公開されているため、パッチ適用さえ怠らなければよい。

VENOM Vulnerability
http://venom.crowdstrike.com/

影響のない製品

・VMware QEMUを使用していない
　http://kb.vmware.com/kb/2117469
・Bochs　QEMUを使用していない
・Hyper-V　Xenをコアにしているもののエミュレータとしては使用していないため

影響のありうる製品

本家HPに対象リストがあり、そのなかで個人的に気になるものをピックアップした。
URLと対象となるOSバージョン、そのパッケージを記載。

QEMU:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721f305d67bc0718795fedee2e824c

Xen Project:
http://xenbits.xen.org/xsa/advisory-133.html
Xen 4.2.x-4.5.x
qemu関連

Red Hat:
https://access.redhat.com/articles/1444903
RHEL 5,6,7
kvm,xen,qemu-kvm,qemu-kvm-rhev

Citrix:
http://support.citrix.com/article/CTX201078
XenServer 6.0-6.5

Ubuntu:
http://www.ubuntu.com/usn/usn-2608-1/
Ubuntu 12.04, 14.04, 14.10, 15.04
qemu, qemu-kvm

Debian:
https://security-tracker.debian.org/tracker/CVE-2015-3456

Suse:
https://www.suse.com/support/kb/doc.php?id=7016497
SLES 10-SP3,SP4 11-SP1,SP2,SP3 12

Amazon:
http://aws.amazon.com/security/security-bulletins/XSA_Security_Advisory_CVE_2015_3456/
対策済み。