VMware ESXi 4.1 Update 2 リリース ノート

お問い合わせ
 

ESXi 4.1 Update 2 Installable | 2011 年 10 月 27 日 | ビルド 502767
ESXi 4.1 Update 2 Embedded | 2011 年 10 月 27 日 | ビルド 502767
VMware Tools | 2011 年 10 月 27 日 | ビルド 493255

ドキュメントの最終更新日：2011 年 10 月 27 日

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

新機能

次の情報は VMware ESXi のこのリリースで利用可能な一部の拡張機能について説明しています。

  • 新たにサポート対象となったプロセッサ： ESXi 4.1 Update 2 は、AMD Opteron 6200 シリーズ （Interlagos） および AMD Opteron 4200 シリーズ （Valencia） をサポートしています。

    注：AMD Family 15h プロセッサの場合、ライセンスが適用されていないと、ESX/ESXi 4.1 Update 2 は、コンピューティング ユニット内の各コアを独立したコアとして扱います。ESX/ESXi は、ライセンスのために、各コンピューティング ユニットを 1 つのコアとして扱います。たとえば、8 個のコンピューティング ユニットを持つプロセッサが、16 コアを持つプロセッサと同等の処理能力を ESX/ESXi 4.1 Update 2 で実現できる場合でも、使用するライセンスは 8 個のみです。
  • 新たにサポート対象となったドライバ：   ESXi 4.1 Update 2 は、LSI PERC8 RAID ドライバのアップデート版をサポートしています。

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

ページの先頭へ

ESXi 4.1 の旧リリース

ESXi 4.1 の以前のリリースの機能および既知の問題については、それぞれのリリース ノートに記載されています。旧リリースの ESXi 4.1 のリリース ノートを表示するには、次のいずれかのリンクをクリックしてください。

ページの先頭へ

はじめに

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

『 VMware 製品の相互運用性マトリックス』 （英語版） では、ESXi、VMware vCenter Server、vSphere Client、およびオプションの VMware 製品を含む VMware vSphere コンポーネントの現在のバージョンと旧バージョンとの互換性について、詳細に説明しています。

ESXi および vCenter Server と VDDK との互換性

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

ハードウェア互換性

  • ハードウェア互換性について

    Web ベースの互換性ガイド （英語版） で、ハードウェア互換性リストを入手できます。この Web ベースの互換性ガイドは、すべての VMware 互換性ガイドへのシングル アクセス ポイントとなっており、ガイドを検索したり、検索結果を PDF 形式に保存するオプションがあります。たとえば、このガイドを利用して、使用するサーバ、I/O、ストレージ、およびゲスト OS に互換性があるかどうかを確認できます。

    互換性ガイドのアップデートの通知を受信する場合は、次の URL から登録してください。 RSS フィードへリンクする RSS イメージ
  • vSphere の互換性について

    VMware vSphere 互換性マトリックス （英語版） （ PDF）

インストールおよびアップグレード

ESXi Installable および vCenter Server のインストールおよび構成の詳細な手順については、 『 ESXi Installable および vCenter Server セットアップ ガイド』 を参照してください。 ESXi Embedded および vCenter Server のセットアップの詳細な手順については、 『 ESXi Embedded および vCenter Server セットアップ ガイド』 を参照してください。

ESXi Installable のインストールが正常に終了したあと、または ESXi Embedded を正常に起動したあとに、重要な構成ステップがいくつかあります。特に、 ライセンス、ネットワーク、およびセキュリティの構成のステップは必須です。これらの構成タスクの 説明については、vSphere のドキュメントにある次のガイドを 参照してください。

VirtualCenter 2.x をインストールしている場合、 64 ビット オペレーティング システムへの vCenter Server のインストール、および VirtualCenter データベースの保存の説明については、 『 vSphere アップグレード ガイド』 を参照してください。

ESXi に関連する MIB （Management Information Base） ファイルは、 vCenter Server にはバンドルされていません。vCenter Server に関連する MIB ファイルのみ、 vCenter Server 4.0.x に付属しています。すべての MIB ファイルは、当社の Web サイト （ http://downloads.vmware.com/jp/d/） からダウンロードできます。

VMware Tools のアップグレード

VMware ESXi 4.1 Update 2 には、VMware Tools の最新のバージョンが含まれています。VMware Tools は、 仮想マシンのゲスト OS のパフォーマンスを強化する ユーティリティ スイートです。ESXi の今回のリリースで VMware Tools に関連する解決された問題のリストは、「 VMware Tools の解決した問題」 を 参照してください。

インストール済みの VMware Tools のバージョンを特定するには、「 VMware Tools のビルド番号の確認」 （KB 1003947） を参照してください。

ESXi 4.1 Update 2 へのアップグレードまたは移行

ESXi 4.1 Update 2 は、アップグレートのために次のオプションを提供しています。

  • VMware vCenter Update Manager。ESXi 3.5 Update 5、ESXi 4.0.x、および ESXi 4.1 から ESXi 4.1 Update 1 への直接アップグレードをサポートする vSphere モジュールです。
  • vihostupdate。 コマンドライン ユーティリティです。 ESXi 4.0 および ESXi 4.1 Update 1 から ESXi 4.1 Update 2 への直接アップグレードをサポートします。この ユーティリティには vSphere CLI が必要です。詳細については、『 vSphere アップグレード ガイド』 を参照してください。VEM バンドルを適用するには、 vihostupdate ユーティリティを使用した回避策を実行します。これにより、ESXi 4.1 Update 2 Embedded ホストを Cisco Nexus 1000 AV 2 vDS に追加できます。

ホストを ESXi 4.1 Update 2 へアップグレードするためのサポート対象のアップグレード方法：

アップグレード用配布ファイル
サポート対象のアップグレード ツール
ESXi 4.1 Update 2 へアップグレードするためのサポート対象の方法

ESXi 3.5 Update 5

ESXi 4.0
次のアップデートを含む：
ESXi 4.0 Update 1
ESXi 4.0 Update 2
ESXi 4.0 Update 3

ESXi 4.1

upgrade-from-ESXi3.5-to-4.1_update02.463540.zip
VMware vCenter Update Manager とホスト アップグレード ベースライン

あり

なし

なし
upgrade-from-esxi4.0-to-4.1-update02-463540.zip
  • VMware vCenter Update Manager とホスト アップグレード ベースライン
  • vihostupdate

なし

あり

なし
update-from-esxi4.1-4.1_update02.zip
  • VMware vCenter Update Managerとパッチ ベースライン
  • vihostupdate
なし
なし
あり

注：

  • アップグレード元のバージョンが ESXi 3.5.Update 5 の場合、VMware vCenter Update Manager を使用する方法がサポートされています。詳細については、 『 vSphere アップグレード ガイド』 および 『 VMware vCenter Update Manager 管理ガイド』 を参照してください。
  • アップグレード元のバージョンが ESXi 4.0.x の場合、VMware vCenter Update Manager および vihostupdate コマンドを vSphere CLI. から使用する方法が サポートされています。詳細については、『 VMware vCenter Update Manager 管理ガイド』 を参照してください。
  • アップグレード元のバージョンが ESXi 4.1.x の場合、VMware vCenter Update Manager および vihostupdate コマンドを vSphere CLI から使用する方法が サポートされています。

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

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

ZIP ファイル形式のほかに、ESXi 4.1 Update 2 の Enbedded および Installable リリースがパッチとして配布され、既存の ESXi 4.1 ソフトウェアに適用できます。

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

