VMware ESXi™ 5.5 Update 1 | 2014 年 3 月 11 日 | ビルド 1623387

最終更新日:2014 年 3 月 25 日

これらのリリース ノートへの追加や更新を確認してください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

新機能

この VMware ESXi リリースでは、次のように機能が拡張されています。

  • VMware Virtual SAN Virtual SAN 5.5 は、プール サーバ側の磁気ディスク (HDD) およびソリッド ステート ドライブ (SSD) に vSphere Hypervisor を拡張する、ハイパーバイザーが統合されたストレージ階層です。Virtual SAN では、サーバ側の HDD および SSD をクラスタ化することによって、仮想環境用に設計および最適化された分散型の共有データストアが作成されます。Virtual SAN は、vSphere とは別に販売されるスタンドアロン製品で、独自のライセンスキーが必要です。

  • 解決した問題 このリリースでは、多くのバグが修正されています。これらは、「 解決した問題」セクションに記載されています。

ESXi 5.5 の旧リリース

ESXi 5.5 の機能と既知の問題については、各リリースのリリース ノートに記載されています。ESXi 5.5 の以前のリリースのリリース ノートを確認するには、『 VMware vSphere 5.5 リリース ノート』を参照してください。

国際化

VMware vSphere 5.5 Update 1 は、次の言語で使用可能です。

  • 英語
  • フランス語
  • ドイツ語
  • 日本語
  • 韓国語
  • 簡体字中国語
  • 繁体字中国語

互換性およびインストール

ESXi、vCenter Server、および vSphere Web Client のバージョンの互換性

VMware 製品の相互運用性マトリックス』(英語版) では、ESXi、VMware vCenter Server、vSphere Web Client、および任意で使用可能な VMware 製品を含む VMware vSphere コンポーネントの現在のバージョンと旧バージョンとの互換性について、詳細に説明しています。ESXi または vCenter Server をインストールする前に、サポート対象の管理エージェントおよびバックアップ エージェントについて『 VMware 製品の相互運用性マトリックス』で確認してください。

vSphere Client と vSphere Web Client は vCenter Server ISO にパッケージされています。VMware vCenter™ インストール ウィザードを使用して、いずれかまたは両方のクライアントをインストールできます。

ESXi、vCenter Server と VDDK との互換性

Virtual Disk Development Kit (VDDK) 5.5.1 では、ESXi 5.5 Update 1 および vCenter Server 5.5 Update 1 のリリースをサポートするようになりました。
VDDK の詳細については、 http://www.vmware.com/support/developer/vddk/ を参照してください。

ESXi と Virtual SAN との互換性

Virtual SAN は、5.5 Update 1 より前の ESXi ホストで構成されたクラスタをサポートしていません。 Virtual SAN を有効にする前に、Virtual SAN クラスタのすべてのホストが ESXi 5.5 Update 1 にアップグレードされていることを確認してください。 vCenter Server も、5.5 Update 1 にアップグレードする必要があります。

Virtual SAN のテスト リリース
Virtual SAN ベータから Virtual SAN 5.5 への Virtual SAN クラスタのアップグレードは、サポートされていません。
Virtual SAN ベータを無効にし、ESXi 5.5 Update 1 ホスト用に Virtual SAN 5.5 を新規にインストールしてください。Virtual SAN のベータ版をテストしていた場合は、vSphere 5.5 Update 1 でのセットアップから引き続き保持するデータを再作成することをお勧めします。 詳細については、 vSphere 5.5 Update 1 にアップグレードするときの Virtual SAN ベータ クラスタの仮想マシンの保持 (KB 2074147) を参照してください。

ESXi のハードウェア互換性

vSphere 5.5 Update 1 と互換性のあるプロセッサ、ストレージ デバイス、SAN アレイ、および I/O デバイスのリストを表示するには、『 VMware 互換性ガイド』の ESXi 5.5 Update 1 の情報を使用してください。

ESXi のデバイス互換性

ESXi 5.5 Update 1 と互換性のあるデバイスを判断するには、『 VMware 互換性ガイド』の ESXi 5.5 Update 1 の情報を使用してください。

一部のデバイスへの互換性は廃止されており、ESXi 5.5 以降ではサポートされていません。アップグレード時に、互換性が廃止されたデバイスのドライバが ESXi 5.5.x ホストにインストールされ、ESXi 5.5.x で機能することもありますが、そのデバイスが ESXi 5.5.x で正式にサポートされているわけではありません。互換性が廃止され ESXi 5.5.x でサポートされていないデバイスのリストについては、VMware のナレッジ ベースの記事「 互換性が廃止されたデバイスと ESXi 5.5 アップグレード時の注意事項 」を参照してください。

ESXi のゲスト OS の互換性

vSphere 5.5 Update 1 と互換性のあるゲスト OS を判断するには、『 VMware 互換性ガイド』に記載されている ESXi 5.5 Update 1 の情報を参照してください。

 

ESXi の仮想マシンの互換性

ESX 3.x 以降(ハードウェア バージョン 4)と互換性がある仮想マシンは、ESXi 5.5 Update 1 でもサポートされています。 ESX 2.x 以降(ハードウェア バージョン 3)と互換性がある仮想マシンは、サポートされていません。このような仮想マシンを ESXi 5.5 Update 1 で使用するには、仮想マシンの互換性をアップグレードする必要があります。『 vSphere アップグレード』のドキュメントを参照してください。

vCenter Server 5.x のリンク モード環境への vSphere Client の接続

vCenter Server 5.5 は、vCenter Server 5.5 のその他のインスタンスを持つリンク モードにのみ存在することができます。

このリリースのインストールに関する注意事項

ESXi と vCenter Server のインストールおよび構成の手順については、『 vSphere のインストールとセットアップ』ドキュメントをお読みください。

インストールは簡単ですが、そのあとに重要な構成ステップがいくつかあります。次のドキュメントをお読みください。

サードパーティ製ソリューションの移行

ESX または ESXi ホストにインストールされたサードパーティ製ソリューションをホスト アップグレードの一部として直接移行することはできません。ESXi 5.1 と ESXi 5.5 間のアーキテクチャの違いにより、サードパーティ製コンポーネントが失われ、システムが不安定になる可能性があります。このような移行を行うためには、イメージ ビルダーを使用してカスタム ISO ファイルを作成します。サードパーティ関連のカスタマイズを使用したホストのアップグレードの詳細については、『 vSphere アップグレード』ドキュメントを参照してください。カスタム ISO を作成するためのイメージ ビルダーの使用方法の詳細については、『 vSphere Installation and Setup』ドキュメントを参照してください。

サポート対象外の CPU に対するアップグレードおよびインストールの禁止

vSphere 5.5.x では、LAHF および SAHF CPU 命令セットを備えた CPU のみがサポートされています。インストールまたはアップグレードの実行時、インストーラによってホスト CPU と vSphere 5.5.x との互換性が確認されます。 ホスト ハードウェアに互換性がない場合、非互換性に関するメッセージを示す紫色の画面が表示されます。vSphere 5.5 をインストールすることも、vSphere 5.5.x にアップグレードすることもできません。

このリリースのアップグレード

vCenter Server および ESX/ESXi ホストのアップグレードの詳細については、『 vSphere アップグレード』ドキュメントを参照してください。

ESXi 5.5 Update 1 へのアップグレードのサポート対象アップグレード パス

アップグレードに含まれている内容

サポート対象のアップグレード ツール

ESXi 5.5 Update 1 へのサポート対象のアップグレード方法

ESX/ESXi 4.0
以下を含む
ESX/ESXi 4.0 Update 1
ESX/ESXi 4.0 Update 2

ESX/ESXi 4.0 Update 3
ESX/ESXi 4.0 Update 4

ESX/ESXi 4.1:

ESX/ESXi 4.1 Update 1
ESX/ESXi 4.1 Update 2

ESX/ESXi 4.1 Update 3 が付属

 

ESXi 5.0:
以下を含む
ESXi 5.0 Update 1

ESXi 5.0 Update 2
ESXi 5.0 Update 3

ESXi 5.1
以下を含む
ESXi 5.1 Update 1
ESXi 5.1 Update 2

ESXi 5.5

VMware-VMvisor-Installer-5.5.0.update01-1623387.x86_64.iso

 

  • VMware vCenter Update Manager
  • CD アップグレード
  • スクリプトを使用したアップグレード

update-from-esxi5.5-5.5_update01.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere CLI

なし

なし

可*

可*

VMware ポータル (オンライン) からダウンロードしたパッチ定義の使用 パッチ ベースライン付きの VMware vCenter Update Manager

いいえ

なし

なし

なし

はい


*注: update-from-esxi5.5-5.5_update01.zipを使用した ESXi 5.0.x または ESXi 5.1.x から ESXi 5.5 Update 1 へのアップグレードは、ESXCLI のみでサポートされています。アップグレードを実行するには、 esxcli software profile update --depot=<depot_location> --profile=<profile_name>コマンドを実行する必要があります。詳細については、『 vSphere アップグレード ガイド』のトピック「 ESXi 5.5.x アップグレード オプション」を参照してください。

VMware vSphere 5.5 Update 1 用オープン ソース コンポーネント

vSphere 5.5 Update 1 で配布されるオープン ソース ソフトウェア コンポーネントに適用される著作権情報およびライセンスは、 http://www.vmware.com/download/vsphere/open_source.html の [オープン ソース] タブで参照できます。また、入手可能な vSphere の最新リリースについて、ソース コードやソース コードへの改変を公開することが必要な GPL、LGPL、またはその他の類似のライセンスのソース ファイルをダウンロードすることもできます。

製品サポートに関する注意事項

  • vSphere Web Client:Linux プラットフォームが Adobe Flash でサポートされなくなったため、Linux OS では vSphere Web Client はサポートされていません。Linux desktop OS に Adobe Flash へのサポートを追加するサード パーティ製のブラウザが引き続き機能する場合もあります。

    VMware vCenter Server Appliance:vSphere 5.5 では、DISA Security Technical Information Guidelines (STIG) に準拠することで、VMware vCenter Server Appliance はガバナンスの高いコンプライアンス基準を満たします。VMware vCenter Server Appliance をデプロイする前に、新しいセキュリティの導入基準の確認と、正しい操作の確保のため、『 VMware Hardened Virtual Appliance 操作ガイド』を参照してください。

  • vCenter Server データベース: vSphere 5.5 は、IBM DB2 の vCenter Server データベースとしてのサポートを廃止しました。

  • VMware Tools:vSphere 5.5 以降、vSphere での VMware Tools のインストールと構成の方法についてのすべての情報は、他の vSphere ドキュメントに統合されています。vSphere での VMware Tools の利用についての詳細は、vSphere ドキュメントを参照してください。『 VMware Tools のインストールと構成』は、vSphere 5.5 以降には適用されません。

  • VMware Tools:vSphere 5.5 以降の VMware Tools は ThinPrint 機能を提供しません。

  • vSphere Data Protection: vSphere Web Client で処理方式が変更になったため、vSphere Data Protection 5.1 には vSphere 5.5 との互換性がありません。 vSphere 5.5 にアップグレードする vSphere Data Protection 5.1 ユーザーは、vSphere Data Protection を引き続き利用する場合、vSphere Data Protection もアップグレードする必要があります。

このリリースに含まれるパッチ

このリリースには、この製品のリリース日以前にリリースされた ESXi のすべてのパッチが含まれています。各パッチの詳細については、VMware の 『 パッチのダウンロード』 ページ (英語版) を参照してください。

パッチ リリース ESXi550-Update01 には、次の各パッチが含まれています。

ESXi550-201403201-UG: ESXi 5.5 esx-base vib のアップデート
ESXi550-201403202-UG: ESXi 5.5 tools-light vib のアップデート
ESXi550-201403203-UG: ESXi 5.5 rste vib のアップデート
ESXi550-201403204-UG: ESXi 5.5 net-e1000e vib のアップデート
ESXi550-201403205-UG: ESXi 5.5 scsi-mpt2sas vib のアップデート
ESXi550-201403206-UG: ESXi 5.5 lsi-msgpt3 vib のアップデート
ESXi550-201403207-UG: ESXi 5.5 mtip32xx-native vib のアップデート
ESXi550-201403208-UG: ESXi 5.5 sata-ahci vib のアップデート
ESXi550-201403209-UG: ESXi 5.5 scsi-megaraid-sas vib のアップデート
ESXi550-201403210-UG: ESXi 5.5 net-igb vib のアップデート
ESXi550-201403211-UG: ESXi 5.5 net-tg3 vib のアップデート

パッチ リリース ESXi550-Update01 Security-only には、次の各パッチが含まれています。