ESXi410-201110201-SG：ESXi 4.1 ファームウェアをアップデート
ESXi410-201110202-UG：ESXi 4.1Tools をアップデート


ESXi 4.1 Update 2 は、以前リリースされた次のバンドルに含まれる修正をすべて含んでいます。

ESXi410-201010401-SG：ファームウェアのアップデート
ESXi410-201010402-BG：VMware Tools のアップデート

各パッチの内容の詳細については、ダウンロード ページに記載されているドキュメントを参照してください。

解決した問題

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

解決した問題のうち、既知の問題として以前記載されていたものには、† 記号が付加されています。

バックアップ

  • スナップショットの作成中または削除中に仮想マシンがパワーオフすることがある


    • vmx| [msg.disk.configureDiskError] 原因：ファイルのロックに失敗しました
    vmx| Msg_Post:エラー
    vmx| [msg.checkpoint.continuesync.fail] スナップショット作成後に仮想マシンを再起動している間にエラーが発生しました。仮想マシンがパワーオフします。

CIM および API

  • RefreshDatastore API が、オフラインのデータストアで呼び出されると、エラーを表示しない



  • ESXi ホストでメモリ タイプが [不明] と表示される

    •  

  • ESXi 4.1 Update 1 Embedded をインストールしてシステムを再起動すると、ユーザー ワールドのコア ダンプが作成される



    • CoreDump:1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003
    esx41u2 内の qlogic-fchba-provider-410.1.3.5-260247 （バージョン 1.3.5）
  • CIM サーバから IBM Systems Director に無効なアラートが送信される
    ESX ホストでの CIM サーバ （sfcbd） プロセスから IBM Systems Director ソフトウェアに、不明な CPU に関する無効な OMC_IpmiAlertIndication アラートが送信されることがあります。この問題は、IBM LS22 7901-AC1 などの IBM ブレード サーバで発生していました。

    今回のリリースで、この問題は修正されました。
  • vCenter Server は、インストールされているすべての OEM VIB に対して、ProviderEnabled 構成アイテムを 1 つしか表示しない
    OEM プロバイダの VIB を複数インストールしても、vCenter Server はインストールされているすべての OEM プロバイダ VIB に対して、ProviderEnabled 構成アイテムを 1 つ （ /UserVars/CIMoemProviderEnabled） しか表示しません。

    今回のリリースで、この問題は修正されました。OEM プロバイダ VIB を複数インストールすると、ProviderEnabled 構成アイテム /UserVars/CIMoem-<元の名前>が各 VIB に対して作成されるようになりました。各プロバイダを別々に有効または無効にできます。

ゲスト OS

  • vMotion が断続的にタイムアウトのメッセージを表示して失敗する


    • error -1:Failed to launch virtual machine process.Failed to launch peer process.

その他

  • ローカルにないユーザー認証情報を使用して ESX 4.1 ホストにログインできない
    これは、ESX 4.1 の /etc/security/access.confファイルに加えられた変更が原因です。ESX 4.1 の access.confファイルにある -:ALL:ALLエントリによって、NIS またはローカルにないユーザー認証情報が失敗します。

    今回のリリースで、vSphere Client に新しい plugins.vimsvc.shellAccessForAllUsersパラメータが追加されたため、この問題は修正されました。 plugins.vimsvc.shellAccessForAllUsersを trueに設定し、vCenter Server に再接続することにより、ローカルにないユーザー認証情報を現在使用できます。
  • 物理マシンにあるソケット 1 つあたりの CPU コアの数が増加すると、ESXi ホストが特定の作業を完了するまでに、これまでより時間がかかる
    • ホスト マシンの起動
    • HA クラスタへのホストの追加
    • vm-support 診断データの収集


  • vSphere 4.1 を使用して Windows 2003 Service Pack 2 R2 仮想マシンをリセットすると、仮想マシンで障害が発生し、ブルー スクリーンが表示される

    • ゲストの再起動
  • サイズが大きい Syslog メッセージが ESXi ホストに正しく書き込まれない
    ESXi ホストで、約 2,048 バイトを超えるログ メッセージが /var/log/messagesに書き込まれないことがあります。

    今回のリリースで、この問題は修正されました。
  • vCenter 4.1 または vSphere 4.1 から ESX ホストに接続しているときに、データストア ブラウザが NFS ボリューム上のシンボリック リンクを管理できない


  • vpxalogファイルのメッセージが複数の行に分割される

    • vpxa
  • Syslog が構成されていない場合に、vSphere Client でアラート メッセージが表示されない



    • 警告：Syslog が構成されていません。vSphere Client で、[構成] - [ソフトウェア] - [詳細設定] の Syslog オプションを確認してください。
  • コントローラを変更した場合、元のコントローラの LUN 上にあるデータストアが非アクティブになることがある


  • ESXi 4.1 では、hostd プロセスで頻繁に問題が発生する
    タスクと国際化フィルタとで共有しているオブジェクトにより、hostd プロセスで頻繁に障害が発生することがあります。

    今回のリリースで、この問題は修正されました。ESX 4.1 Update 2 の修正により、オブジェクトを共有する代わりに、オブジェクトのクローンを作成します。
  • コマンド vim-cmd を使用してスナップショットを変更すると、特定のスナップショットのツリー構造に問題が発生する
    コマンド vim-cmd vmsvc/snapshot.removeまたは vim-cmd vmsvc/snapshot.revert
    を使用してスナップショットを変更すると、特定のスナップショットのツリー構造からスナップショットを適用しようとするときに、問題が発生します。

    今回のリリースで、この問題は修正されました。現在は、仮想マシンに関連付けられたスナップショットごとに一意の識別子 snapshotId が作成されます。snapshotId は、コマンド vim-cmd vmsvc/snapshot.get <vmid>を実行することにより取得できます。今までと同じコマンドを操作するときに、次の新しい構文を使用できます。

    スナップショットまで戻る場合： vim-cmd vmsvc/snapshot.revert <vmid> <snapshotId> [suppressPowerOff/suppressPowerOn]
    スナップショットを削除する場合： vim-cmd vmsvc/snapshot.remove <vmid> <snapshotId>
  • Remote Tech Support モード （SSH） または Local Tech Support モードを有効にすると、次のような警告メッセージが vCenter Server に表示される

    構成の問題
    ホスト localhost.localdomain の Local Tech Support モードが有効になっています。
    ホスト <server> の Remote Tech Support モード （SSH） が有効になっています

    今回のリリースで、この問題は修正されました。現在は、vCenter Serve で UserVars.SuppressShellWarning パラメータを設定することにより、この警告を無効にできます。
  • 固定パススルー デバイスで構成された仮想マシンをパワーオンできない
    14 個以上の PCIe デバイスで構成された仮想マシンに、1 個でも固定パススルー （FPT） デバイスがある場合は、その仮想マシンをパワーオンできないことがあります。仮想マシンが一度は正常に起動することもありますが、そのあとの再起動時にはパワーオンできません。 vmware.logに次のようなエラー メッセージが記録されます。

    Mar 25 20:56:17.659:vcpu-0| Msg_Post:Error
    Mar 25 20:56:17.659:vcpu-0| [msg.pciPassthru.mmioOutsidePCIHole] PCIPassthru 005:00.0:Guest tried to map 32 device pages (with base address of 0x0) to a range occupied by main memory.This is outside of the PCI Hole.Add pciHole.start = "0" to the configuration file and then power on the VM.

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

ネットワーク

  • vNetwork 分散スイッチを削除すると、ESX ホストでエラー メッセージが表示される


    • vCenter Server 「loganvc29.eng.vmware.com」 で、オブジェクト 「networkSystem-3739」 の 「HostNetworkSystem.UpdateNetworkConfig」 の呼び出しが失敗しました。
    操作に失敗しました。診断レポート：DVS DvsPortset-0 に 1 個のシャドウ ポートまたはゾンビ ポートがあります。
  • e1000 vNIC が送信する最初のパケットに無効な MAC アドレスがある

    • 00:00:00:xx:xx:xx があります。
  • vDS （vNetwork 分散スイッチ） で構成された ESXi ホストが vCenter Server から切断され、再接続を複数回試行しても再接続できない

    • 制限を超えました
  • VLAN が be2net または ixgbe ドライバを使用する物理 NIC で構成されていると、ネットワーク接続ができない
    物理 NIC 用に be2net または ixgbe ドライバがインストールされている場合、vNetwork 分散スイッチで、dvUplink ポート グループに単一の VLAN、または VLAN ID 範囲を構成すると、その単一の VLAN に対するネットワーク接続、または VLAN ID 範囲の最高値の VLAN ID に割り当てられている VLAN に対するネットワーク接続ができないことがあります。

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

セキュリティ

  • SFCB での整数のオーバーフローに関する問題の解決

    今回のリリースで、SFCB での整数のオーバーフローに関する問題は修正されました。この問題は、 /etc/sfcb/sfcb.cfg内の httpMaxContentLength がデフォルト値から 0 に変更されると発生していました。この整数のオーバーフローにより、リモートの攻撃者が Content-Length HTTP ヘッダに大きい整数を挿入して、サービス拒否 （ヒープ メモリの破損） を発生させたり、恣意的なコードを実行したりする危険性がありました。

    CVE （Common Vulnerabilities and Exposures） プロジェクト （cve.mitre.org） は、この問題を CVE-2010-2054 として公表しています。
  • pam RPM のアップデート

    今回のリリースで、pam RPM が pam_0.99.6.2-3.27.5437.vmw にアップデートされ、PAM モジュールにあった複数のセキュリティ上の問題が修正されました。

    Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2010-3316、CVE-2010-3435、および CVE-2010-3853 として公表しています。
  • 2 つの異なるクラスタにある ESX 4.1 ホスト間でコールド移行ができない


  • openssl パッケージのアップデート
     
    バグの概要：今回のリリースで、openssl パッケージが openssl098e から openssl-0.9.8e.12.el5_5.7 にアップデートされ、2 つのセキュリティ上の問題が修正されました。Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2008-7270 および CVE-2010-4180 として公表しています。
  • NSS および NSPR ライブラリのアップデート
     
    今回のリリースで、NSS （Network Security Services） ライブラリおよび NSPR （Netscape Portable Runtime） ライブラリのソース ファイルにあるライセンス テキストが更新され、MPL （Mozilla Public License） でなく LGPL （Lesser General Public License） 2.1 の条項に基づいて、これらのパッケージを配布するようになりました。また、NSS および NSPR は nspr-4.8.6-1 および nss-3.12.8-4 にアップデートされ、複数のセキュリティ上の問題が解決しています。

    Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2010-3170 および CVE-2010-3173 として公表しています。
  • libuser RPM のアップデート
      
    今回のリリースで、libuser RPM がバージョン 0.54.7-2.1.el5_5.2 にアップデートされ、セキュリティ上の問題が修正されました。Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、この問題を CVE-2011-0002 として公表しています。
  • openldap RPM および openldap-client RPM のアップデート
     
    今回のリリースで、openldap RPM および openldap-client RPM が 2.3.43.12.el5_5.1 および 2.3.43-12.el5_6.7 にアップデートされ、OpenLDAP ライブラリにあった複数のセキュリティ上の問題が修正されました。

    Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2010-0211、CVE-2010-0212、および CVE-2011-1024 として公表しています。
  • userworld glibc のアップデート

    バグの概要：今回のリリースで、userworld glibc が 2.5-58.el5_6.2 にアップデートされ、複数のセキュリティ上の問題が修正されました。
     
    Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2011-0536、CVE-2010-0296、CVE-2011-1071、および CVE-2011-1095 として公表しています。
  • mpt2sas ドライバのアップデート

    今回のリリースで、mpt2sas ドライバがアップデートされ、ローカル ユーザー権限のエスカレーションの危険性があった複数のセキュリティ上の問題が修正されました。

    Common Vulnerabilities and Exposures プロジェクト （cve.mitre.org） は、これらの問題を CVE-2011-1494 および CVE-2011-1495 として公表しています。
  • Intel e1000 および e1000e ドライバのアップデート

    今回のリリースで、Intel PRO/1000 アダプタ向けの e1000 および e1000e Linux ドライバにあったセキュリティ上の問題が修正されました。この問題により、リモートの攻撃者がパケット フィルタをバイパスし、操作されたパケットが送信される危険性がありました。

    CVE （Common Vulnerabilities and Exposures） プロジェクト （cve.mitre.org） は、この問題を CVE-2009-4536 として公表しています。

サーバ構成

  • リモート ホストにアクセスできない場合、Syslog 操作でエラーが発生することがある

    • syslogd
    syslogd
  • ESXi で、パスワード設定を編集するために /etc/pam.d/system-authファイルを変更しても、システムを再起動すると、その変更が反映されていない
    /etc/pam.d/system-authファイルは、ユーザーが編集できません。そのため、 /etc/pam.d/system-authファイルを変更しても、システムを再起動すると、その変更は反映されません。現在は、 /etc/pam.d/passwdファイルを変更することにより、パスワード設定を編集できます。

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

ストレージ

  • ESX 4.0 で QLogic QME2472 ホスト バス アダプタ （HBA） を使用している場合、FalconStor ホスト バス アダプタのフェイルオーバーによって APD （All Paths Down） 状態になる


  • ESX/ESXi ホストが、アップグレード後に NC382i アダプタの iSCSI 機能を検出できない


  • ESX/ESXi ホストでファイバ チャネル スイッチを再起動すると、スイッチのリンク状態がリストアされない


  • ESX ホストに接続された 3par アレイのファイバ チャネル論理ユニット番号 （LUN） のターゲット情報が vSphere に表示されない


  • ESX/ESXi で、Dell MD36xxi ストレージ アレイにある Raw デバイス マッピング ファイルを仮想マシンが検出できない。


    • KB 1037925
  • アップグレードされた VMFS ボリュームのスナップショットは、ESX 4.x ホストでのマウントに失敗する
    ブロック サイズが 1MB より大きく、VMFS2 からアップグレードされた VMFS3 ボリュームのスナップショットは、ESX 4.x ホストへのマウント処理に失敗することがあります。検出された VMFS スナップショット ボリュームを一覧表示する esxcfg-volume -lコマンドは失敗し、次のようなエラー メッセージが表示されます。

    ~ # esxcfg-volume -l
    エラー：デバイスにファイル システムがありません

    今回のリリースで、この問題は修正されました。VMFS2 からアップグレードされた VMFS3 ボリュームのスナップショットを、マウントや再署名できるようになりました。
  • LUN のスキャン時に、QLogic ファイバ チャネルの筐体内ドライバがある ESX ホストで障害が発生し、紫色の診断画面が表示される


  • システムを再起動すると、デバイスの [有効な非最適化状態のパスの使用] （useANO） 設定が保持されない


  • ESXi 4.1 が Dell PowerEdge システムで SATA 内部エラー メッセージを記録し続ける


    • cpu2:4802)<6>ata1:soft resetting port
    cpu1:4802)<6>ata1:SATA link up 1.5 Gbps (SStatus 113 SControl 300)
    cpu0:4802)<6>ata1.00:configured for UDMA/100
    cpu0:4802)<6>ata1:EH complete
    cpu0:4802)<3>ata1.00:exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
    cpu0:4802)<3>ata1.00:(irq_stat 0x40000001)
    cpu0:4802)<3>ata1.00:tag 0 cmd 0xa0 Emask 0x40 stat 0x51 err 0x24 (internal error)

  • aic79xx ドライバを使用してアクセスするテープ ドライブに接続された ESX ホストで障害が発生する
    aic79xx ドライバを使用してアクセスするテープ ドライブに接続された ESX ホストで、解放されたメモリ領域にドライバがアクセスしようとすると、そのホストで障害が発生し、紫色の画面に次のようなエラー メッセージが表示される場合があります。

    Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000

    今回のリリースで、この問題は修正されました。
  • ESX/ESXi ホストに接続された論理ユニット番号 （LUN） のパスのステータスが、ESX/ESXi ホストに再接続してもアップデートされない