ESXi550-201403101-SG: ESXi 5.5 esx-base vib のアップデート
ESXi550-201403102-SG: ESXi 5.5 tools-light vib のアップデート

パッチ リリース ESXi550-Update01 には、次のイメージ プロファイルが含まれています。

ESXi-5.5.0-20140302001-standard
ESXi-5.5.0-20140302001-no-tools

パッチ リリース ESXi550-Update01 Security-only には、次のイメージ プロファイルが含まれています。

ESXi-5.5.0-20140301001s-standard
ESXi-5.5.0-20140301001s-no-tools

パッチおよびアップデートの分類に関する情報については、 KB 2014447 を参照してください。

解決した問題

このセクションでは、本リリースで解決された問題について説明します。

CIM および API の問題

  • IPMI センサー データを取得できない
    exscli hardware ipmi sdr listコマンドを実行する場合、リソースの使い切りに関する次のようなエラー メッセージが表示されることがあります。
    No records or incompatible version or read failed

    今回のリリースで、この問題は修正されました。
  • vmkapimod の vmklinux_9:ipmi_thread で 1 時間の CPU 使用量が 100% と表示される
    ESXi ホストで Intelligent Platform Management Interface (IPMI)ツールを使用して現場で交換可能なユニット(FRU)のインベントリ データを読み取る際に、vmkapimod の vmklinux_9:ipmi_thread で CPU 使用量が 100% と表示されます。これは、IPMI ツールで大きいインベントリ データを読み取るために Read FRU Data コマンドが複数回使用されるためです。

    今回のリリースで、この問題は修正されました。
  • CIM ポート 5989 で強度の弱い暗号を無効化できない
    クレジット カード業界(PCI)のコンプライアンスの暗号ブロック連鎖(CBC)アルゴリズムを無効化するには、場合によっては CIM ポート 5989 で強度の弱い暗号を無効化する必要があります。 これは許可されていません。次のコマンドを実行することで、強度の弱い暗号が無効になるように sfcb.cfgの構成を更新できます。

    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart

    今回のリリースで、この問題は修正されました。

  • EMC PowerPath を使用した CIM_System のクエリ操作に失敗する
    PowerPath が /VMware/esxv2/で CIM_System をクエリする場合、操作に失敗し CIM サーバからエラーが報告されます。次のようなエラーが表示されます。

    ThreadPool --- 要求をキューに追加できませんでした。すでにキューに入っている要求が多すぎます: vmwaLINUX
    ThreadPool --- 要求をキューに追加できませんでした。すでにキューに入っている要求が多すぎます: vmware_base, active 5, queued 11 .\TreeViewHostDiscovery.cpp 611

    今回のリリースで、この問題は修正されました。

  • センサー データの更新中にイーサネット プロバイダからコア ダンプが作成される
    IBM x3650M3 サーバ上の [ハードウェア ステータス] タブでセンサー データの更新中に、イーサネット プロバイダから Small Footprint CIM Broker (SFCB) コア ダンプが作成されます。複数回試行した後でも、 ハードウェア ステータス タブにデータが表示されません。

    今回のリリースで、この問題は修正されました。

その他の問題

  • ホストの再起動時に SNMP トラップ ファイル用の RAM ディスクが作成されない
    ホストの再起動時またはダイレクト コンソール ユーザー インターフェイスから ESXi ホストで管理エージェントを再起動するときに、SNMP トラップ ファイル用の RAM ディスクが作成されません。ESXi ホストの /var/spool/snmp(ディレクトリ、ファイル、リンクなど) でオブジェクトが作成されてから SNMP サービスを開始するときに、SNMP トラップ ファイル用の RAM ディスクが作成されません。

    今回のリリースで、この問題は修正されました。

  • 仮想マシンをパワーオフすると、エラー メッセージが表示されて VMX プロセスが失敗することがある
    仮想マシンをパワーオフしようとすると、VMX プロセスが失敗することがあります。
    次のようなエラー メッセージが vmware.logファイルに書き込まれることがあります。

    Unexpected signal: 11

    今回のリリースで、この問題は修正されました。
  • 3D 対応仮想マシンで JavaFX アプリケーション アイテムが適切に表示されない
    仮想マシンの設定で 3D が有効になっている場合、JavaFX アプリケーションのユーザー インターフェイス コンポーネントが適切に表示されません。

    今回のリリースで、この問題は修正されました。

  • lsilogic 仮想アダプタが使用可能なすべてのターゲットの I/O の完了を待機しているときに、その仮想アダプタで構成された複数の仮想ディスクが応答しないことがある
    lsilogic 仮想アダプタで SCSI ターゲット リセット コマンドを実行すると、仮想アダプタは使用可能なすべてのターゲットの I/O の完了を待機します。その結果、lsilogic 仮想アダプタで複数の仮想ディスクが構成された仮想マシンが、応答しなくなることがあります。

    今回のリリースで、この問題は修正されました。

ネットワークの問題

  • RSS の頻繁な変更により、Windows Server 2008 R2 で VMXNET3 アダプタがリセットされる
    マルチ vCPU の Windows 仮想マシンで Receive Side Scaling が有効になっている場合、MAC アドレスを繰り返す NetPort メッセージが表示され、そのポートが無効化されてから再有効化されたことが示されます。 vmkernelログに次のようなメッセージが表示されます。

    2013-07-08T06:11:58.158Z cpu4:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:11:58.177Z cpu4:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24
    2013-07-08T06:12:46.191Z cpu1:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:12:46.211Z cpu7:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24

    これらの MAC アドレスを使用する仮想マシンの vmware.logファイルには、対応する次のようなイベントが含まれます。

    2013-07-08T06:18:20.175Z| vcpu-1| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:20.199Z| vcpu-1| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212
    2013-07-08T06:18:36.165Z| vcpu-6| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:36.187Z| vcpu-6| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212

    今回のリリースで、この問題は修正されました。VMXNET3 ネットワーク ドライバは今回のリリースで更新されています。

  • E1000 または E1000e 仮想アダプタを使用する仮想マシンをホストする ESXi 5.x ホストに障害が発生して紫色の診断画面が表示される
    rxRing バッファがいっぱいになり、最大 Rx リングが 2 より多く設定されている場合、ESXi ホストで E1000PollRxRing と E1000DevRx のエラーが発生し、紫色の診断画面が表示されます。 2 番目のリングで処理される、次に受信する Rx パケットは NULL であるため、処理エラーが発生します。
    紫色の診断画面には、次のようなエントリが記載されます。

    @BlueScreen: #PF Exception 14 in world 63406:vmast.63405 IP 0x41801cd9c266 addr 0x0
    PTEs:0x8442d5027;0x383f35027;0x0;
    Code start: 0x41801cc00000 VMK uptime: 1:08:27:56.829
    0x41229eb9b590:[0x41801cd9c266]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x410015264580
    0x41229eb9b600:[0x41801cd9fc73]E1000DevRx@vmkernel#nover+0x18a stack: 0x41229eb9b630
    0x41229eb9b6a0:[0x41801cd3ced0]IOChain_Resume@vmkernel#nover+0x247 stack: 0x41229eb9b6e0
    0x41229eb9b6f0:[0x41801cd2c0e4]PortOutput@vmkernel#nover+0xe3 stack: 0x410012375940
    0x41229eb9b750:[0x41801d1e476f]EtherswitchForwardLeafPortsQuick@<None>#<None>+0xd6 stack: 0x31200f9
    0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@<None>#<None>+0x13bb stack: 0x412200000015
    0x41229eb9b9c0:[0x41801cd2b2c7]Port_InputResume@vmkernel#nover+0x146 stack: 0x412445c34cc0
    0x41229eb9ba10:[0x41801cd2ca42]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x41001203aa01
    0x41229eb9ba70:[0x41801cd99a05]E1000DevAsyncTx@vmkernel#nover+0x190 stack: 0x41229eb9bab0
    0x41229eb9bae0:[0x41801cd51813]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x2
    0x41229eb9bc60:[0x41801cd0b21b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41229eb9bd10
    0x41229eb9bca0:[0x41801cd0b895]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041229eb9bd20
    0x41229eb9bd20:[0x41801cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x41229eb9be20
    0x41229eb9be20:[0x41801cdbc9bc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x29eb9bfa0
    0x41229eb9bf10:[0x41801cdc4c1f]CpuSchedDispatch@vmkernel#nover+0xabe stack: 0x0
    0x41229eb9bf80:[0x41801cdc5f4f]CpuSchedWait@vmkernel#nover+0x242 stack: 0x412200000000
    0x41229eb9bfa0:[0x41801cdc659e]CpuSched_Wait@vmkernel#nover+0x1d stack: 0x41229eb9bff0
    0x41229eb9bff0:[0x41801ccb1a3a]VmAssistantProcessTask@vmkernel#nover+0x445 stack: 0x0
    0x41229eb9bff8:[0x0]<unknown> stack: 0x0

    今回のリリースで、この問題は修正されました。

  • 複数の VMkernel ポートで管理トラフィックが有効になっている場合、リセット時に、DCUI に表示される IP アドレスが変わる
    複数の VMkernel ポートで管理トラフィックが有効になっている管理ネットワークをリセットすると必ず、ダイレクト コンソール ユーザー インターフェイス (DCUI) に表示される IP アドレスが変わります。

    今回のリリースで、この問題は修正されました。
  • ESXi ホストが紫色の診断画面になり、例外 14 エラーが表示される
    DvFilter モジュールのある ESXi ホストで紫色の診断画面が表示され、次のようなバックトレースが表示されることがあります。

    2013-07-18T06:41:39.699Z cpu12:10669)0x412266b5bbe8:[0x41800d50b532]DVFilterDispatchMessage@com.vmware.vmkapi#v2_1_0_0+0x92d stack: 0x10
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bc68:[0x41800d505521]DVFilterCommBHDispatch@com.vmware.vmkapi#v2_1_0_0+0x394 stack: 0x100
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bce8:[0x41800cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x412266b5bde8, 0x412266b5bd88,

    今回のリリースで、この問題は修正されました。

  • ESXi TCP/IP スタックの競合状態により、ESXi ホストで障害が発生し、紫色の画面になることがある
    ESXi ホストで障害が発生し、紫色の画面になり、次のようなエラー メッセージが表示されることがあります。

    2013-02-22T15:33:14.296Z cpu8:4104)@BlueScreen: #PF Exception 14 in world 4104:idle8 IP 0x4180083e796b addr 0x1
    2013-02-22T15:33:14.296Z cpu8:4104)Code start: 0x418007c00000 VMK uptime: 58:11:48:48.394
    2013-02-22T15:33:14.298Z cpu8:4104)0x412200207778:[0x4180083e796b]ether_output@<None>#<None>+0x4e stack: 0x41000d44f360
    2013-02-22T15:33:14.299Z cpu8:4104)0x4122002078b8:[0x4180083f759d]arpintr@<None>#<None>+0xa9c stack: 0x4100241a4e00

    この問題は、ESXi TCP/IP スタックの競合状態が原因で発生します。

    今回のリリースで、この問題は修正されました。

  • Intel e1000e ネットワーク インターフェイス ドライバで受信(RX)トラフィックに対する応答が停止することがある
    Intel e1000e ネットワーク インターフェイス ドライバで受信(RX)トラフィックに対する応答が停止することがあります。

    今回のリリースで、この問題は修正されました。

  • ネットワーク健全性チェック機能が有効化されている場合、ESXi ホストで障害が発生し、紫色の画面になることがある
    ネットワーク健全性チェック機能が有効化されており、多くの健全性チェック パケットが処理される場合、L2Echo 機能で高ネットワーク トラフィックを処理できず、ESXi ホストで障害が発生し、紫色の診断画面に次のようなメッセージが表示されることがあります。

    2013-06-27T10:19:16.074Z cpu4:8196)@BlueScreen: PCPU 1: no heartbeat (2/2 IPIs received)
    2013-06-27T10:19:16.074Z cpu4:8196)Code start: 0x418024600000 VMK uptime: 44:20:54:02.516
    2013-06-27T10:19:16.075Z cpu4:8196)Saved backtrace from: pcpu 1 Heartbeat NMI
    2013-06-27T10:19:16.076Z cpu4:8196)0x41220781b480:[0x41802468ded2]SP_WaitLockIRQ@vmkernel#nover+0x199 stack: 0x3b
    2013-06-27T10:19:16.077Z cpu4:8196)0x41220781b4a0:[0x4180247f0253]Sched_TreeLockMemAdmit@vmkernel#nover+0x5e stack: 0x20
    2013-06-27T10:19:16.079Z cpu4:8196)0x41220781b4c0:[0x4180247d0100]MemSched_ConsumeManagedKernelMemory@vmkernel#nover+0x1b stack: 0x0
    2013-06-27T10:19:16.080Z cpu4:8196)0x41220781b500:[0x418024806ac5]SchedKmem_Alloc@vmkernel#nover+0x40 stack: 0x41220781b690...
    2013-06-27T10:19:16.102Z cpu4:8196)0x41220781bbb0:[0x4180247a0b13]vmk_PortOutput@vmkernel#nover+0x4a stack: 0x100
    2013-06-27T10:19:16.104Z cpu4:8196)0x41220781bc20:[0x418024c65fb2]L2EchoSendPkt@com.vmware.net.healthchk#1.0.0.0+0x85 stack: 0x4100000
    2013-06-27T10:19:16.105Z cpu4:8196)0x41220781bcf0:[0x418024c6648e]L2EchoSendPort@com.vmware.net.healthchk#1.0.0.0+0x4b1 stack: 0x0
    2013-06-27T10:19:16.107Z cpu4:8196)0x41220781bfa0:[0x418024c685d9]L2EchoRxWorldFn@com.vmware.net.healthchk#1.0.0.0+0x7f8 stack: 0x4122
    2013-06-27T10:19:16.108Z cpu4:8196)0x41220781bff0:[0x4180246b6c8f]vmkWorldFunc@vmkernel#nover+0x52 stack: 0x0


    今回のリリースで、この問題は修正されました。
  • データストアの .dvsData ディレクトリから未使用の vSphere Distributed Switch (VDS) ポートがクリアされない
    vNIC が VDS に接続されている仮想マシンでの vMotion の実行中、vMotion ソース ホストのポート ファイルが時間をおいても .dvsData ディレクトリからクリアされません。

    今回のリリースで、この問題は修正されました。

  • vCenter パフォーマンス チャートと VMkernel の net.throughput.usage の戻り値が矛盾している
    net.throughput.usage に関連する値は、vCenter パフォーマンス チャートではキロバイト単位ですが、VMkernel では同じ値がバイト単位で返されます。結果として、vCenter パフォーマンス チャートの値の表示が不正確になります。

    今回のリリースで、この問題は修正されました。

  • tg3 NIC の TCP セグメンテーション オフロード (TSO) 機能が原因で、ESXi ホストが失敗することがある
    tg3 ドライバで TSO 機能が有効になっていると、tg3 NIC により、そこを通過するデータが破損されることがあります。

    今回のリリースで、この問題は修正されました。TSO 機能は、tg3 NIC では無効になっています。
  • 同じ ESXi ホストおよび同じ vSwitch での 2 つの仮想マシン間のネットワーク パケット ドロップが esxtop で誤って報告される
    2 つの仮想マシンがホスト上の同じ vSwitch に e1000 ドライバを使用して構成されている場合、2 つの仮想マシン間のネットワーク トラフィックについて、esxtop で重大なパケット ドロップが報告されることがあります。これは、報告時に分割パケットが考慮されないために、ゲストから TSO を有効にするときに発生します。

    今回のリリースで、この問題は修正されました。VMXNET3 ネットワーク ドライバは今回のリリースで更新されています。