サポート対象のハードウェア

  • Linux 仮想マシンでは、ESX ホストに接続された MAI KEYLOK II USB デバイスにアクセスできない


アップグレードおよびインストール

  • ESX 4.1 Update1 以前のリリースの新規インストール中に、ブロック サイズまたは VMFS ボリュームのサイズを変更できない
    ESX/ESXi 4.1 Update1 以前のリリースを詳細な設定をしてインストールするとき、パーティションのサイズや VMFS ブロック サイズを変更するオプションがありません。デフォルトでは、VMFS ボリュームはフル パーティションで作成されます。
    ESX/ESXi では、GUI、テキスト、およびキックスタートのインストール中に VMFS ブロック サイズを指定できるようになり、この問題は修正されました。

    今回のリリースで、この問題は修正されました。
  • ESX を 3.5 から 4.1 にアップグレードすると、NetWare 5.1 Service Pack 8 仮想マシンで CPU の使用率が増加する


  • LSI SAS Mezzanine コントローラ （LSI 1064E） を搭載した日立 BS320 AC51A3 ブレード サーバでは、ESX 4.1 のインストールに失敗する
    この問題は、ESX 4.1 で導入された試験的な機能である、FireWire シリアル バス スキャンが原因で発生します。VMware 製品の試験的な機能に対する当社の公式な姿勢については、 https://www.vmware.com/support/policies/experimental.html を参照してください。

    今回のリリースで、FireWire を無効にすることにより、この問題は修正されました。ESX 4.1 以降では、FireWire は正式にサポートされません。

  • キックスタート ファイルで --fstype コマンドを指定すると、ESXi 4.1 U2 のスクリプトによるインストール中に警告メッセージが表示される
    ESXi 4.1 の以前のリリースでは、ESXi のスクリプトによるインストールでコマンド --fstypeを選択して、その値として vmfs3のみを指定できました。今回のリリースからは、 --fstypeコマンドがスクリプトによるインストールから削除されました。現在はスクリプトによるインストール中にキックスタート ファイルに --fstypeコマンドを指定すると、次のような警告メッセージが表示されます。
     
    警告：NFS：<ホスト名>/ks.cfg:line xxx：コマンド 「part」 に対する引数 「--fstype」 に値は不要です
     
    ただし、インストールは正常に完了します。

仮想マシンの管理

  • ESX 3.5 または 4.0 の場合、MOB （Managed Object Browser） を使用して ESX ホストを参照すると、CPU とメモリの予約の値が 「未設定」 と表示される

    • [virtualMachineConfigSummary.cpuReservation][virtualMachineConfigSummary.memoryReservation]


  • Windows 2008 R2 ゲスト OS を実行している仮想マシンのホット クローニングをカスタマイズすると、障害が発生し、クローンの仮想マシンが再起動され続けるWindows 2008 R2 ゲスト OS のホット クローニングをカスタマイズすると、障害が発生してエラー メッセージ [ 自動チェックなし] を出力し、仮想マシンが再起動され続けます。

    今回のリリースで、この問題は修正されました。
  • vCenter では、クローン作成された Windows 2000 Professional 仮想マシンが、Windows 2000 Professional ではなく Windows 2000 をゲスト OS として vmxファイルに出力する




  • ESX/ESXi 4.0 では、PerfQuerySpec にある maxSample パフォーマンス統計プロパティに誤った値が表示される

    •  
  • パワーオフ状態の仮想マシン用にプロビジョニングされた領域が、vSphere Client で誤って表示される


  • スナップショットを削除すると、VMware hostd 管理エージェントで障害が発生する
    仮想マシンのスナップショットを削除すると、VMware hostd 管理エージェントで障害が発生して、次のようなバックトレースを表示することがあります。

    [2010-02-23 09:26:36.463 F6525B90 error 'App']
    Exception:Assert Failed:"_config != __null && _view != __null" @ bora/vim/hostd/vmsvc/vmSnapshot.cpp:1494

    これは、仮想マシンの構成ファイルと同じディレクトリにある <仮想マシン名>-aux.xmlが空のためです。ホスト上に仮想マシンが作成または登録されていると、 <仮想マシン名>-aux.xmlファイルの内容が読み取られ、 _viewオブジェクトが配置されます。XML ファイルが空の場合、 _viewオブジェクトは配置されません。その結果、スナップショットの統合時にエラーが発生します。

    今回のリリースで、この問題は修正されました。
  • MIB ファイルを使用して SNMP クエリが送信されると、ESX ホストが応答しなくなる
    ホストに組み込まれた SNMP エージェントを有効にし、 VMWARE-VMINFO-MIB.mibMIB ファイルを使用して、移行、クローン作成、作成、または削除しようとしている仮想マシンに SNMP クエリを送信すると、ESX ホストが応答しなくなることがあります。

    今回のリリースで、この問題は修正されました。
  • 仮想ディスクの [IOPs の制限] の値を変更すると、スナップショットで実行している仮想マシンが応答しなくなることがある
    スナップショットを使用して実行している仮想マシン、またはスナップショットを作成している仮想マシンで、仮想ディスクの [IOPs の制限] の値を [制限なし] からほかの値に変更すると、数秒間隔で仮想マシンが応答しなくなることがあります。  

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

vMotion および Storage vMotion

  • 複数の仮想マシンで vMotion を実行すると、ESX ホストが警告メッセージ [ メモリ不足] を表示する


    • WARNING:vmklinux26:AllocPages:gfp_mask=0xd4, order=0x0, vmk_PktSlabAllocPage returned 'Out of memory' in the vmkernel log during vMotion
  • HA （High Availability） や DRS （Distributed Resource Scheduler） をメンテナンス モードにしようとするか、vMotion の操作を実行しようとすると、vMotion が [ メモリ不足] のエラー メッセージを出力して失敗する
    vCenter 4.1 または vSphere 4.1 を使用して、vMotion を同時に実行するか、DRS が有効なクラスタに含まれる 4.1 ホストをメンテナンス モードにしようとすると、仮想マシンの退避に失敗して、次のようなエラー メッセージを出力します。

    ホスト <> への移行がエラー 「メモリ不足」 （195887124） で失敗しました。vMotion 移行 [184468762:1286284186972455] の書き込み機能が失敗しました。

    今回のリリースで、この問題は修正されました。
  • スワップ ファイルがロックされているために vMotion に失敗する


VMware Tools

  • Windows NT 4.0 オペレーティング システムの仮想マシンに VMware Tools をインストールすると、エラー メッセージが表示される
    Windows NT 4.0 オペレーティング システムの仮想マシンに VMware Tools をインストールすると、正常に実行されます。しかし、vSphere Client は VMware Tools のステータスを次のように表示します：[ VMware Tools：旧バージョン]。
    今回のリリースで、この問題は修正されました。
  • 一部の Linux ゲスト OS で /tmp内のフォルダがいくつか削除されているために、VMware Tools のアップグレードに失敗する
    一部の Linux ディストリビューションは /tmp内のファイルやフォルダを定期的に削除しているため、VMware Tools の ESX 3.5 から ESX 4.0 へのアップグレードに失敗することがあります。VMware Tools の自動アップグレードには、 /tmp内のこのディレクトリが必要です。
    今回のリリースで、この問題は修正されました。
  • VMware Tools をアップグレードしたあと、Windows 仮想マシンのネットワーク接続が失われる
    HGFS （Host Guest File System） がインストールされている VMware Tools を ESX 3.5 から ESX 4.x にアップグレードすると、HGFS ドライバが適切にアンインストールされないことがあります。その結果、Windows 仮想マシン ネットワークの [ネットワーク接続] - [詳細] - [詳細設定] にある [プロバイダの順序] タブに誤った情報が表示され、仮想マシンのネットワーク接続が失われる場合があります。  

    今回のリリースで、この問題は修正されました。旧バージョンの HGFS ドライバと関連するすべてのレジストリ エントリは、アップグレード中に適切にアンインストールされるようになりました。
  • Windows 2008 R2 仮想マシンの静止スナップショットを作成すると、仮想マシンの追加ディスクで障害が発生する
    • Windows 2003
    • Windows Vista
    • Windows 2008
    • Windows 7


  • 1 つのアプリケーションが複数のスレッドから WNetAddConnection2API を同時に呼び出すと、Windows HGFS プロバイダが原因となってデッドロックが発生する

    • WNetAddConnection2WNetCancelConnection
  • ESX 4.1 U1 上の最新のカーネルのある RHEL3 に VMware Tools をインストールすると、VMXNET ネットワーク インターフェイス カードを使用できなくなる

    • vmxnetvsocket
    回避策
  • 仮想ハードウェアをアップグレードしたあと、Windows ゲスト OS が NIC デバイスのステータスを誤って表示する


    • このハードウェア デバイスはコンピュータに接続されていません （コード 45）
    回避策

  • RHEL 2.1 仮想マシンに VMware Tools をインストールすると、処理に失敗してエラー メッセージが表示される

    • vmware-install.pl
    カーネル用の新しい initrd 起動イメージを作成しています。/tmp/vmware-fonts2/system_fonts.conf のオープン エラー。実行は中止されました。
  • VMware Tools をインストールしたあと Linux 仮想マシンを再起動すると、無関係なエラーが表示される
    Linux 用の VMware Tools をインストールしたあとゲスト OS を再起動すると、Linux カーネル （udev） 用のデバイス マネージャで次のような無関係なエラーが表示されることがあります。

    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'ATTRS{model}'
    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]:add_to_rules:unknown key 'AT

    今回のリリースで、この問題は修正されました。Linux 用の VMware Tools インストーラはデバイスを検出し、システム特有のルールのみを記述するようになりました。
  • Linux 仮想マシンでは、VMware Tools のインストール中に構成ファイルのエントリが上書きされる
    Linux 仮想マシンで VMware Tools をインストールまたはアップデートすると、構成ファイル （Redhat および Ubuntu の場合は /etc/updated.conf ファイル、SuSE の場合は /etc/sysconfig/locate など） 内にあるサードパーティ製の開発ツールによって作成されたエントリが、VMware Tools インストーラによって上書きされることがあります。これによって、これらの仮想マシンで updatedb を実行する cron ジョブに影響が出る可能性があります。

    今回のリリースで、この問題は修正されました。
  • SUSE Linux Enterprise Server 10 Service Pack 3 x86 仮想マシン上で、VMware Tools をインストールまたはアップグレードすると、無効な CUPS （Common UNIX Printing System） サービスが自動的に開始される


  • SUSE Linux Enterprise 10 の場合
    • chkconfig --level 2345 cups off
    chkconfig --level 2345 cupsrenice off


    service cups status
    chkconfig -l|grep -i cups


  • Red Hat Enterprise Linux 5 の場合

    • chkconfig --level 2345 cups off
    system-config-services
  • Linux ゲスト OS で、キュー ペアが切り離されると、VMCI （Virtual Machine Communication Interface） ソケットが応答しなくなる
    • 仮想マシンを使用できない。
    • ゲスト OS で、バスメモリの無効化に失敗したとレポートされている。

    •  


    ピアにより接続がリセットされました
  • カーネルを切り替えている最中は、VMware Tools のカーネル モジュールがロードされない
    VMware Tools をインストールしてカーネルを切り替えている場合は、vsock および vmmemctl モジュールは起動時にロードされません。dmesg コマンドを実行するか、不適切なカーネルのモジュールを手動でロードしようとすると、次のエラー メッセージが表示されます。

    vmmemct：シンボル module_layout のバージョンが一致していません。
    vsock：シンボル module_layout のバージョンが一致していません。

    今回のリリースで、この問題は修正されました。ESX 4.1 Update 2 の修正では、カーネルの切り替え中に、VMware Tools のモジュールを再構築します。
  • レジストリー キーを使用して、仮想メモリの割り当て順序を上位から下位に強制すると、64 ビット Windows 仮想マシン上の VMware Tools サービス （vmtoolsd） で障害が発生する



  • オペレーティング システムの名称が長い Linux ゲストに VMware Tools をインストールしたあと、VMware Tools サービス （vmtoolsd） で障害が発生することがある


  • VMware Tools のインストール後、X11 の構成が変更される

    SLES （SuSe Linux Enterprise Server） 仮想マシンに VMware Tools をインストールしたあと、X11 の構成が変更されます。その結果、キーボードのロケールの設定が Albanian に変更され、マウスとモニターの構成が空白になるため、VNC で障害が発生します。

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

 

ページの先頭へ

既知の問題

このセクションでは、次の内容に関するこのリリースの既知の問題について説明しています。

既知の問題で以前記載されていなかったものには、* 記号が付加されています。

CIM および API

  • ESX 4.1 Update 2 にアップグレードしたとき、構成アイテム /UserVars/CIMoemProviderEnabled が削除されない *
    回避策：次のコマンドを実行して、 /UserVars/CIMoemPrividerEnabledを削除してください。

    esxcfg-advcfg-L /UserVars/CIMoemProviderEnabled

  • ESX 4.1 Update 2 にアップグレードすると、デフォルトで OEM ProviderEnabled 構成アイテムが有効になる *
    回避策：
    1. 次のコマンドを実行して、OEM プロバイダを無効にします。
      esxcfg-advcfg -s 0 /UserVars/CIMoem-<元の名前>ProviderEnabled
    2. 次のコマンドを実行して、 sfcbdサービスを再起動します。
        /etc/init.d/sfcbd-watchdog restart
  • SFCC ライブラリが、生成される XML ファイルに SetBIOSAttribute メソッドを設定しない
    SFCC （Small Footprint CIM Client） で、SFCC ライブラリが     CIM_BIOSService クラスの SetBIOSAttribute メソッドを実行しようとすると、次のエラーを含む XML ファイルが SFCC から返されます：[ ERROR CODE="13" DESCRIPTION="The value supplied is incompatible with the type" ]。この問題は、生成される XML ファイルにメソッドのパラメータの型を設定することが、古い SFCC ライブラリでサポートされていない場合に発生します。この問題が原因で、SetBIOSAttribute メソッドを呼び出すことができません。ESXi 4.1 ホストの SFCC ライブラリは、生成されたソケット ストリーム XML ファイルに、メソッドのパラメータの型を設定しません。

    推奨するいくつかの回避策を次に示します。
    • IBM 社による CIMOM バージョンのアップデートを適用する
    • 今回の修正を使用して、IBM 社からのパッチを CIMOM バージョンに適用する
    • IBM 社が自社バージョンの SFCC ライブラリを使用する