セキュリティの問題

  • libxslt の更新
    ESXi userworld libxslt パッケージが更新されています。
  • NTP デーモンの更新
    NTPデーモンが更新され、セキュリティの問題が解決しました。
    Common Vulnerabilities and Exposures プロジェクト (cve.mitre.org) は、この問題を CVE-2013-5211 として公表しています。
    注: この問題の回避策については、 KB 2070193 を参照してください。
  • glibc パッケージの更新
    ESXi glibc-2.5 パッケージが更新され、セキュリティの問題が解決しました。
    Common Vulnerabilities and Exposures プロジェクト (cve.mitre.org) は、この問題を CVE-2013-4332 として公表しています。

サーバ構成の問題

  • esxtop コマンドライン ツールによって報告される CPU 使用率の値に矛盾がある
    ハイパースレッドが有効になったマシンでは、CPU の vSphere Client コア使用率の値が、esxtop を使用して検出したコア使用率の値と比較して 2 倍になります。

    今回のリリースで、この問題は解決しました。
  • esxcli network nic coalesce get コマンドで誤った単位が返される
    esxcli network nic coalesce getコマンドを入力した場合、返される出力の単位がミリ秒になります。正しい単位はマイクロ秒です。

    今回のリリースで、この問題は修正されました。
  • VMFS データストアまたは一部のファイルにアクセスできない
    vCenter Server の データストア タブに仮想マシン ファイル システム データストアが表示されないか、 イベント タブに次のようなイベントが表示されることがあります。

    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX または 最低 1 つの破損したオンディスク ロックがボリューム {1} ({2}) で検出されました。ボリュームのその他の領域も破損している可能性があります。

    次のメッセージが vmkernel.logファイルに記録されます。

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") might be damaged on the disk.Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$

    また、 vmkernel.logファイル に次のメッセージが記録されることがあります。

    2013-07-24T05:00:43.171Z cpu13:11547)WARNING: Vol3: ValidateFS:2267: XXXXXX/51c27b20-4974c2d8-edad-b8ac6f8710c7: Non-zero generation of VMFS3 volume: 1

    今回のリリースで、この問題は修正されました。

  • HP サーバに EMC PowerPath をインストールした後、ESXi ローカル ディスクが使用できない
    EMC PowerPath をインストールした後、ローカル データストアがどのマルチパス プラグイン (MPP) からも要求されません。要求ルールが実行されているときは、パスが要求ルールと一致する場合、そのパスが MPP に渡されます。vSphere 5.1 では、MPP によってエラーが返されると、そのパスが他の要求ルールと照合され、一致するものが存在する場合、それらの要求ルール内の MPP にそのパスが渡されます。パスがどの MPP からも要求されないと、キャッチオール要求ルールに基づいてそのパスが NMP に渡されます。

    今回のリリースで、この問題は修正されました。

  • ESXi ホストが紫色の診断画面になり、エラーが表示される
    ユーザーワールド プログラム ps からの VMkernel System Information (VSI) 呼び出しで、カーネルに送信されたインスタンス リストが破損していると、VMkernel でエラーが発生します。この問題は、 numParamsが高すぎる場合にカーネルがそのインデックスの配列にアクセスしようとすると発生します。次に、バックトレースが表示された紫色の診断画面の例を示します。

    2013-09-06T00:35:49.995Z cpu11:148536)@BlueScreen: #PF Exception 14 in world 148536:ps IP 0x418004b31a34 addr 0x410019463308

    PTEs:0x4064ffe023;0x2080001023;0x100065023;0x0;

    2013-09-06T00:35:49.996Z cpu11:148536)Code start: 0x418004800000 VMK uptime: 2:11:35:53.448
    2013-09-06T00:35:49.996Z cpu11:148536)0x412250e1bd80:[0x418004b31a34]VSIVerifyInstanceArgs@vmkernel#nover+0xf3 stack: 0x410009979570
    2013-09-06T00:35:49.997Z cpu11:148536)0x412250e1bdd0:[0x418004b31bbb]VSI_CheckValidLeaf@vmkernel#nover+0xca stack: 0x8c8
    2013-09-06T00:35:49.998Z cpu11:148536)0x412250e1be40:[0x418004b32222]VSI_GetInfo@vmkernel#nover+0xb1 stack: 0x4100194612c0
    2013-09-06T00:35:49.999Z cpu11:148536)0x412250e1beb0:[0x418004ca7f31]UWVMKSyscallUnpackVSI_Get@<None>#<None>+0x244 stack: 0x412250e27000
    2013-09-06T00:35:50.000Z cpu11:148536)0x412250e1bef0:[0x418004c79348]User_UWVMKSyscallHandler@<None>#<None>+0xa3 stack: 0x0
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf10:[0x4180048a8672]User_UWVMKSyscallHandler@vmkernel#nover+0x19 stack: 0xffea48d8
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf20:[0x418004910064]gate_entry@vmkernel#nover+0x63 stack: 0x0
    2013-09-06T00:35:50.004Z cpu11:148536)base fs=0x0 gs=0x418042c00000 Kgs=0x0

    今回のリリースで、この問題は修正されました。

  • ESXi ホストが応答しなくなり、vCenter Server から切断される
    ESXi ホストが応答しなくなり、vCenter Server から切断されます。また、Active Directory 環境内のオフライン ドメインに起因する lsassd でのメモリ リークのために、ホストへの DCUI ログインや SSH ログインができません。

    今回のリリースで、この問題は修正されました。

  • 仮想マシンが物理ホストのシリアル番号を表示できるようにしてほしい
    仮想マシンが物理 ESXi ホストのシリアル番号を反映できません。

    今回のリリースで、この問題は修正されました。

  • ESXi ホストで resourceCpuAllocMax システム カウンタが誤った値で表示される
    ホスト システムに対して resourceCpuAllocMax および resourceMemAllocMax システム カウンタの値を取得しようとすると、ESX ホストが不正な値を返します。この問題は、vSphere Client が vCenter Server に接続されている場合に発生することが確認されています。

    今回のリリースで、この問題は修正されました。

  • ファイバ チャネル ホスト バス アダプタ (HBA) の速度が間違って表示される
    管理対象オブジェクト ブラウザ (MOB) 上で、一部の ESXi ホストに関してファイバ チャネル ホスト バス アダプタ (HBA) の速度が常に 0 と間違って表示されます。

    今回のリリースで、この問題は修正されました。

  • 複数の ESXi ホストが vCenter Server で応答しなくなる
    大量のパラレル HTTP GET /folderURL リクエストが hostd に送信されると、hostd サービスが失敗します。そのため、ホストが VCenter Server に戻されなくなります。次のようなエラー メッセージが表示されることがあります。

    指定ホストにアクセスできません。ホストが存在しないか、サーバ ソフトウェアが応答していない、またはネットワークに問題があるかのいずれかが考えられます。
     

    今回のリリースで、この問題は修正されました。

  • ハードウェア バージョンが 10 より前の仮想マシンは NVS ネットワークに接続できない
    ハードウェア バージョンが 10 より前の仮想マシンは、NVS (NSX Virtual Switch) ネットワークに接続できません。ただし、ハードウェア バージョンが 4 以上の仮想マシンは、NVS ネットワークに接続できます。

    今回のリリースで、この問題は修正されました。

  • hostd に失敗し、hostd-worker ダンプが生成される
    vDS 上で vmknic に接続されているソフトウェア iSCSI ディスクを取り外すと、ESXi 5.5 ホストによって hostd-worker ダンプが生成されることがあります。ホストの最新の情報を取得しようとすると、この問題が発生します。

    今回のリリースで、この問題は修正されました。

  • 共有非持続性ディスクが別のパワーオン状態の仮想マシンに接続(または共有)されている場合、ホット リムーブにより長い時間がかかる
    共有非持続性読み取り専用ディスクを仮想マシンに追加すると、仮想マシンでディスクの削除操作に要する時間が長くなることがあります。

    今回のリリースで、この問題は修正されました。
  • 仮想マシンのプロビジョニングとカスタマイズを行うと、ネットワークの接続が切断されることがある
    Ephemeral ポートのある vDS 上でテンプレートから仮想マシンをプロビジョニングし、カスタマイズすると、その仮想マシンがネットワークから切断されることがあります。

    ログ ファイルに次のようなエラー メッセージが記録される場合があります。

    2013-08-05T06:33:33.990Z| vcpu-1| VMXNET3 user: Ethernet1 Driver Info: version = 16847360 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 0
    2013-08-05T06:33:35.679Z| vmx| Msg_Post: Error
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetPortID] Unable to get dvs.portId for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetNetworkName] Unable to get networkName or devName for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.device.badconnect] Failed to connect virtual device Ethernet0.
    2013-08-05T06:33:35.679Z| vmx|

    今回のリリースで、この問題は修正されました。

  • SNMP エージェントが停止すると ESXi ホストでトラップ ファイルが作成される
    SNMP エージェントが停止すると、簡易ネットワーク管理プロトコル (SNMP) によって ESXi ホストの /var/spool/snmpフォルダにトラップ ファイル ( .trp) が作成されます。SNMP エージェントの停止時までにディレクトリ /var/spool/snmpが正常に削除されないと、hostd によって /var/spool/snmpにトラップ ファイル (.trp) が書き込まれます。そのため、ホストが inode を使い切り、vCenter Server から切断されたようにみえます。その結果、そのホストですべてのタスクを実行できなくなることがあります。

    今回のリリースで、この問題は修正されました。

  • Preboot Execution Environment (PXE) 起動ホストで、パワーオン状態の仮想マシンの GuestNicInfo が見つからない
    VMware Tools がインストール済みで実行されている場合、GuestNicInfo および GuestStackInfo はパワーオン状態の仮想マシンで使用できません。

    今回のリリースで、この問題は修正されました。

  • ESXCLI コマンドを実行するか、または SNMP エージェントに依存する監視ツールを使用すると、ESXi ホストへの接続が失われることがある
    ESXCLI コマンドを実行するか、または SNMP エージェントのデータに依存する監視ツールを ESXi で使用すると、hostd サービスで障害が発生し、ESXi ホストへの接続が失われることがあります。

    今回のリリースで、この問題は修正されました。

  • ゲスト OS で、ESXi ホストの bandwidthCap オプションと throughputCap オプションが機能しないことがある
    ESXi ホストで bandwidthCap と throughputCap が同時に設定されていると、仮想マシンでそれらの I/O 調整オプションが機能しないことがあります。これは、SCSI スケジューラで調整オプションを設定する際に論理比較を誤ったために発生します。

    今回のリリースで、この問題は修正されました。

  • SNMP が有効で、サーバにサード パーティの CIM プロバイダがインストールされているホストで SNMP トラップが受信されない
    SNMP が有効で、サード パーティの CIM プロバイダがインストールされている ESXi ホストで監視対象のハードウェア ステータスが変わると、SNMP トラップが受信されないことがあります。 syslogファイルには次のようなメッセージが記録されます。

    2013-07-11T05:24:39Z snmpd: to_sr_type: unable to convert varbind type '71'
    2013-07-11T05:24:39Z snmpd: convert_value: unknown SR type value
    02013-07-11T05:24:39Z snmpd: parse_varbind: invalid varbind with type 0 and value: '2'
    2013-07-11T05:24:39Z snmpd: forward_notifications: parse file '/var/spool/snmp/1373520279_6_1_3582.trp' failed, ignored

    今回のリリースで、この問題は修正されました。

  • 仮想マシンで CPUID マスクをリセットしようとすると、hostd に失敗する
    SetRegisterInfoの値が NULL または空の文字列である場合、仮想マシンで CPUID マスクをリセットしようとすると、hostd がクラッシュします。

    今回のリリースで、この問題は修正されました。

  • ESXi のインストールが「UnboundLocalError」エラーで失敗する
    ESXi のインストールが「UnboundLocalError: local variable 'isLocalOnlyAdapter' referenced before assignment」というエラーで失敗します。

    今回のリリースで、この問題は修正されました。

  • ホスト プロファイルがネットワーク接続ストレージ (NAS) プロファイルを断続的に適用できない
    アプリケーション障害が発生している間、ホストは NasStorageProfileを適用できず、メンテナンス モードから抜けることができません。

    今回のリリースで、この問題は修正されました。

  • 複雑なホスト プロファイルを適用しようとするとタイムアウトになる場合がある
    複雑なホスト プロファイル(ポートグループとデータストアが大量に含まれるホスト プロファイルなど)を適用すると、その操作がタイムアウトになり、次のようなエラー メッセージが表示される場合があります。

    2013-04-09T15:27:38.562Z [4048CB90 info 'Default' opID=12DA4C3C-0000057F-ee] [VpxLRO] -- ERROR task-302 -- -- vim.profile.host.profileEngine.HostProfileManager.applyHostConfig:

    vmodl.fault.SystemError:
    --> Result:
    --> (vmodl.fault.SystemError) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> reason = "",
    --> msg = "A general system error occurred: ",
    --> }

    hostd のデフォルト タイムアウトは 10 分です。applyHostConfig は累進的に行われるタスクではないため、hostd サービスは hostd タイムアウト中に、失敗したタスクと実行に時間がかかっているタスクを識別することはできません。この結果、hostd サービスは applyHostConfig が失敗したと報告します。

    今回のリリースで、HostProfileManager 管理対象オブジェクトの一部分として 30 分のタイムアウトを設定することでこの問題は修正されました。ただし、大きなホスト プロファイルの適用を試みて、タスクが 30 分のタイムアウト制限を超える可能性がある場合には、依然としてこの問題が発生する可能性があります。この問題を回避するには、ホスト プロファイルをもう一度適用します。

    注: タイムアウトの実際のトリガーは、ホスト プロファイルの複雑さによって異なります。
  • 仮想マシン モニタが無効なマシン ページ数を返すと、VMKernel で障害が発生する
    VMX がページを読み取るために VPN 値を渡すと、VMKernel はその VPN 値の有効なマシン ページ数を見つけるのに失敗し、結果としてホストで障害が発生して紫色の診断画面が表示されます。

    今回のリリースで、この問題は修正されました。