ゲスト OS

  • メモリが 3GB 超にホットアドされると、ゲスト OS が応答しなくなることがある
    RedHat 5.4 の 64 ビット ゲスト OS を IDE デバイスが接続されている状態で起動し、メモリが 3GB 未満から 3GB 超にホットアドされると、ゲスト OS が応答しなくなる場合があります。

    回避策：メモリのホットアドを使用して、仮想マシンのメモリ サイズを 3072MB 以下から 3072MB 超に変更しないでください。仮想マシンをパワーオフしてこの再構成を行います。ゲスト OS がすでに応答していない場合は、仮想マシンを再起動します。この問題は、オペレーティング システムの稼動中に 3GB マークを超える場合にのみ発生します。
  • Windows NT ゲスト OS をハードウェア バージョン 7 の仮想マシンを使用してインストールするとエラーが発生する
    ハードウェア バージョン 7 の仮想マシンで Windows NT 3.51 をインストールすると、インストール プロセスが応答しなくなります。これは Windows NT 3.51 バージョンの起動時にブルー スクリーンが表示された直後に発生します。これは Windows NT 3.51 カーネルの既知の問題です。ハードウェア バージョン 7 の仮想マシンは 34 個を超える PCI バスを搭載していますが、Windows NT カーネルがサポートするホストの最大 PCI バス数は 8 個です。

    回避策：これが新規インストールの場合は、既存の仮想マシンを削除して新しい仮想マシンを作成します。仮想マシンの作成時にはハードウェア バージョン 4 を選択してください。ハードウェア バージョンを変更するには、[新規仮想マシン] ウィザードを使用してカスタム パスを選択する必要があります。ハードウェア バージョン 4 の仮想マシンを作成し、それをハードウェア バージョン 7 にアップグレードした場合は、VMware vCenter Converter を使用して仮想マシンをハードウェア バージョン 4 にダウングレードします。
  • VMware Tools OSP パッケージを SLES 11 ゲスト OS にインストールすると、パッケージがサポートされていないことを示すメッセージが表示される
    VMware Tools OSP パッケージを SUSE Linux Enterprise Server 11 ゲスト OS にインストールすると、次のようなエラー メッセージが表示されます：[     次のパッケージはベンダーによってサポートされていません ]。

    回避策：メッセージは無視してかまいません。OSP パッケージには、ベンダーのサポート対象であることを示すタグは含まれません。ただし、パッケージはサポートされています。
  • VMware カーネルのモジュールのコンパイルが、実行中のカーネルでのみサポートされる
    現在、VMware では、カーネル モジュールのコンパイルを現在実行中のカーネルに対してのみサポートしています。

    回避策：カーネルを起動してから、そのカーネルのモジュールをコンパイルします。

  • 仮想マシンをデプロイしてパワーオンしたあと、ネットワーク接続がなくなる
    [カスタマイズ] ウィザードを使用して作成した仮想マシンを ESXi ホストにデプロイしてパワーオンすると、その仮想マシンのネットワーク接続が失われる場合があります。

    回避策：    ESXi ホストに各仮想マシンをデプロイしたあと、[仮想マシンのプロパティ] ウィンドウで [パワーオン時に接続] オプションを選択し、そのあと仮想マシンをパワーオンします。  

その他

  • resxtop または esxtop を長期間実行するとメモリの問題が発生する場合がある
    resxtop または esxtop を実行すると、監視対象の ESXi ホストの状況によってはメモリの使用量が徐々に増加する場合があります。つまり、2 つの表示間のデフォルトの遅延時間が 5 秒であれば、 resxtop または esxtop は約 14 時間後にシャットダウンされます。

    回避策： -nオプションを使用して繰り返し処理の総数を変更できますが、 resxtopはデータが必要な場合にのみ実行するようにしてください。 resxtopまたは esxtopの統計情報を長期間にわたり収集する必要がある場合は、1 つの resxtopインスタンスまたは esxtopインスタンスを数週間または数か月実行するのではなく、 resxtopまたは esxtopを定期的にシャットダウンしてから再起動してください。
  • vSphere Client のグループ ID の文字数が vCLI のグループ ID の文字数より短い
    vSphere Client を使用してグループ ID を指定する場合、9 文字しか使用できません。これに対して、     vicfg-user vCLI を使用してグループ ID を指定する場合は、最大 10 文字まで指定できます。

    回避策：なし

  • esxcfg-pciid コマンドを実行すると、警告メッセージが表示される
    esxcfg-pciidコマンドを実行してイーサネット コントローラおよびアダプタを一覧表示しようとすると、次のような警告メッセージが表示されることがあります。
    Vendor short name AMD Inc does not match existing vendor name Advanced Micro Devices [AMD] （ベンダーの省略名 AMD Inc が既存のベンダー名 Advanced Micro Devices [AMD] と一致しません）
    kernel driver mapping for device id 1022:7401 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7409 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7411 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7441 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown

    この問題は、プラットフォームのデバイス記述子ファイルとドライバ固有の記述子ファイルの両方に、同じデバイスの記述があると発生します。

    回避策：この警告メッセージは無視してかまいません。
  • ESXi 4.1 Update 1 Embedded ホストを Cisco Nexus 1000V Release 4.0(4)SV1(3a) に追加できない
    vCenter Server から ESXi 4.1 Update 1 Embedded ホストを Cisco Nexus 1000V Release 4.0(4)SV1(3a) に追加できないことがあります。

    回避策
    ESXi 4.1 Update 1 Embedded ホストを Cisco Nexus 1000V Release 4.0(4)SV1(3a) に追加するには、 vihostupdateユーティリティを使用して ESXi ホストに VEM バンドルを適用します。
    次の手順を実行して、ESXi 4.1 Update 1 Embedded ホストを追加します。
    1. Cisco Nexus 1000V Release 4.0(4)SV1(3a) をセットアップします。
    2. vCenter Server をセットアップします。この際、VUM プラグインもインストールします。
    3. Cisco Nexus 1000V Release 4.0(4)SV1(3a) を vCenter Server に接続します。
    4. データ センターを作成し、ESXi 4.1 Update 1 Embedded ホストを vCenter Server に追加します。
    5. vSphere CLI から次のコマンドを実行して、ESXi 4.1 Update 1 と互換性のある AV.2 VEM ビットを ESXi ホストに追加します。
      vihostupdate.pl --server <サーバ IP> -i -b <VEM オフライン メタデータ パス>
      次のプロンプトが vCLI に表示されます。
      Enter username: （ユーザー名の入力）
      Enter password: （パスワードの入力）
      Please wait patch installation is in progress ... （パッチのインストール中です。しばらくお待ちください）
    6. パッチのアップデート後、vCenter Server の [ネットワーク ビュー] に移動し、Cisco Nexus 1000V Release 4.0(4)SV1(3a) にホストを追加します。  
    7. ESXi 4.1 Update 1 ホストが Cisco Nexus 1000V Release 4.0(4)SV1(3a) に追加されていることを確認します。

ネットワーク

  • 物理 NIC で制御操作を実行しているときに、ネットワーク接続およびシステムに障害が発生する
    複数の X-Frame II s2io NIC で同じ PCI-X バスを共有している場合、物理 NIC 上で MTU の変更などの制御操作を実行すると、ネットワーク接続が失われたり、システムに障害が発生したりすることがあります。

    回避策：同じ PCI-X バスを共有している複数の X-Frame II s2io NIC をスロットに置かないようにします。このような構成が必要な場合、仮想マシンがネットワーク I/O を実行している間は、物理 NIC で制御操作を実行しないようにしてください。
  • LRO が有効に設定されているトラフィック転送中の仮想マシン上で、TCP パフォーマンスが低下する場合がある
    一部の Linux モジュールは LRO で生成されたパケットを処理できません。このため、Linux ゲスト OS を実行しているトラフィック転送中の仮想マシンでは、VMXNET2 または VMXNET3 デバイスの LRO を有効に設定すると、TCP のパフォーマンスが低下する場合があります。これらのデバイスでは、LRO はデフォルトで有効に設定されます。

    回避策：Linux ゲスト OS を実行しているトラフィック転送中の仮想マシンでは、VMXNET2 または VMXNET3 の Linux ドライバのモジュール ロード タイム パラメータに disable_lro=1 が含まれるように設定します。
  • ホストが 1,016 を超える dvPort を vDS 上で使用すると、メモリの問題が生じる
    1 つのホストが vDS 上で使用できる dvPort の最大数は 4,096 ですが、ホストに対する dvPort の数が 1,016 に近づくと、メモリの問題が生じ始める場合があります。この問題が生じると、vDS に仮想マシンまたは仮想アダプタを追加することはできません。

    回避策：vDS 上で、ホストあたりの dvPort の最大数が 1,016 になるように設定します。
  • VMXNET3 NIC を再構成すると、仮想マシンが起動することがある
    Wake-on-LAN が有効になっている場合、仮想マシンのスリープ中に VMXNET3 NIC を再構成すると、仮想マシンがレジュームされます。

    回避策：VMXNET3 vNIC を再構成したあと （たとえば、ホット アドやホット リムーブを実行したあと）、仮想マシンを手動でスリープ モードに戻します。

ストレージ

  • NIC の論理デバイス名が長い場合、NIC を経由した iSCSI を構成できない
    vSphere コマンドライン インターフェイス （vCLI） からコマンド     esxcli swiscsi nic add -n を実行すると、VMkernel NIC の論理デバイス名が 8 文字を超える場合、VMkernel NIC を経由した iSCSI 操作を構成できません。8 文字を超える vmnic 名および vmknic 名を使用するサードパーティ製 NIC ドライバは、ESXi ホストの iSCSI ポート バインド機能と連動できません。リモート コマンド ライン インターフェイスに例外エラー メッセージが表示されることがあります。vCLI から esxcli swiscsi nic list、esxcli swiscsi nic add、esxcli swiscsi vmnic list などのコマンドを実行しても、サードパーティ製ドライバが作成した長い vmnic 名を処理できないため失敗します。

    回避策：サードパーティ製 NIC ドライバでは、iSCSI ポート バインドの要件を満たすために、vmnic 名を 8 バイト以下に制限する必要があります。
    注：iSCSI ポート バインドにドライバを使用していない場合は、名前に最大 32 バイト使用できます。また、これは、ポート バインド機能がない iSCSI とも連動します。

  • var/log/messages ログ ファイルに大量のストレージ関連のメッセージがある
    ストレージ デバイスへの複数の物理パスを使用してホスト上で ESXi を起動すると、VMkernel ログ ファイルに、次のようなストレージ関連のメッセージが大量に記録されます。
    Nov 3 23:10:19 vmkernel:0:00:00:44.917 cpu2:4347)Vob:ImplContextAddList:1222:Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path:%s) failed:VOB context overflow
    ストレージの再スキャン中に、システムによって同様のメッセージがログに記録される場合があります。これらのメッセージ作成は予想される動作であり、何らかの障害を示しているわけではありません。これは無視してかまいません。

    回避策：メッセージを表示しないようにする場合は、ログ記録をオフにしてください。
  • 共有 LUN で永続的な予約の競合が生じると、ESXi ホストの起動に時間がかかる場合がある
    SAN 上で LUN を共有しているホストを起動しているときに、非常に時間がかかる場合があります。これは、LUN SCSI 予約の間に競合が生じていることが原因である可能性があります。

    回避策：この問題を解決して、起動処理スピードを上げるには、 Scsi.CRTimeoutDuringBootパラメータを 10000 に設定し、起動時の同期コマンドに対するタイムアウトを 10 秒に変更します。

    vSphere Client のパラメータを変更するには、次の手順を実行します。
    1. vSphere Client インベントリ パネルで、ホストを選択し、[構成] タブをクリックしてから、[ソフトウェア] の [詳細設定] をクリックします。    
    2. [SCSI] を選択します。  
    3. Scsi.CRTimeoutDuringBootパラメータの値を 10000 に変更します。

サポート対象のハードウェア

  • allowInterleavedNUMANodes 起動オプションが [FALSE] である場合、ESXi が起動に失敗することがある
    MAX 5 エクステンションが適用された IBM eX5 ホストでは、ESXi が起動に失敗し、     SysAbort メッセージが表示されます。この問題は、 allowInterleavedNUMANodes 起動オプションが [TRUE] に設定されていない場合に発生することがあります。このオプションのデフォルト値は [FALSE] です。

    回避策：     allowInterleavedNUMANodes 起動オプションを [TRUE] に設定します。ESXi ホストの起動オプションを設定する方法の詳細については、KB 1021454 （ http://kb.vmware.com/kb/1021454） を参照してください。
  • HP ProLiant DL370 G6 で PCI デバイスのマッピング エラーが発生する
    I/O 処理を HP ProLiant DL370 G6 サーバで実行すると、紫色の画面が表示されるか、Lint1 Interrupt や NMI に関するアラートが表示されることがあります。HP ProLiant DL370 G6 サーバは、2 つの IOH （Intel I/O Hub） を備え、ACPI DMAR （Direct Memory Access Remapping） 構造定義には BIOS の不具合があります。このため、一部の PCI デバイスが間違った DMA 再マッピング ユニットの下に記述される場合があります。このように誤って記述された PCI デバイスが DMA アクセスを行うと、IOMMU に障害が発生し、そのデバイスは I/O エラーを受け取ります。デバイスによっては、この I/O エラーにより、Lint1 Interrupt または NMI に関するアラート メッセージが表示されたり、紫色の画面が表示されてシステム障害が発生したりする場合があります。

    回避策：BIOS を 2010.05.21 以降のバージョンにアップデートします。
  • HP システムにインストールされた ESXi では HP NMI ドライバが必要になる
    HP システム上の ESXi 4.1 インスタンスでは、マスク不可能な割り込み （NMI） を正しく処理するために HP NMI ドライバが必要です。NMI ドライバをインストールすると、NMI が正しく検出されてログに出力されます。このドライバがないと、ESX を実行する HP システムではハードウェア障害を伝える NMI が無視されます。
    注意： このドライバをインストールしないと、気付かないうちにデータが破損している場合があります。

    回避策：NMI ドライバをダウンロードしてインストールします。ドライバは HP の Web サイトからオフライン バンドルとして入手可能です。また、KB 1021609 （ http://kb.vmware.com/kb/1021609） も参照してください。
  • EqualLogic ストレージにデプロイされた iSCSI データストア上で仮想マシンが実行されている場合、仮想マシンが読み取り専用になる場合がある
    古いファームウェア バージョンの EqualLogic アレイを使用している場合に、仮想マシンが読み取り専用になる場合があります。このようなファームウェアはアレイ キューから I/O をドロップすることがあります。これにより、仮想マシンはその I/O に失敗のマークをつけ、そのあと読み取り専用になります。

    回避策：EqualLogic アレイ ファームウェアをバージョン 4.1.4 以降にアップグレードします。
  • ストレージ アレイをアップグレードしたあと、vSphere Client でハードウェア アクセラレーションのステータスが [サポート] に変更されるまで、短時間の遅延が発生する
    ストレージ アレイのファームウェアを VAAI 機能をサポートするバージョンにアップグレードしても、vSphere 4.1 はその変更を即時に登録しません。vSphere Client は、一時的に、ハードウェア アクセラレーションのステータスを [不明] と表示します。

    回避策：この遅延には問題がありません。ハードウェア アクセラレーション ステータスは、短時間経過したあと、[サポート] に変更されます。
  • P410i または P410 Smart アレイ コントローラを搭載した HP G6 プラットフォームの ESXi において、仮想マシンのパワーオン時やディスク I/O でパフォーマンスが低下する
    一部のホストでは、仮想マシンのパワーオン時やディスク I/O の生成時にパフォーマンスが低下する場合があります。主な症状としては、I/O パフォーマンスが低下し、次に示すような多数のエラー メッセージが /var/log/messagesに記録されます。
    Mar 25 17:39:25 vmkernel:0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:25 vmkernel:0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:26 vmkernel:0:00:08:47.632 cpu1:4097)NMP:nmp_CompleteCommandForPath:Command 0x28 (0x410005060600) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data:0x
    Mar 25 17:39:26 0 0x0 0x0.
    Mar 25 17:39:26 vmkernel:0:00:08:47.632 cpu1:4097)WARNING:NMP:nmp_DeviceRetryCommand:Device
    "naa.600508b1001030304643453441300100":awaiting fast path state update for failoverwith I/O blocked.No prior reservation
    exists on the device.
    Mar 25 17:39:26 vmkernel:0:00:08:47.632 cpu1:4097)NMP:nmp_CompleteCommandForPath:Command 0x28 (0x410005060700) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data:0x
    Mar 25 17:39:26 0 0x0 0x0

    回避策：HP 256MB P シリーズ キャッシュ アップグレード モジュール （ http://h30094.www3.hp.com/product.asp?mfg_partno=462968-B21&pagemode=ca&jumpid=in_r3924/kc） をインストールします。