ストレージの問題

  • esxtop パフォーマンス データの出力がゼロと表示されることがある
    esxtop パフォーマンス データの出力が CSV 形式のファイルにリダイレクトされるときに、バッチ モードで収集される esxtop.csvの値がゼロになることがあります。 esxtop.csvファイルには、次のような I/O 値が表示される可能性があります。

    "09/04/2013 22:00:00","1251.43","4.89","7.12","1839.62","7.19","4.99","1273.05","4.97","7.08""09/04/2013
    22:00:10","1283.92","5.02","7.06","1875.14","7.32","4.89","1290.37","5.04","7.07""09/04/2013
    22:00:20","1286.49","5.03","7.03","1914.86","7.48","4.87","1320.55","5.16","6.90""09/04/2013
    22:00:31","1222.56","4.78","7.44","1775.23","6.93","5.21","1253.87","4.90","7.28""09/04/2013
    22:00:41","1269.87","4.96","7.15","1847.40","7.22","4.97","1267.62","4.95","7.13""09/04/2013
    22:00:51","1291.36","5.04","7.05","1857.97","7.26","4.96","1289.40","5.04","7.08""09/04/2013
    22:01:01","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:11","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:22","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:32","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013 22:01:42","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00"


    この問題は、VSCSI Invalid メッセージが、 Falseではなく、デフォルトで Trueに設定されているときに発生します。

    今回のリリースで、この問題は修正されました。

Virtual SAN の問題

  • Advance Host Controller Interface (AHCI)ドライバが要求するストレージ ディスクは、それらのディスクが Virtual SAN ディスク グループに含まれている場合にはホット アンプラグできない
    AHCI ドライバは、マザーボード上の SATA ポートまたは AHCI 対応のストレージ アダプタを介した SATA ポートに接続されているデータ ストレージ ディスクまたは SSD ストレージ ディスクを要求します。それらのディスクが AHCI ドライバによって要求される場合、ディスクが Virtual SAN ディスク グループに含まれていると、ディスクを ESXi ホストからホット アンプラグできません。ホット アンプラグを行うと、ディスクを接続し直した後、ホストがディスクを検出できません。

    今回のリリースで、この問題は修正されました。
  • SSD ホット アンプラグ時に、ESXi ホストでエラーが発生することがある。
    SSD をホット アンプラグしようとすると ESXi ホストがクラッシュして停止することがあります。

    今回のリリースで、この問題は修正されました。
  • ホット アンプラグしてホット インサートし直したディスクは Virtual SAN で検出されないことがある
    SSD または非 SSD ディスクをホット アンプラグした場合、ホット インサートし直した後、そのディスクが Virtual SAN で検出されないことがあります。

    今回のリリースで、この問題は修正されました。
  • ESXi ホストが単一のノード クラスタを形成し、既存の Virtual SAN クラスタには参加できない
    この問題は、Virtual SAN が有効になっているときに Virtual SAN に構成されている vmknic に IP アドレスがない場合に発生します。Virtual SAN 対応の vmknic が IP アドレスを取得する時点で hostd がまだ起動していないと、ホストは単一のノード クラスタを形成する可能性があります。

    今回のリリースで、この問題は修正されました。
  • Virtual SAN クラスタの現在の容量使用率が 70% を超えていると、 全データの退避オプションを使用してノードをメンテナンス モードにすることができない
    この問題は、クラスタからノードを削除した結果、容量使用率が Virtual SAN クラスタの 70% を超える場合に発生します。クラスタ容量は Virtual SAN クラスタ内の容量を意味します。

    今回のリリースで、この問題は修正されました。
  • ストレージ ポリシーが設定された仮想マシンのクローン作成を行うと、不要な場合でも常にそのストレージ ポリシーがターゲットの仮想マシンに転送される。
    ストレージ ポリシーに関連付けられた仮想マシンのクローン作成を行い、ターゲットの仮想マシンにストレージ ポリシーを割り当てないことを選択した場合、クローン作成プロセスは成功します。しかし、元の仮想マシンのストレージ ポリシーが、ターゲットの仮想マシンの構成に使用されます。その結果、ターゲットの仮想マシンによって Virtual SAN データストア上のリソースが誤って余分に使用されることがあります。

    今回のリリースで、この問題は修正されました。

vCenter Server および vSphere Web Client の問題

  • 仮想ディスクのスループットのパフォーマンス統計計算が 1024 係数だけ間違っていることがある
    仮想ディスクのスループットのパフォーマンス統計計算は、秒あたりのバイト単位で誤って測定されます。

    今回のリリースでは、測定単位を秒あたりのキロバイト数に変更することで、この問題を解決しています。

仮想マシンの管理の問題

  • BIOS で [Legacy Floppy Disk] が無効になっていると CD または DVD から仮想マシンを起動できない
    BIOS で [Legacy Floppy Disk] を無効にすると、仮想マシンを起動できないことがあります。この問題は、次の手順を実行すると発生します。
    1. オペレーティング システムを指定せずに仮想マシンを作成します。
    2. 仮想マシン設定 を使用して、ゲスト OS にインストールする ISO イメージ ファイルまたは物理ドライブに接続する CD または DVD を構成します。
    3. BIOS で [Legacy Floppy Disk] を無効にします。
    BIOS で [Legacy Floppy Disk] を無効にすると、仮想マシンでビープ音が 2 回鳴り、起動に失敗します。

    今回のリリースで、この問題は修正されました。
  • 仮想マシンを OVF としてエクスポートしようとするとタイムアウト エラーで失敗する
    仮想マシンで Ext 2または Ext 3ファイル システムが使用され、そのディスクに大量の空のブロック(210 GB 以上の空のセカンダリ ディスクなど)が Open Virtualization Format (OVF)で存在する場合、この仮想マシンをエクスポートしようとすると、操作はタイムアウトします。

    今回のリリースで、この問題は修正されました。