アップグレードおよびインストール

  • VMware vCenter Update Manager を使用して、ESXi 3.5 から ESXi 4.0.x、さらに ESXi 4.1 Update 2 にマルチパス アップグレードできない *
    VMware vCenter Update Manager を使用して、ESXi 3.5 から ESXi 4.0.x にアップグレードしたあと、それをさらに ESXi 4.1 Update 2 にアップグレードしようとすると、次のようなエラー メッセージが表示され、失敗します。

    [ VMware vCenter Update Manager で、原因不明のエラーが発生しました。詳細については、[タスクおよびイベント] タブとログ ファイルを確認してください。]

    次のアップグレード パスを実行しようとすると失敗します：

    • ESXi 3.5 から ESXi 4.0 Update 1、さらに ESXi 4.1 Update 2 にアップグレード
    • ESXi 3.5 から ESXi 4.0 Update 2、さらに ESXi 4.1 Update 2 にアップグレード
    • ESXi 3.5 から ESXi 4.0 Update 3、さらに ESXi 4.1 Update 2 にアップグレード
    • ESXi 3.5 から ESXi 4.0、さらに ESXi 4.1 Update 2 にアップグレード

    回避策：ESXi 4.0.x にアップグレードしたあと再起動してから、ESXi 4.1 Update 2 にアップグレードしてください。

  • Update Manager 4.1 を使用してホストを ESX/ESXi 4.1 Update 1 にアップグレードできない   （KB 1035436）

  • vSphere Client のインストールが、エラーにより失敗する場合がある
    vSphere Client のインストール中に、インストーラによって期限切れの Microsoft Visual J# ランタイムのアップグレードが試行される場合があります。このアップグレードは正常に実行されず、vSphere Client のインストールは失敗し、エラー [ Microsoft Visual J# 2.0 Second Edition インストーラからエラー コード 4113 が返されました] が表示されます。

    回避策：以前のバージョンの Microsoft Visual J# をすべてアンインストールしてから、vSphere Client をインストールします。インストーラには、アップデートされた Microsoft Visual J# パッケージが含まれています。
  • 別々の USB フラッシュ ドライブ上にある 2 台の ESXi 環境に同時にアクセスすると、システムがパニック メッセージを表示する
    2 つの異なる USB フラッシュ ドライブ上にビルド番号が同じ ESXi 環境が複数ある場合、これらにアクセスするシステムを起動すると、システムがパニック メッセージを表示します。

    回避策：いずれかの USB フラッシュ ドライブを切断し、システムを再起動します。

vMotion および Storage vMotion

  • ESXi 4.1 ホストの再起動後、vMotion が無効になる
    ESXi ホストで vMotion を有効化し、ESXi ホストを再起動すると、再起動処理が完了したあと vMotion が有効でなくなっています。  

    回避策：この問題を解決するには、システム ベンダーから提供されている最新バージョンの ESXi イメージを再インストールします。

  • スワップ ファイルの再配置後にホット プラグイン処理が失敗する
    スワップ ファイルの場所を変更したあと、DRS クラスタまたはスタンドアロン ホストにあるパワーオン状態の仮想マシンでホット プラグイン処理が失敗し、[ ターゲットのレジュームに失敗しました。仮想マシンが見つかりません] というエラー メッセージが表示されます。

    回避策：次のタスクのいずれかを行なってください。
    • 該当の仮想マシンを再起動してスワップ ファイルの新しい場所を登録してから、ホット プラグイン処理を実行します。
    • vMotion を使用して該当の仮想マシンを移行します。
    • 該当の仮想マシンをサスペンドします。

VMware Tools

  • PR 632995：ESXi 4.1 U1 上の最新の errata kernel のある RHEL3 に VMware Tools をインストールすると、VMXNET ネットワーク インターフェイス カードを使用できなくなる *
    RHEL 3.9 モジュールに事前に組み込まれた VMware Tools の一部のドライバは、2.4.21-63 カーネルとは ABI に互換性がないため正しく動作しません。その結果、vmxnet や vsocket などの一部のデバイス ドライバは、REHL3.9 への VMware Tools のインストール時にロードされません。

    回避策：2.4.21-63 カーネルで起動します。2.4.21-63 カーネル用の kernel-source および gcc パッケージをインストールします。 vmware-config-tools.pl, --compileコマンドを実行します。これによって、このカーネル用のモジュールがコンパイルされ、実行中のカーネルで動作するモジュールが生成されます。

  • Microsoft Windows 2000 仮想マシンの再起動時に、VMware Tools が自動アップグレードを実行しない
    VMware Tools で電源サイクル時の自動アップグレードを構成 （[仮想マシンのプロパティ] ウィンドウの [詳細] ペインの下にある [各パワーオンの前に毎回 Tools をチェックしてアップグレード] オプションを選択） しても、Microsoft Windows 2000 ゲスト OS の場合、VMware Tools は自動アップグレードを実行しません。    

    回避策：         Microsoft Windows 2000 ゲスト OS では、VMware Tools を手動でアップグレードします。

 

 

ページの先頭へ