VMware HA および Fault Tolerance の問題

  • HA の構成が失敗して、HA マスター エージェントが見つかりませんというエラー メッセージが表示されることがある
    HA (High Availability) の構成が失敗することがあります。次のようなエラー メッセージが vpxd.logファイルに記録されることがあります。

    vpxd-1967.log:2013-04-06T01:35:02.156+09:00 [07220 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_GD for 120 seconds
    vpxd-1968.log:2013-04-06T05:02:55.991+09:00 [07320 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_ID for 120 seconds


    この問題は、hostd 機能がセッションを使い切ると発生します。次のようなエラー メッセージが hostd.logファイルに記録されます。

    SOAP session count limit reached.

    今回のリリースで、この問題は修正されました。

アップグレードとインストールの問題

  • UnboundLocalError エラーで ESXi インストールが失敗する
    ESXi インストールが失敗し、次のエラーが表示されます。 UnboundLocalError: local variable 'isLocalOnlyAdapter' referenced before assignment

    今回のリリースで、この問題は修正されました。

VMware Tools の問題

  • VSS ドライバを登録解除しようとすると、VMware Tools の更新中に vCenter 保護エージェントで警告メッセージが表示されることがある
    Windows ゲスト OS で VMware Tools を更新しようとしていて、VMware Tools ビルドに署名なしの comreg.exeファイルがあり、VSS ドライバを登録解除しようとすると、vCenter 保護エージェントで次のような警告メッセージが表示されることがあります。

    comreg.exe was trying to run

    今回のリリースで、この問題は VMware の署名入り comreg.exeファイルを含めることにより修正されました。
  • Microsoft Office でファイルを共有ディレクトリに保存できない
    Microsoft Office 2007 または Microsoft Office 2010 アプリケーションから VMware vShield Endpoint とエージェントレス アンチウイルス ソリューションによって保護された仮想マシン上の共有ディレクトリにファイルを保存するときに、次のようなエラー メッセージが表示されます。

    ファイルは現在使用されています。後でもう一度やり直してください。
    ファイルがこの場所に保存できません。

    Windows Share に保存されたファイルは空で、サイズは 0 KB です。

    今回のリリースで、この問題は修正されました。

  • RHEL 6.2 で VMware Tools を更新しているときにエラーが発生する
    RPM (Red Hat Package Manager) を使用して RHEL 6.2 (Red Hat Linux Enterprise) 仮想マシンで VMware Tools を以前のバージョンから 9.0.5 バージョンに更新するときに、次のようなエラーが表示されることがあります。

    Error: Package: kmod-vmware-tools-vsock-9.3.3.0-2.6.32.71.el6.x86_64.3.x86_64 (RHEL6-isv)
    Requires: vmware-tools-vsock-common = 9.0.1
    Installed: vmware-tools-vsock-common-9.0.5-1.el6.x86_64 (@/vmware-tools-vsock-common-9.0.5-1.el6.x86_64)
    vmware-tools-vsock-common = 9.0.5-1.el6
    Available: vmware-tools-vsock-common-8.6.10-1.el6.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 8.6.10-1.el6
    Available: vmware-tools-vsock-common-9.0.1-3.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 9.0.1-3

    今回のリリースで、この問題は修正されました。

  • --cmd 引数を使用して仮想マシンの情報を取得中に VMware Tools サービスが失敗する
    vmtoolsd --cmd "info-get guestinfo.ovfEnv"などの vmtoolsdクエリを実行すると、VMware Tools サービスが失敗することがあります。この問題は、VMware Tools バージョン 9.0.1 と 9.0.5 で発生することが確認されています。

    今回のリリースで、この問題は修正されました。
  • Oracle Linux 5.x で事前ビルド済みカーネル モジュールが欠落している
    VMware Tools は 2.6.39-200/400事前ビルド済みカーネル モジュールを含む Oracle Linux 5.x を提供するように更新されています。

    今回のリリースで、この問題は修正されました。
  • Operating System Specific Package を使用して VMware Tools をインストールすると、/tmp/vmware-root ディレクトリが vmware-db.pl.* ファイルでいっぱいになる
    OSP を使用して VMware Tools をインストールすると、 /tmp/vmware-rootディレクトリ内のログ ファイルの数が増加します。この問題は、SUSE Linux Enterprise Server 11 Service Pack 2 および RedHat Enterprise Linux 6 の仮想マシンで発生することが確認されています。

    今回のリリースで、この問題は修正されました。
  • Linux ゲスト OS で VMware Tools がインストールされていることを vSphere Web Client が認識しないことがある
    Linux ゲスト OS で VMware Tools がインストールされていることを vSphere Web Client が認識しないことがあります。
    次のようなエラー メッセージが vSphere Web Client の サマリ タブに表示されることがあります。
    VMware Tools がこの仮想マシンにインストールされていません。

    今回のリリースで、この問題は修正されました。
  • Maxon Cinema 4D アプリケーションが vSGA モードで失敗することがある
    アプリケーションの UI 項目のいずれかをクリックしようとすると、VMware OpenGL ドライバの問題が原因で、Maxon Cinema 4D が vSGA (Virtual Shared Graphics Acceleration) モードで失敗することがあります。

    今回のリリースで、この問題は修正されました。
  • Petrel 3D アプリケーションを仮想マシンで実行すると、レンダリング関連のエラーが表示されることがある
    Petrel 3D アプリケーションを仮想マシンで実行すると、OpenGL グラフィック ドライバの問題が原因で、レンダリングに関連するエラーが表示されることがあります。

    今回のリリースで、この問題は修正されました。
  • ユーザーが VMware Tools のアップグレード中に Windows 8 および Windows 8.1 仮想マシンから強制的に ログアウトさせられる
    Windows 8 および Windows 8.1 仮想マシンで VMware Tools をアップグレードしている間、ユーザーが仮想マシンから自動的にログアウトさせられます。

    今回のリリースで、この問題は修正されました。

既知の問題

既知の問題で以前記載されていなかったものには、* 記号が付加されています。既知の問題は、以下のとおり、グループ化されます:

インストールの問題
  • Simple Install が Windows Server 2012 で失敗する
    DHCP IP アドレスを使用するようにオペレーティング システムが構成されている場合、Windows Server 2012 での Simple Install が失敗します。

    回避策: 固定 IP アドレスを使用するように、Windows 2012 Server を構成します。

  • ソフトウェア iSCSI LUN のインストールが失敗し、エラー [2 つの起動バンクが求められていますが、0 個が見つかりました] が表示される
    この問題を伴うエラーの全容は次のとおりです。
    エラー (詳細はログを参照):
    2 つの起動バンクが求められていますが、0 個が見つかりました。

    最初のネットワーク アダプタが iBFT iSCSI から起動するように構成されている場合に、この問題は発生します。iSCSI 起動ディスクにアクセスするように作成された VMkernel ネットワーク ポートを構成するのに iBFT IP 設定が使用されているからです。この場合、最初のアダプタは管理トラフィック用に使用されるため、このポートは管理ネットワーク ポートになります。

    インストールが約 90% 終了した段階で、インストーラが DHCP を使用して管理インターフェイスを再構成します。結果として、iBFT IP 設定は失われ、iSCSI 起動ターゲットとの TCP 接続は切断されます。

    回避策: 次のいずれかの操作を実行します。

    • 複数のネットワーク アダプタが利用可能な場合、2 番目のネットワーク アダプタを使用して、iSCSI 起動ディスクにアクセスします。
    • 1 つのネットワーク アダプタしか利用できない場合は、DHCP を使用するように iBFT を構成します。iSCSI ターゲットは、管理ネットワーク上に存在する必要があります。iSCSI ターゲットが別のサブネット上にある場合は、デフォルトの VMkernel ゲートウェイが、管理トラフィックと iSCSI トラフィックの両方の経路選択を行うことができます。

     

  • Auto Deploy ステートレス キャッシュまたは Auto Deploy ステートフル インストールで [VMFS を保持] を使用すると、コア ダンプ パーティションが作成されない
    空のディスク上でステートレス キャッシュまたはステートフル インストールに Auto Deploy を使用すると MSDOS パーティション テーブルが作成されます。しかし、コア ダンプ パーティションは作成されません。

    回避策: ステートレス キャッシュまたはステートフル インストール ホスト プロファイル オプションを有効にする場合、空のディスク上にインストールする場合でも VMFS を上書き を選択します。これにより、2.5GB のコアダンプ パーティションが作成されます。

  • スクリプトによるインストール中に、installorupgrade コマンドで --ignoressd オプションが使用されていても SSD 上に ESXi がインストールされる
    ESXi 5.5 では、 installorupgradeコマンドの --ignoressdオプションはサポートされていません。 installorupgradeコマンドで --ignoressdオプションを使用すると、インストーラはこれが無効な組み合わせであることを示す警告を表示しますが、インストールを停止してエラー メッセージを表示するのではなく、SSD 上に ESXi のインストールを続行します。

    回避策: スクリプトによる ESXi のインストールで --ignoressdオプションを使用するには、 installorupgradeコマンドではなく installコマンドを使用します。

  • Auto Deploy キャッシュ消去の遅延により、削除されたホスト プロファイルが適用される場合がある
    ホスト プロファイルは削除された後すぐに Auto Deploy キャッシュから消去されるわけではありません。ホスト プロファイルがキャッシュに存在している限り、Auto Deploy はそのプロファイルを適用し続けます。プロファイルを適用するルールは、そのプロファイルがキャッシュから消去されている場合のみ失敗します。

    回避策: Get-DeployRuleSetPowerCLI cmdlet を使用して、削除されたホスト プロファイルをルールで使用するかどうかを決定できます。この cmdlet を使用すると、ルールの itemlistdeletedという文字列が表示されます。次に、 Remove-DeployRulecmdlet を実行してルールを削除します。

  • 選択したディスクに ESX がインストールされていると、ステートレス キャッシュが有効な Auto Deploy を使用するよう設定されているホスト プロファイルの適用に失敗する
    ステートレス キャッシュが有効になっている Auto Deploy を設定するには、ホスト プロファイルを使用します。ホスト プロファイルで、ESX (ESXi ではない) のバージョンがインストールされているディスクを選択します。ホスト プロファイルを適用すると、次のテキストを含むエラーが表示されます。
    2 つの起動バンクが求められていますが、0 個が見つかりました

    回避策: 異なるディスクを選択してステートレス キャッシュを使用するか ESX ソフトウェアをディスクから削除します。ESX ソフトウェアは削除すると使用できなくなります。

  • Oracle America (Sun) ベンダーのサーバ上で ESXi バージョン 5.5.0 のインストールまたは起動が失敗する
    Oracle America (Sun) ベンダーのサーバ上で新規の ESXi バージョン 5.5.0 をインストールしたり、既存の ESXi バージョン 5.5.0 インストールを起動すると、インストール プロセス中または既存の ESXi 5.5.0 ビルドの起動中にサーバ コンソールに空白画面が表示されます。これは、Oracle America (Sun) ベンダーのサーバでは、ヘッドレス プラットフォームでないにも関わらず ACPI FADTテーブル内で HEADLESSフラグが設定されているために発生します。

    回避策: ESXi 5.5.0 をインストールまたは起動するときに、起動オプション ignoreHeadless="TRUE"を渡します。

アップグレードの問題

  • パッチ ID ESXi550-Update01 のパッチ名が「see description」として表示される*
    vSphere Update Manager を使用しているときに、ESXi 5.5 Update 1 ロールアップ バンドル、パッチ ID ESXi550-Update01のパッチ名が「 see description, (No KB)」と表示されることがあります。
    パッチ名の欠落によって機能上の影響が出ることはありません。ロールアップ バンドルの詳細は KB 2065832 に記載されています。

    回避策:なし
  • 物理 RAM が 4 GB 未満の場合に ESXCLI コマンドを使用して ESXi ホストをアップグレードすると、アップグレードは成功するが、再起動時に一部の ESXi 操作が失敗する
    ESXi 5.5 には、少なくとも 4GB の物理 RAM が必要です。ESXCLI コマンドライン インターフェイスは、必要な 4GB のメモリがあるかどうかをアップグレード前に確認しません。メモリが不十分でも ESXCLI を使用してホストを正常にアップグレードできますが、4GB 未満の RAM でアップグレードした ESXi 5.5 ホストを起動すると、一部の操作が失敗する場合があります。

    回避策:なし。バージョン 5.5 にアップグレードする前に、ESXi ホストに 4GB 以上の物理 RAM があることを確認してください。

  • vCenter Server Appliance 5.0.x から 5.5 にアップグレード後、外部の vCenter Single Sign-On を使用すると、vCenter Server が起動しない
    vCenter Server Appliance を 5.0.x から 5.5 にアップグレード中に、外部の vCenter Single Sign-On インスタンス使用を選択すると、アップグレード後に vCenter Server が起動しなくなります。vCenter Single Sign-On はアプライアンス管理インターフェイスに 未構成 (not configured) と表示されます。

    回避策: 次の手順を実行します。

    1. Web ブラウザで、vCenter Server Appliance 管理インターフェイス (https:// appliance-address:5480) を開きます。
    2. [vCenter Server/サマリ] ページで、 [サーバの停止] ボタンをクリックします。
    3. [vCenter Server/SSO] ページで、正しい設定をフォームに入力し、 [設定の保存] をクリックします。
    4. [サマリ] ページに戻り、 [サーバの起動] をクリックします。

     

  • ESXCLI を使用して ESXi 4.x または 5.0.x ホストをバージョン 5.1 または 5.5 へアップグレードすると、アップグレード後にすべての VMKernel ポート グループの vMotion の設定および Fault Tolerance のログ記録 (FT ログ記録) の設定が失われる
    コマンド esxcli software profile update <options>を使用して ESXi 4.x または 5.0.x ホストをバージョン 5.1 または 5.5 にアップグレードすると、アップグレードは成功しますが、すべての VMkernel ポート グループの vMotion の設定および FT ログ記録の設定が失われます。その結果、vMotion および FT ログ記録はリストアされ、デフォルトの設定である無効になります。

    回避策:対話型アップグレードまたはスクリプトによるアップグレードを実行するか、vSphere Update Manager を使用してホストをアップグレードします。 esxcliコマンドを使用する場合、影響を受けた VMkernel ポート グループに対して、アップグレード後に vMotion の設定および FT ログ記録の設定を手動で適用する必要があります。

  • vSphere 5.0.x 以前のバージョンをバージョン 5.5 にアップグレードすると、手動で設定されたシステム リソース割り当て値がデフォルト値にリセットされる
    vSphere 5.0.x 以前のバージョンでは、一時的な回避策として、システム リソース割り当てユーザー インターフェイスの設定を変更する場合、完全に ESXi を再インストールせずにこれらの設定の値をデフォルトにリセットすることはできません。vSphere 5.1 以降のバージョンではシステム動作が変更されたため、カスタム システム リソース割り当て設定を保持すると、使用することが安全でない値になる場合があります。このため、アップグレードによりそれらの値はすべてリセットされます。

    回避策:なし。

  • ESX 4.x から ESXi 5.5 へアップグレードすると仮想 NIC vmk0 の IPv6 設定が保持されない
    IPv6 を有効にした ESX 4.x ホストを --forcemigrateオプションを使用して ESXi 5.5 にアップグレードすると、仮想 NIC vmk0 の IPv6 アドレスはアップグレード後に保持されません。

    回避策:なし。

vCenter Single Sign-On の問題
  • vSphere Web Client の 5.1 Update 1a から 5.5 へのアップグレード中に、エラー 29107 が表示される
    アップグレード前に使用中だった vCenter Single Sign-On サービスが High Availability Single Sign-On として構成されている場合、vSphere Web Client のバージョン 5.1 Update U1a からバージョン 5.5 へのアップグレード中に、エラー 29107 が表示されます。

    回避策: アップグレードを再度実行します。インストーラを実行し、[カスタム インストール] を選択することで、vSphere Web Client のみをアップグレードできます。

  • vSphere Web Client のプルダウン メニューから administrator@vsphere.local のパスワードを変更できない
    vSphere Web Client から vCenter Single Sign-On サーバーにログインしている場合は、プルダウン メニューからパスワードを変更できますが、administrator@vsphere.local でログインしている場合は、 パスワードの変更 オプションはグレイアウトされています。

    回避策:

    1. 管理 タブを選択して、 vCenter Single Sign-On > ユーザーとグループ を選択します。
    2. 管理者ユーザーを右クリックして、 ユーザーの編集 をクリックします。
    3. パスワードを変更します。

     

ネットワークの問題

  • vmknic インターフェイスおよび動的 IP アドレスに関連付けられた固定ルートが再起動後に表示されないことがある*
    ホストの再起動後に、VMkernel ネットワーク インターフェイス (vmknic) および動的 IP アドレスに関連付けられた固定ルートが表示されなくなることがあります。
    この問題は、DHCP クライアントとリストア ルート コマンド間の競合状態が原因で発生します。DHCP クライアントは、ホストが再起動プロセス中にカスタム ルートをリストアしようとすると、vmknics の IP アドレスの取得を完了しないことがあります。その結果、ゲートウェイが設定されず、ルートがリストアされない場合があります。

    回避策esxcfg-route –rコマンドを実行してルートを手動でリストアします。
  • IPv6 アドレスを使用して vCenter Server に追加した ESXi ホストが応答しなくなる
    ESXi ホストを fe80::/64形式の IPv6 リンク ローカル アドレスを使用して vCenter Server に追加した場合、しばらくするとホスト名が淡色表示になり追加したホストが vCenter Server に応答しなくなります。

    回避策: リンク ローカル アドレスではない有効な IPv6 アドレスを使用してください。

  • vSphere Web Client では、物理 NIC でサポートされているよりも多くの仮想機能を構成することができ、エラー メッセージが表示されない
    物理アダプタの SR-IOV 設定では、アダプタでサポートされているよりも多くの仮想機能を構成することができます。たとえば、23 個の仮想機能しかサポートしない NIC に 100 個の仮想機能を構成することができ、エラー メッセージは表示されません。この場合、この SR-IOV 設定を適用するためにホストの再起動を促すメッセージが表示されます。ホストが再起動すると、NIC はアダプタがサポートする最大数の仮想機能 (この例では、23 個) で構成されます。ホストの再起動を促すメッセージが、このメッセージが表示されるべきではないタイミングで表示され続けることになります。

    回避策:なし

  • SR-IOV を有効にした ESXi ホストで、仮想機能に関連付けられた仮想マシンが起動しないことがある
    Intel ixgbe NIC を搭載した ESXi 5.1 以降のホストで SR-IOV を有効にした環境でいくつかの仮想機能を有効にすると、一部の仮想マシンが起動に失敗する場合があります。
    vmware.logファイルには、次のようなメッセージが含まれます。
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

    回避策: 影響を受ける仮想マシンに関連付ける仮想機能の数を減らしてから、仮想マシンを起動します。

  • Emulex BladeEngine 3 物理ネットワーク アダプタで、仮想機能でバッキングされた仮想マシン ネットワーク アダプタが、アップリンクとして物理機能を使用する VMkernel アダプタにアクセスできない
    仮想機能とその物理機能の間では、トラフィックが流れません。たとえば、物理機能にバッキングされたスイッチでは、同じポートで仮想機能を使用する仮想マシンは、同じスイッチの VMkernel アダプタにアクセスすることはできません。これは Emulex BladeEngine 3 物理アダプタの既知の問題です。詳細については、Emulex にお問い合わせください。

    回避策:ホスト上の Emulex BladeEngine 3 デバイスに対するネイティブ ドライバを無効にします。詳細については、 VMware KB 2044993 を参照してください。

  • ESXi Dump Collector が、ESXi コア ファイルのリモート サーバへの送信に失敗する
    ESXi Dump Collector のトラフィックを処理する VMkernel アダプタが、アクティブなアップリンクとして設定されているリンク集約グループ (LAG) を持つ分散ポート グループになるように構成されている場合、ESXi Dump Collector は、ESXi コア ファイルの送信に失敗します。LACP ポート チャネルは、物理スイッチ上に構成されています。

    回避策: 次のいずれかの回避策を実行します。

    • ESXi Dump Collector のトラフィックをリモート サーバを使って処理する VMkernel アダプタを、vSphere 標準スイッチを使用して構成します。
    • スタンドアロン アップリンクを使用して、VMkernel アダプタが構成されている分散ポート グループのトラフィックを処理します。
  • vSphere 標準スイッチまたは vSphere Distributed Switch がホスト上に持つポートの数を vSphere Client を使用して変更した場合、再起動しても、変更が保存されていない
    vSphere 標準スイッチまたは vSphere Distributed Switch が ESXi 5.5 ホスト上に持つポートの数を vSphere Client を使用して変更した場合、ホストを再起動しても、ポートの数は変更されていません。

    ESXi 5.5 を実行しているホストが再起動されると、仮想スイッチのポートの増減を動的に行います。ポートの数はホストが実行できる仮想マシンの数に基づいて決まります。このようなホストのスイッチ ポートの数を設定する必要はありません。

    回避策: vSphere Client での回避策はありません。

サーバ構成の問題

  • シリアル コンソールからダイレクト コンソール ユーザー インターフェイスにアクセスすると、メニュー ナビゲーションの問題が発生する*
    シリアル コンソールからダイレクト コンソール ユーザー インターフェイス (DCUI) にアクセスすると、メニューへのナビゲーション中に上矢印キーと下矢印キーが機能しなくなり、ユーザーが強制的に DCUI 構成画面からログアウトさせられます。

    回避策: DCUI プロセスを停止します。DCUI プロセスは自動的に再起動されます。

  • ESXi ホストを 5.5 Update 1 にアップグレードしてホスト構成を変更した後で、ホスト プロファイルが間違って準拠として表示されることがある*
    ホスト プロファイルに準拠した ESXi ホストを ESXi 5.5 Update 1 に更新してホスト構成を一部変更し、ホストのホスト プロファイルへの準拠を確認し直すと、プロファイルが間違って準拠と報告されます。

    回避策:
    • vSPhere Client で問題のあるホスト プロファイルに移動し、 参照ホストからのプロファイルの更新 を実行します。
    • vSPhere Web Client で問題のあるホスト プロファイルに移動し、 ホストから設定をコピー をクリックし、構成設定をコピーするホストを選択して OK をクリックします。
  • ホスト プロファイルの修正が vSphere Distributed Switch で失敗する
    ホスト プロファイルの vSphere Distributed Switch への適用時に、そのホスト プロファイルの Distributed Switch を使用しているホスト上で Fault Tolerance に対応する仮想マシンがパワーオフ状態の場合に、修正エラーが発生することがあります。

    回避策:ホスト プロファイルが正常に実行されるよう、パワーオフされている仮想マシンを別のホストに移動します。

  • ステートレス キャッシュまたは USB へのステートフル インストールのために Auto Deploy を使用した後、コンプライアンス違反メッセージが表示される
    ホストの USB ディスクへのステートレス キャッシュを有効にするためにホスト プロファイルを編集した後に、修正しようとすると、ホスト プロファイルはコンプライアンス エラーを受け取ります。ホストが再起動し、キャッシングが完了します。コンプライアンスのチェック後、以下のコンプライアンス エラーを受け取ります。
    ホスト状態が仕様と一致しません

    回避策:回避策は必要ありません。このメッセージは、正しくありません。

  • ESX 4.0 または ESX 4.1 プロファイルを ESXi 5.5.x ホストに適用する場合に、ホスト プロファイルがファイアウォール設定コンプライアンス エラーを受け取る
    ESX 4.0 または ESX 4.1 からホスト プロファイルを抜き出して、そのプロファイルを ESXi 5.5.x ホストに適用しようとした場合、プロファイルの修正は成功します。ただし、コンプライアンス チェックが、次のようなファイアウォール設定エラーを受け取ります。
    ルールセット LDAP が見つかりません
    ルールセット LDAPS が見つかりません
    ルールセット TSM が見つかりません
    ルールセット VCB が見つかりません
    ルールセット activeDrirectorKerberos が見つかりません

    回避策:回避策は必要ありません。ESX 4.0、ESX 4.1 ホストのファイアウォール設定と ESXi 5.5.x ホストのファイアウォール設定は異なるため、これは想定どおりの動作です。

  • ESXi ホストの BIOS のデバイス設定を変更するとデバイス名が無効になることがある
    ESXi ホストの BIOS のデバイス設定を変更することでデバイスに割り当てられた <segment:bus:device:function> の値にずれが生じた場合、デバイス名が無効になることがあります。たとえば、以前に無効にした統合 NIC を有効にすると、他の PCI デバイスに割り当てられた <segment:bus:device:function> の値にずれが生じ、結果的に ESXi はこれらの NIC に割り当てられた名前を変更します。以前のバージョンの ESXi とは異なり、ホスト BIOS からデバイスの固有の場所の情報が提供されている場合、ESXi 5.5 は <segment:bus:device:function> の変更を介してデバイス名の保存を試みます。この機能のバグにより、vmhba1 や vmnic32 などの無効な名前が生成されることがあります。

    回避策:ESXi ホストを数回再起動すると、無効なデバイス名が消去され、元の名前が復元される可能性があります。本番環境では ESXi ホストを無効なデバイス名とともに実行しないでください。

ストレージの問題

  • RDM ディスクを含む仮想マシンのライブ Storage vMotion を実行しようとすると、失敗することがある*
    RDM ディスクを含む仮想マシンの Storage vMotion が失敗し、仮想マシンがパワーオフ状態として表示されることがあります。仮想マシンをパワーオンしようとすると失敗し、次のエラーが表示されます。

    ファイルをロックできませんでした

    回避策: なし。
  • 名前が変更されたタグが、仮想マシン ストレージ ポリシーの編集ウィザードで消えてしまったように見える
    仮想マシン ストレージ ポリシーには、データストア タグに基づくルールが含まれることがあります。タグの名前を変更した場合、このタグを参照するストレージ ポリシーは、このタグを自動的にアップグレードせず、このタグを [なし] と表示します。

    回避策:[なし] と表示されているタグを、仮想マシン ストレージ ポリシーから取り除いてから、名前を変更したタグを追加します。すべての期限切れエンティティにストレージ ポリシーを再適用します。

  • Flash Read Cache のブロック サイズが 16KB、256KB、512KB、または 1024KB に設定されている場合、仮想マシンをパワーオンすることができない
    16KB、256KB、512KB、または 1024KB のブロック サイズの Flash Read Cache で構成されている仮想マシンは、パワーオンできません。Flash Read Cache がサポートするキャッシュ サイズは 最小 4MB、最大 200GB、ブロック サイズは 最小 4KB、最大 1MB です。サポートされていないキャッシュ サイズ、ブロック サイズの仮想マシンをパワーオンした場合、操作は失敗し、次のメッセージが表示されます。

    仮想マシンのパワーオン時に ESX ホストからエラーを受信しました。

    仮想マシンの起動に失敗しました。

    Module DiskEarly のパワーオンに失敗しました。

    ディスク scsi0:0 の構成に失敗しました。

    未構成のディスクを使用して仮想マシンをパワーオンすることはできません。 vFlash キャッシュを接続できません: msg.vflashcache.error.VFC_FAILURE

    回避策:仮想マシンの Flash Read Cache のサイズとブロック サイズを設定してください。

    1. 仮想マシンを右クリックし、 設定の編集 を選択します。
    2. 仮想ハードウェア タブで、 ハード ディスク を展開してディスク オプションを表示します。
    3. 仮想 Flash Read Cache フィールドの横の 詳細 をクリックしてください。
    4. キャッシュ サイズの予約を増やしてください。もしくは、ブロック サイズを縮小してください。
    5. OK をクリックして、変更内容を保存します。
  • 保存したリソース プール ツリー ファイルのカスタム拡張子を、vSphere Web Client に読み込めない
    ホスト サマリ ページに、DRS エラー メッセージが表示されます。

    vSphere Web Client で DRS を無効にすると、リソース プール構造を将来的に再度読み込めるように保存しておくよう要求されます。このファイルのデフォルトの拡張子は .snapshotですが、このファイルに別の拡張子を選ぶこともできます。ファイルがカスタム拡張子を使用している場合、ファイルを読み込もうとしたときに無効と表示されます。この現象は、OS X でのみ起きることが確認されています。

    回避策:OS X 上の vSphere Web Client にファイルを読み込むには、拡張子を .snapshotに変更します。

  • DRS エラー メッセージがホスト サマリ ページに表示される
    次の DRS エラー メッセージがホスト サマリ ページに表示されます。

    ホストに DRS リソース構成を適用できませんでした。その操作は、現在の状態では実行できません。DRS の性能が極端に低下する可能性があります。

    一部の構成では、競合状態により、意味があるわけでも操作を指示するわけでもないエラー メッセージがログに作成されることがあります。DRS リソース構成が適用されたのと同時に仮想マシンの登録が解除された場合に、このエラーは発生することがあります。

    回避策:このエラー メッセージを無視します。

  • 16TB を超える VMDK に仮想 Flash Read Cache を設定すると、エラーが発生する
    仮想 Flash Read Cache は、16TB を超える仮想マシン ディスクをサポートしません。このようなディスクを構成しようとしても、失敗します。

    回避策:なし

  • キャッシュ サイズが再構成されたときに、仮想マシンがパワーオフすることがある
    無効な値の割り当てなどを行い、仮想マシンに仮想 Flash Read Cache を不適切に再構成した場合、仮想マシンがパワーオフすることがあります。

    回避策:『 vSphere ストレージ』ドキュメントの推奨キャッシュ サイズのガイドラインに従ってください。

  • 仮想マシンで仮想 Flash Read Cache を有効にする再構成が、 操作のタイムアウトエラーで失敗することがある
    再構成の操作は非常に大きな I/O バンド幅を必要とします。負荷の重い処理を実行している場合、再構成の操作が完了する前に操作がタイムアウトになる可能性があります。また、ホスト上に APD (All-Paths-Down) 状態の LUN がある場合にも、この現象が発生することがあります。

    回避策:ホストの APD 状態をすべて解消し、LUN とホストの I/O 負荷を減らしてから、操作をやり直してください。

  • ロード バランシングのための仮想 Flash Read Cache を持つ仮想マシンに対して、DRS が vMotion を実行しない
    ロード バランシングのための仮想 Flash Read Cache を持つ仮想マシンには、DRS は vMotion を実行しません。

    回避策:次のような理由がある場合を除いて、DRS は vMotion を上記のような仮想マシンに使用することを推奨しません。

    • メンテナンス モードまたはスタンバイ モードに切り替えることをユーザーが要求したホストを退避させるため
    • DRS のルール違反を修正するため
    • ホストのリソース使用量が赤色の状態になっている場合
    • 1 つまたは大部分のホストが過剰に使用されており、仮想マシン需要が満たされていない場合
      注:この理由を無視するように、DRS を設定することもできます。
  • 仮想マシンのアクティブなメモリが Low メモリで、消費されたメモリが High メモリの場合、ホストがスタンバイ状態になる
    ESXi 5.5 では、DPM のデフォルト動作に DPM の積極性を低下させるための変更が加えられています。この変更は、アクティブなメモリが Low メモリで、消費されたメモリが High メモリの場合の仮想マシンのパフォーマンスの低下を防止するのに役立ちます。DPM のメトリックは、 X% * IdleConsumedMemory + アクティブなメモリです。この X% 変数は調整可能で、デフォルトでは 25% に設定されています。

    回避策:詳細オプションで PercentIdleMBInMemDemand=0を設定することで、ESXi の以前のリリースの積極性のある DPM 動作に戻すことができます。

  • DRS によって起動された vMotion が失敗することがある
    仮想 Flash Read Cache の予約がある仮想マシンに、DRS が vMotion を推奨する場合、仮想マシンの仮想 Flash Read Cache の予約を管理するホストでメモリ (RAM) の空き容量が不足していることが原因で、vMotion が失敗することがあります。

    回避策:『vSphere ストレージ  』の Flash Read Cache 構成の推奨事項に従ってください。
    vMotion が失敗した場合、次の手順を実行します。

    1. ターゲット ホスト上の仮想マシンのブロック サイズと移行する仮想マシンのブロック サイズを再設定し、接続先ホスト上の VMkernel メモリの使用量を全体的に減らします。
    2. 手動で vMotion を実行して仮想マシンを接続先ホストに移行し、確実に状況が解決されるようにしてください。
  • 個々の SSD デバイスの仮想フラッシュの構成中に発生した問題を表示できないことがある
    仮想フラッシュ リソースの構成は、SSD デバイスのリスト上で操作するタスクです。すべてのオブジェクトでこのタスクが完了したとき、vSphere Web Client はタスクの成功を通知しますが、個々の SSD デバイスの構成での問題点は通知されないこともあります。

    回避策:次のいずれかのタスクを実行します。

    • [最近のタスク] パネルで、完了済みのタスクをダブルクリックしてください。
      構成の失敗は、[タスク詳細] ダイアログ ボックスで [関連イベント] セクションに表示されます。
    • または、次の手順を実行します。
      1. インベントリでホストを選択します。
      2. 監視 タブをクリックし、 イベント をクリックします。
  • ESXi ホスト上の Micron PCIe SSD の SMART 情報を取得することができない
    esxcli storage core device smart get -dコマンドを使用して Micron PCIe SSD デバイスの統計情報を表示しようとしても失敗し、次のエラー メッセージが表示されます。
    SMART パラメータ取得でエラー:デバイスをオープンできません

    回避策:なし。このリリースでは、 esxcli storage core device smartコマンドは、Micron PCIe SSD をサポートしていません。

  • ESXi が、仮想マシンの構成ファイルで SCSI 仮想ディスク用に設定した帯域幅制限を適用しない
    SCSI 仮想ディスクの帯域幅とスループットの制限は、仮想マシンの構成ファイル ( .vmx) で、一連のパラメータを使用して設定します。たとえば、構成ファイルには、scsi0:0 仮想ディスク用の次の制限が含まれていることがあります。
    sched.scsi0:0.throughputCap = "80IOPS"
    sched.scsi0:0.bandwidthCap = "10MBps"
    sched.scsi0:0.shares = "normal"

    ESXi は、 sched.scsi0:0.bandwidthCap制限を scsi0:0 仮想ディスクに適用しません。

    回避策:vSphere Web Client または esxcli system settings advanced set コマンドを使用して、以前のバージョンのディスク I/O スケジューラに戻してください。

    • vSphere Web Client で、ホストの詳細システム設定リストの Disk.SchedulerWithReservationパラメータを編集します。
      1. ホストに移動します。
      2. 管理 タブで、 設定 を選択し、 システムの詳細設定 を選択します。
      3. フィルタ ボックスや 検索 テキスト ボックスなどを利用して、 Disk.SchedulerWithReservationパラメータを探します。
      4. 編集 をクリックし、パラメータを 0 に設定します。
      5. OK をクリックします。
    • ESXi Shell でホストに、次のコンソール コマンドを実行します。
      esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0
  • Flash Read Cache で構成されている仮想マシンは、キャッシュにエラーがある場合に、ホストから移行することができない
    キャッシュがエラー状態になっていて使用できない場合、Flash Read Cache で構成されている仮想マシンで移行エラーが発生する可能性があります。このエラーにより仮想マシンの移行が失敗します。

    回避策:

    1. 仮想マシンを再構成してキャッシュを無効にします。
    2. 移行を実行します。
    3. 仮想マシンが移行された後、キャッシュを再び有効にします。

    または、キャッシュでのエラーを修正するために、仮想マシンをパワーオフにしてからパワーオンにする必要があります。

  • ホストが ESXi 5.5 ベータからアップグレードされた後に VFFS ボリュームを削除できない
    ホストを ESXi 5.5 ベータからアップグレードした後、VFFS ボリュームを削除することができません。

    回避策:この問題は、ESXi 5.5 ベータから ESXi 5.5 にアップグレードしたときにのみ発生します。この問題を回避するには、アップグレードを行わずに ESXi 5.5 をインストールします。ESXi 5.5 ベータからアップグレードする場合は、アップグレード前に VFFS ボリュームを削除してください。

  • 旧バージョンの Windows および Linux ゲスト OS の仮想マシン上で仮想 Flash Read Cache が有効になった場合に、期待通りの遅延ランタイムの改善が見られない
    仮想 Flash Read Cache が最適なパフォーマンスを提供するのは、キャッシュのサイズが対象作業セットに一致するよう設定されたとき、およびゲスト ファイル システムが少なくとも 4KB 境界に整列されたときです。Flash Read Cache は、キャッシュ内で部分的なブロックをキャッシュしないよう、不整列のブロックを除外します。この動作は通常、Windows XP および 2.6 以前の Linux ディストリビューションの仮想マシンの VMDK について、仮想 Flash Read Cache が構成された場合に発生するものです。このような場合、低キャッシュ占有率での低いキャッシュ ヒット率が発生し、VMDK でのキャッシュ予約に無駄が生じていることが分かります。この動作は、Windows 7、Windows 2008、および Linux 2.6 以降のディストリビューションでは、最適なパフォーマンスを確保するためにファイル システムを 4KB 境界に整列するため、発生しません。

    回避策:キャッシュ ヒット率を改善し、各 VMDK のキャッシュ予約を最適に使用するために、VMDK にインストールされているゲスト オペレーティング ファイル システムが少なくとも 4KB 境界に整列されていることを確認してください。

Virtual SAN

  • 7 つを超える磁気ディスクを Virtual SAN ディスク グループに追加しようとすると失敗し、誤ったエラー メッセージが表示されることがある*
    Virtual SAN ディスク グループは最大で 1 つの SSD と 7 つの磁気ディスク (HDD) をサポートします。磁気ディスクをさらに追加しようとすると失敗し、次のような誤ったエラー メッセージが表示されることがあります。

    ディスクの数が不足しています。

    回避策:なし
  • Virtual SAN ディスクの追加中に再スキャンが失敗する*
    Virtual SAN ディスクを追加するときに、non-Virtual SAN ボリュームでプローブ障害が原因で再スキャンが失敗し、操作が失敗します。

    回避策: すべてのディスクは正しく登録されているため、エラーを無視します。
  • 関連付けられたソリッド ステート ドライブ (SSD) を取り外した後に取り外したハード ディスク ドライブ (HDD) が Virtual SAN によって要求されるストレージ ディスクとしてまだリストに表示されたままになることがある*
    Virtual SAN データストアから SSD を、続いて関連付けられた HDD を取り外して esxcli vsan storage listコマンドを実行すると、取り外された HDD が Virtual SAN によって要求されるストレージ ディスクとしてまだリストに表示されたままになります。HDD を異なるホストに取り付けると、ディスクは 2 つの異なるホストの一部として表示されることがあります。

    回避策: たとえば、SSD と HDD を ESXi x から取り外して ESXi y に取り付けた場合、次の手順を実行すると HDD が ESXi x と ESXi y の両方の一部として表示されるのが回避されます。
    1. ESXi x から取り外した SSD と HDD を ESXi y に取り付けます。
    2.SSD を ESXi x から廃止します。
    3. esxcfg-rescan -Aコマンドを実行します。
    HDD と SSD が ESXi x のリストに表示されなくなります。
  • vSphere Storage   ドキュメントの「 Virtual SAN の操作  」セクションには、ディスク グループあたりの最大の HDD ディスク数は 6 つと説明されている。しかし、許可される最大の HDD 数は 7 つです。*
  • Virtual SAN クラスタで障害が起きると、vSphere HA は仮想マシンを再起動する前に複数のイベント(不適切なイベントも含む)を報告することがある。*
    Virtual SAN で稼働している仮想マシンが停止したように見えた後、vSphere HA マスター エージェントはその仮想マシンを複数回再起動しようとします。仮想マシンがただちに再起動できない場合、マスター エージェントはクラスタ状態を監視し、再起動が成功する可能性があればもう一度起動を試します。Virtual SAN で稼働している仮想マシンの場合、vSphere HA マスターは特殊なアプリケーション ロジックを使用して仮想マシンのオブジェクトのアクセシビリティが変更された可能性がある時点を検出し、アクセシビリティ変更の可能性が認められる場合はいつでも再起動を試みます。マスター エージェントは、アクセシビリティ変更が示唆されると必ず再起動を試行し、仮想マシンを正常にパワーオンできなかった場合は、次にアクセシビリティ変更の可能性が示唆されるまで待機します。

    vSphere HA は、各試行が失敗した後にフェイルオーバーが正常に行われなかったことを示すイベントを報告します。さらに、試行が 5 回失敗した時点で、フェイルオーバーの最大試行回数に達したため、仮想マシンの再起動試行を停止したことを報告します。試行を停止したことを報告した後も、vSphere HA マスター エージェントは次にアクセシビリティ変更の可能性が示唆されると試行します。

    回避策:なし。

  • Virtual SAN ホストをパワーオフすると、vSphere Web Client の [ストレージ プロバイダ] ビューの更新に通常よりも時間がかかる*
    Virtual SAN ホストをパワーオフすると、[ストレージ プロバイダ] ビューが空であるかのようになります。情報が何も表示されないにもかかわらず、[更新] ボタンが回り続けます。

    回避策: [ストレージ プロバイダ] ビューで情報を再度表示するには、15 分以上待ちます。このビューは、ホストをパワーオンした後も更新されます。

  • 失敗したタスクが Virtual SAN によって完了済みと報告される*
    一部のタスクは、内部的に失敗した場合でも Virtual SAN によって完了済みと報告されることがあります。

    次に、状況とエラーの原因を示します。

    • 状況:Virtual SAN ライセンスの期限が切れた後、ユーザーが新しいディスク グループの作成を試みているか、または既存のディスク グループに新しいディスクの追加を試みている。
      エラー スタック:一般的なシステム エラーが発生した:ディスクを追加できない:このホストでは VSAN にライセンスが付与されていない。
    • 状況:サポートされている数を超えるディスク数を指定してユーザーがディスク グループの作成を試みている。あるいは、ユーザーが既存のディスク グループに新しいディスクの追加を試みており、それを加えた合計数がディスク グループあたりのサポートされているディスク数を超える。
      エラー スタック:一般的なシステム エラーが発生した:ディスク数が多すぎる。
    • 状況:エラーがあるディスク グループにユーザーがディスクを追加しようとしている。
      エラー スタック:一般的なシステム エラーが発生した:パーティション テーブルを作成できない。

    回避策:エラーの原因を特定した後、原因を解決してタスクをもう一度実行します。

  • Virtual SAN データストアにホスト ローカル スワップ ファイルとシステム スワップ ファイルを格納できない*
    一般に、システム スワップ ファイルとホスト ローカル スワップ ファイルはデータストアに配置できます。しかし、Virtual SAN データストアはシステム スワップ ファイルとホスト ローカル スワップ ファイルをサポートしません。そのため、システム スワップまたはホスト ローカル スワップのファイルの場所として Virtual SAN データストアを選択できるようにする UI オプションは使用できません。

    回避策:Virtual SAN 環境では、サポートされている他のオプションを使用してシステム スワップ ファイルとホスト ローカル スワップ ファイルを配置します。

  • vSphere HA クラスタ内の Virtual SAN 仮想マシンが、パワーオフされているにもかかわらず、vSphere HA で保護されていると報告される*
    この問題は、ホーム オブジェクトが Virtual SAN データストア上に存在する仮想マシンをパワーオフする際にそのホーム オブジェクトにアクセスできないときに発生する可能性があります。この問題は、このオブジェクトがアクセスできなくなった後で HA マスター エージェントを選択する場合に発生します。

    回避策:

    1. 指定されているストレージ ポリシーにオブジェクトが従っているかを確認し、ホーム オブジェクトが元どおりアクセスできることを確認します。
    2. 仮想マシンをパワーオンし、もう一度パワーオフします。

    ステータスが保護解除に変わります。

  • 再適用操作を開始して正常に完了した後も仮想マシン オブジェクトのステータスが [期限切れ] のままになる*
    新しいストレージ要件に従って既存の仮想マシン プロファイルを編集する場合、関連付けられた仮想マシン オブジェクト(ホームまたはディスク)のステータスが [期限切れ] になることがあります。この問題は、現在の環境が仮想マシン オブジェクトの再構成をサポートできない場合に発生します。 再適用操作を行ってもステータスは変化しません。

    回避策:Virtual SAN クラスタにリソース(ホストまたはディスク)をさらに追加し、 再適用操作をもう一度開始します。

  • Virtual SAN を有効にした後で Virtual SAN にライセンスを割り当てると、Virtual SAN の自動ディスク要求が期待どおりに機能しない*
    Virtual SAN を自動モードで有効にし、その後でライセンスを割り当てると、Virtual SAN のディスク要求が失敗します。

    回避策:モードを 手動に変更し、その後で 自動に戻します。Virtual SAN は正常にディスクを要求します。

  • Virtual SAN ネットワークが分割されていると、vSphere High Availability (HA) が仮想マシンの再起動に失敗する*
    この問題は、Virtual SAN がノード間通信に、クラスタ内の他の VMkernel アダプタと同じサブネット上に存在する VMkernel アダプタを使用する場合に発生します。このような構成は、ネットワーク障害の原因となって Virtual SAN ノード間通信を妨げる可能性があります(vSphere HA ノード間通信には影響を及ぼしません)。

    この状況では、HA マスター エージェントは仮想マシン内の障害を検出する可能性はありますが、仮想マシンを再起動することはできません。この問題は、マスター エージェントが稼働しているホストに、仮想マシンのオブジェクトへのアクセス権がない場合などに発生します。

    回避策:Virtual SAN によって使用されている VMkernel アダプタが、他の目的に使用されている VMkernel アダプタとサブネットを共有していないことを確認します。

  • VM ディレクトリに重複スワップ ファイル (.vswp) が含まれる*   
    Virtual SAN で実行されている仮想マシンがクリーン シャットダウンされず、Virtual SAN ディスクからデータを消去せずに ESXi および vCenter Server を新規にインストールするとこのようなことが発生する可能性があります。結果として、古いスワップ ファイル (.vswp) がクリーン シャットダウンされなかった仮想マシンのディレクトリで見つかります。

    回避策:なし

vCenter Server および vSphere Web Client

  • ESXi ホストを Active Directory ドメインに追加できない*
    権限を割り当てようとしたときに、Active Directory ドメイン名が [ユーザーおよびグループを選択] オプションの [ドメイン] ドッロップダウン リストに表示されないことがあります。また、Active Directory に信頼性のあるドメインがある場合でも、[認証サービス設定] オプションに信頼性のあるドメイン コントローラが表示されないこともあります。

    回避策:
    1. netlogond、lwiod、次に lsassd デーモンを再起動します。
    2. vSphere Client を使用して ESXi ホストにログインします。
    3. 構成 タブで 認証サービス設定 をクリックします。
    4. 更新して信頼性のあるドメインを表示します。
仮想マシンの管理の問題
  • フランス語ローケルで Windows 7 Enterprise 64 ビットのゲスト OS を使用している仮想マシンで、クローン操作中に問題が発生する
    フランス語ロケールで実行中のクローン作成された Windows 7 Enterprise 64 ビット仮想マシンがある場合に、その仮想マシンはネットワークとの接続を切断し、カスタマイズ仕様は適用されません。この問題は、仮想マシンが ESXi 5.1 ホスト上で実行されているときに、その仮想マシンを ESXi 5.5 ホストにクローン作成し、VMware Tools のバージョンを ESXi 5.5 ホストで利用可能な最新のバージョンにアップグレードした場合に発生します。

    回避策:VMware Tools を利用可能な最新バージョンにアップグレードする前に、仮想マシンの互換性を ESXi 5.5 以降にアップグレードしてください。

  • 実行中の仮想マシン上の仮想ディスクのサイズを増やそうとしても、エラーが発生して失敗する
    仮想マシンが実行中の場合に仮想ディスクのサイズを増やそうとしても、次のエラーが発生して失敗することがあります。

    操作は、このタイプのデバイスでサポートされていません。

    このエラーは、ディスクのサイズを 2TB 以上に拡張しようとする場合に発生します。ホット拡張操作では、2TB 以下のディスク サイズへの拡張のみサポートしています。SATA 仮想ディスクは、サイズに関係なく、ホット拡張操作をサポートしていません。

    回避策:仮想ディスクを 2TB 以上に拡張する場合は、仮想マシンをパワーオフしてください。

VMware HA および Fault Tolerance の問題
  • 仮想マシンのフェイルオーバーに vSphere HA クラスタ内の ESX/ESXi 4.0 または 4.1 ホストを選択すると、仮想マシンが期待通りに再起動しない場合がある
    vSphere HA が、仮想マシンが動作していた元のホストとは異なる ESX/ESXi 4.0 または 4.1 ホスト上で仮想マシンを再起動すると、応答されないクエリが発行されます。vSphere Client から手動でクエリに応答するまで、仮想マシンは新しいホスト上でパワーオンされません。

    回避策:vSphere Client からクエリに応答します。または、タイムアウト (デフォルトでは 15 分間) 後に vSphere HA が仮想マシンを異なるホスト上で再起動しようとするのを待つこともできます。ホストが ESX/ESXi バージョン 5.0 以降を実行している場合、仮想マシンが再起動します。

  • vSphere HA クラスタ内で共有ストレージを使用しない vMotion 操作が失敗すると、移行先仮想マシンが予期しないホストに登録される場合がある
    共有ストレージを使用しない vMotion 移行は、移行先仮想マシンが、2 台の仮想マシン間の制御の転送を調整するハンドシェイク メッセージを受け取らなかったために失敗する場合があります。vMotion プロトコルは移行元および移行先の両方の仮想マシンをパワーオフします。移行元と移行先のホストが同じクラスタ内にあり、vSphere HA が有効になっている場合、移行先仮想マシンは vSphere HA によって、vMotion 移行の対象として選択されたのとは異なるホストに登録される可能性があります。

    回避策:移行先仮想マシンを保持し、特定のホストに登録するには、移行先仮想マシンを目的のホストに再配置します。この再配置は仮想マシンをパワーオンする前に行うのが最善です。

サポート対象のハードウェアの問題
  • ファン、電源、電圧および電流センサーのセンサー値が vCenter Server の [ハードウェアのステータス] タブのその他のグループに表示される
    いくつかのセンサー値が、分類されたグループ別ではなく、その他のグループに一覧表示されます。

    回避策:なし。

  • デバッグ DMA (Direct Memory Access)マッピングが有効にされていると I/O メモリ管理ユニット(IOMMU)の異常が表示されることがある
    デバッグ マッピングでデバイスが IOMMU ドメインに配置されると、明示的にマッピングされていないアドレスにデバイス メモリがアクセスする原因となります。古いファームウェアを持つ HP のシステムで、IOMMU の異常が表示されることがあります。

    回避策: HP の Web サイトからファームウェアのアップグレードをダウンロードし、適用します。

    • HP iLO2 コントローラのファームウェアをアップグレードします。
      2011 年 8 月リリースのバージョン 2.07 では、この問題は解決されています。
    • HP Smart Array のファームウェアをアップグレードします。
      2012 年 1 月リリースの HP Smart Array P410 バージョン 5.14 では、この問題は解決されています。

VMware Tools の問題

  • OSP による VMware Tools のインストール中またはアンインストール中にユーザーが強制的にログアウトされる*
    OSP (Operating System Specific Package) を使用してインストールされた RHEL (Red Hat Linux Enterprise) および CentOS 仮想マシンで VMware Tools パッケージのインストール中またはアンインストール中に、現在のユーザーが強制的にログアウトさせられます。この問題は、RHEL 6.5 64 ビット、RHEL 6.5 32 ビット、CentOS 6.5 64 ビット、CentOS 6.5 32 ビットの仮想マシンで発生します。

    回避策:
    • Secure Shell (SSH) を使用して VMware Tools をインストールまたはアンインストールします
      または
    • ユーザーが再びログインして VMware Tools パッケージをインストールまたはアンインストールする必要があります