ESXi5.1でIntel NICを認識するけど使えないという事象


SupermicroのマザーボードPDSM4+を使ってvSphere環境を構築中、悩んだ点が1つ。

ESXi5.0だと特に問題なく動くのに、ESXi5.1にすると、オンボードNICがvmnicとして認識するけれども通信ができない、という症状。
MACアドレス認識するし、IPアドレスも普通に設定できるのに通信ができない。

いろいろ調べたら解消するための事例を発見。
VMWare ESXi, SuperMicro X7SB4, Intel 82573, Network trouble, сетевая проблема」と、その元ネタ「VMWare community」を発見

曰く

・Intel NICのうち82573E/82573Lで認識されているもので発生する
・ESXi 5.1をインストールした後に、ESXi5.0からnet-e1000とnet-e1000eドライバを適用せよ
・ネットワークがつながらないのでUSBメモリでコピーする必要あり
 ・USBメモリはFAT32フォーマット不可。FAT16でフォーマットする必要あり
 ・ESXiにUSBメモリをさす前に「/etc/init.d/usbarbitrator stop」を実行せよ
・「esxcli software vib install -d /vmfs/volumes/datastore1/ESXi500-201207001.zip -n net-e1000e」というような形でファイルはフルパス指定でコマンド実行

で、実際にためした結果、上記以外に以下の注意点もありました。
・ESXiをUSBメモリにインストールしているんだったらLinuxにマウントして直接コピーしてもよい
・さらに新しいESXi5.0のパッチ「ESXi500-201209001.zip」でもokだった。

また、ESXi5.1に最新のパッチ「ESXi510-201212001.zip」を適用しても通信は不可でした。
パッチ適用後、再度、ESXi5.0のnet-e1000eを適用する必要がありました。


2013/03/08追記

正攻法の突破方法として、対応するドライバをコンパイルして使える様にした、という事例を発見しました。

環境さんぷる「ESXi5.1のドライバを作成してみる(intel 82579LM/82574L編)」と、その更新版の「ESXi5.1のドライバを作成してみる(intel I217/I218/82579LM/82574L編)

Intelで公開されているドライバソースから作成したとのこと。
こちらは、VMwareの署名が無いドライバのため、インストールにはESXiの設定変更が必要です。

ちなみに、ここの人、他にもドライバを公開していました。
ESXi5.1のドライバを作成してみる(VIA VT6130/VT6122編)
ESXi5.0のドライバを作成してみる(Silicon Image 3124/3132/3531編)

ESXi5.xでテープ装置を使う


仮想環境において、ゲストOSからFC接続されているテープ装置を使おうとしたら、認識してないようだったので調べてみた。

結論からいうと、VMware KB2013670:「ESX/ESXi でテープデバイスが間違って ALUA デバイスとして認識されてしまう」が該当していた。
2015/12/18追記:現在は「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (2090103)」で公開されている。
2020/09/28追記:「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (1026157)

対処方法も、上記KBそのままで大丈夫だった。

実際に実行した例について、以下に紹介する。

1. まず認識しているかどうかを確認する
(1)「esxcli storage core path list」を実行する。

# esxcli storage core path list

<略>
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
Runtime Name: vmhba1:C0:T4:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 4
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
<略>
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
Runtime Name: vmhba1:C0:T5:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 5
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
<略>
#

というような感じで「Plugin: (unclaimed)」というデバイスが認識されいている。

(2) VMware上で使える認識になっているか確認する
「esxcli storage nmp device list」を実行する。

# esxcli storage nmp device list
<略>
#


こちらの出力結果には出てこない。

2. 該当デバイスのSCSI inquryを調査
(1) SCSIデバイスのスキャンを実行
「esxcfg-rescan vmhba?」を実行。
今回の場合、「vmhba1」で認識されているので「esxcfg-rescan vmhba1」を実行。

(2) ログに出力されたScsiScanを確認。

# grep "ScsiScan" /var/log/vmkernel.log
<略>
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T1:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T1:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1582: Add path: vmhba1:C0:T1:L0
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T2:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T2:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.212Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T2:L0
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T3:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T3:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T3:L0
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T4:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T4:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T4:L0
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T5:L0': Vendor: 'HP ' Model: 'D2DBS ' Rev: 'EL01'
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T5:L0': Type: 0x8, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.214Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T5:L0
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
#

こんな感じで出力されている。
該当するものとしては、以下の3種類となる。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

3. 定義の変更
(1) 該当のデバイスに「VMW_SATP_LOCAL」として動作させる設定として、まず定義を設定。
先ほどの例の場合は以下の3デバイスがある。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

今回の場合は、以下のコマンドを実行した。

# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^Ultrium 4-SCSI*"
# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^D2DBS*"
#

なお、SCSI inquryでは文字列末尾につくスペースも重要であるが、このコマンドでは末尾のスペースは無視してくれるようである。

(2) 次に、各デバイスに対して現状、設定されている定義を解除

# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 0 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 1 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 3 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 4 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 5 -L 0
#

(3) 再スキャンを行い、設定した定義を適用
「esxcfg-rescan vmhba?」を実行する。

# esxcfg-rescan vmhba1
#


4. 認識が変わったことを確認
「esxcli storage nmp device list」を実行

# esxcli storage nmp device list
naa.XXXXXXXXXXXXc8
Device Display Name: HP Fibre Channel Medium Changer (naa.XXXXXXXXXXXXc8)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T5:L0;current=vmhba1:C0:T5:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T5:L0

naa.XXXXXXXXXXXX0a
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0a)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T2:L0;current=vmhba1:C0:T2:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T2:L0

naa.XXXXXXXXXXXX0c
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0c)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T3:L0;current=vmhba1:C0:T3:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T3:L0

naa.XXXXXXXXXXXX0e
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0e)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T4:L0;current=vmhba1:C0:T4:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L0

<略>

naa.XXXXXXXXXXXX08
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX08)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T1:L0;current=vmhba1:C0:T1:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T1:L0
#

クライアント端末にディスクイメージを配布するVMware MIRAGE



VMwareから新しい仮想デスクトップ向けのプロダクト「VMware MIRAGE」というのが登場。

・・・いや、詳細を見ていくと「仮想デスクトップ」と言えるかは、かなり微妙なんだけど、とりあえずVDIというくくりになるとは思う。

概要をみると、だいたいやりたい方向性としてはCitrix Xen Clientと似てる。
(Xen Clientは、ハードウェア制限が結構きびしいけど、これはどうなんだろうか?)

さて、とりあえず、ざらっと見た感じの特徴。

・VMware ViewはESXi上で実際のマシンが動いていたけど、これはクライアント端末上で動かす感じ
・クライアント上で仮想マシンを動かしているわけではない
 クライアント上でHypervisorを動かし、その上でクライアントOSを動作させている訳ではなく、ディスクイメージから直接Windows OSを起動している
・ディスクイメージ自体は仮想化技術の応用をしている
・クライアントとして使用できるのは以下のOS
 「XP SP2」「XP SP3」「Windows 7」
・Windowsライセンス上は各クライアントの物理マシンで直接Windowsが動作、という感じ

・各個別のクライアント端末上に存在するディスクイメージは以下に分割される
 ・ベースOS部分(Driver Library Layer/Base Layer/Departmental Application Layper)
 ・各ハードウェア固有差分(Machine Identify Layer)
 ・ユーザ固有のアプリケーション差分(User Application Layer)
 ・ユーザ固有の個人情報/デスクトップ情報など(User Data Settings Layer)
・上記のディスクイメージは、VMware Mirage Serverに転送され管理される
・OSパッチ/アプリケーション追加などはMirage Serverから行い、
 差分情報だけがクライアント端末に配布される。
・クライアント端末のハードウェアが複数あっても共通化可能

・Mirage ServerはWindows Server 2008R2上に立てる
 物理/仮想はどちらでも良い

不明な点
・クライアント端末のハードウェア制約
・導入によるクライアント端末のパフォーマンス低下の度合い
・プレインストールのクライアント端末が大量にある場合のMirage環境へのマイグレート手法

NetAppの仮想ストレージData ONTAP Edge



NetAppから「Data ONTAP Edge」というプロダクトが出てきた。

vSphere5環境で動作する仮想マシンとしてNetAppを動かして、NAS共有ストレージとして利用する、というもの。

ぶっちゃけ、これまでず~っとあった、検証用に提供されていたData ONTAP Simulatorを製品化しちゃったようなもの。
使い続けるためには有償となるようだが、コストに関しての記述が無かったので詳細不明。

利用可能ストレージサイズの最大が「5TB」なので、利用用途は大規模環境ではない感じ。

Data ONTAP Edgeを要求要件
・仮想マシンに2CPU以上割り当て(可能な限り占有させること)
・メモリは4GB以上(可能な限り占有させること)
・OS領域は57.5GB必要
・仮想ディスクを置く領域はキャッシュがバッテリーバックアップされたRAID上のVMFS3/VMFS5であること
・1本の仮想ディスクサイズは50GB~2TBまでを選択できる。
(何本まで増加できるか明記は無し)

特色
・Data ONTAP的にはクラスタモード(旧来の7-Modeではない)
・標準ライセンスに重複排除/SnapVault/SnapRestore/FlexCloneが含まれている
→ 小規模リモートオフィスにEdgeを置いて、中央のNetAppでバックアップ、的な感じ

いままでのSimulatorでもいい感じで使えてたので、Edgeになったからといって、特段かわりそうもないですが、とりあえず評価版の入手が可能です。

評価版はData ONTAP Edge Evaluationから入手できますが、NetApp Nowのアカウントが必要です。

また、NetAppのコミュニティーにData ONTAP Edgeに関する掲示板も出来ています。
Welcome to the Data ONTAP Edge CommunityにていろんなQ&Aを確認することができます。

vSphere 5.1関連の追加点・変更点



VMwareのwhitepaper類をあさってピックアップしたvSphere 5.1での追加点・変更点から、個人的に注目するポイントのみを紹介。

なお、ここに記載した見解は誤っている可能性があります。
鵜呑みにせず、原本資料などを当たってみてください。


vMotion関連の機能拡張
「vMotionとStorage vMotionを同時実施」およびそれを拡張した「共有ディスク無しのvMotion」。
KVM,Xenなどでできる共有ディスク無しで稼働中のVMをについて物理サーバを移動させるということが可能となった。
vMotion/Storage vMotionが同時に利用できることを「“Unified” vMotion」と呼ぶようだ。

ネットワーク経由でディスクイメージを転送するためにかかる時間短縮のための拡張も入っている。
「VMFS5利用時にvMotion速度改善」
ディスクイメージの転送方法を見直し、1つのディスクイメージを複数に分割し、並列転送をさせることで、VMFS3利用時に対して7割程度の速度になる。

「vMotion利用時の複数枚NICのロードバランス」
2枚以上のNICをvMotionに割り当てた場合に、前項目の「並列転送」の処理をそれぞれのNICに割り当て負荷分散を図るようになった。

(2013/02/18追記:VMware Communityにて「PowerCLI 5.1で x-vMotion」という日本語解説が書かれていました。旧来のvSphere Clintからは実行できない、とのこと)


vSphere Replication

以前からVMware SRMというDR向けソリューションがある。
仮想ディスクイメージの同期を取り、災害時にDR先で継続できる、という仕組みである。
VMware SRMを利用する場合の利点というのは「DR先でIPなどが変わる場合に自動的に変更した上で起動させることができる仕組み」とか「本番環境に影響させないようにDR検証ができる」だと思っている。

このVMware SRM、最初はVMware SRMに対応した高級なストレージが必須となっていた。
vSphere 5.0になり、専用ストレージでなくとも、仮想アプライアンスとして提供される仕組みを利用して通常のストレージでもVMware SRMが可能となっていた。

この仮想アプライアンスとして提供された仕組みの部分を今回「vSphere Replication」として切り出したような形となっている。

VMware SRM相当のことを行うには、人間が手を動かす必要がある、という感じである。

というか、DRのことまで含まれてしまうと3rdパーティーの仕組みを提案しにくくなるのですが・・・・


vCenter Server関連の拡張点
vSphere 5.0ではWindowsライセンスを必要としないvCenter Serverとして、LinuxベースのvCenter Serverアプライアンスが提供され始めた。
vSphere 5.1では、それをさらに進め、Windowsを利用しないでも大丈夫なようになりつつある。

「vCenter Single Sign-On Server登場」
いままでvCenter Serverのユーザ認証はWindowsユーザ認証に依存していた。
それを「OpenLDAP」「Active Directory」「NIS」によるユーザ認証で行えるようにした。

「vSphere Clientの終息」
vCenter Serverの管理はWindows上で起動するvSphere Clientから行う、というものだったが、vSphere Clientソフトウェアの更新が終息気味となっている。(まだ使える)
代替としてはvSphere 5.0から登場した「vSphere Web Client」となる。
vCenter Single Sign-On Serverやいろんな新機能を使う場合に、vSphere Clientは利用できない。


仮想マシンに対する拡張
毎回、いろんな制限が拡張されていますが、もちろん今回もあります。

「64CPU,メモリ1TBの仮想マシンが作成可能に」
仮想マシンハードウェアversion9が登場し、64CPU/メモリ1TBをサポート。
3Dグラフィックアクセラレーション関連もサポート。

「VMware Toolsの大幅改変」
いままでVMware Toolsはカーネル系のモジュールやドライバをインストールしていたため、VMware toolsのバージョンアップ時にOSの再起動が必要となっていました。
それをOS再起動が不要な構造とした、とのことです。
(ただし、おそらくVMware Tools with vSphere 5.0からVMware Tools with vSphere 5.1へアップデートする際は、再起動が必要になりそう)


各種I/Oに関する強化
「Storage DRS強化、Storage I/Oコントロールも強化」
Storage DRS 2.0!とか謳うぐらいに強化している・・・ということなんだけど、いまいち使いどころが見えない。
大規模環境で負荷分散できるらしいが・・・

「VMware vSphere APIs Arrary Integration(VAAI) snapshot」
VAAIというVMwareからストレージの機能を制御する仕組みに機能追加。
仮想マシンのsnapshotを取る際に、VAAIを利用してストレージの持つsnapshot機能動作させ、ESXi側の処理を軽減させる。

「vSphere Distributed Switch(VDS)の機能強化」
各種limitの拡張、LACPサポートなど、細かい点はさておき、地味に重要な修正がありました。

「VDS関連設定情報のバックアップ/リストア手法を改善」
VDSに関する設定は、いままでSQL DBの中に入っていたのですが、それに関するバックアップ/リストアの仕組みがちゃんと用意されていませんでした。
それをちゃんと用意したようです。
とはいえ、バックアップを取っていないと、vCenter Serverが全損した際に、VDSを1から再作成する必要がある、という点は変わらないようです。

「Single-Root I/O仮想化(SR-IOV)サポート」
PCIeのNIC側で仮想マシンに関するI/O処理を委託する機能
CPUのオフロードがはかれますが・・・まぁ、基本的に10Gb-NIC向けですね。


vSphere Data Protection(VDP)の拡張
VMware純正のバックアップソリューションが少し機能強化。

「VDPの利用数制限を緩和」
1台のvCenter Serverで管理できるVDP総数が10台。
1台のVDPで扱えるバックアップ対象となる仮想VMが100台。

「バックアップの保存先ディスク制限緩和」
いままで1TBディスク*2=2TBが最大だったものが少し拡張された。
0.5TB*3=実効容量 850GB
1.0TB*3=実効容量1300GB
2.0TB*3=実効容量3100GB
なぜ、実効容量がこんなにも減るのかは説明がなかったので不明。

「VDPアプライアンスの要求スペック上昇」
ただ、マイナス点があって、VDPアプライアンスとして必要な仮想環境が4vCPU、4GBメモリを要求しているという点。


Auto Deploy強化
大規模環境ではいちいち各物理サーバに対してESXiをインストールするのがめんどいわけです。
それを簡略化するために、PXEブートでESXiを起動させる仕組みAuto Deployに機能強化が入りました。

vSphere 5.0では完全ディスクレスの「Stateless」のみだったものが、
「Stateless」「Stateless caching」「Stateful installs」の3種類の選択可能になりました。

「Stateless caching」
サーバローカルのUSB/HDD/SAN Diskにブートイメージとか設定情報を置くが、別に消えてもかまわない状態

「Stateful installs」
サーバローカルのUSB/HDD/SAN Diskに対してESXiを自動インストールする

まぁ、用途に応じて使い分ける、という感じになるのでしょうか?


細かい変更点

「ESXiのrootユーザの扱いが変更に」
サポート用などでshellログインする際にrootアカウントが使えなくなった。
一般ユーザでログインし、suでroot権限を取得する必要がある
まぁ、ESX4.0ではそうなってたので、前の仕様に戻した、という気もしますがね。

「VMware View向けの機能拡張」
VMware View環境向けにいろいろ機能が追加されている。
Win7/Win8上でWindows XP Modeを利用してWindows XPアプリを動作させる、という場合に、それを補助する仕組み、というのは、かなりアレなものだと思う。

また、VDIでは1つのディスクイメージから複数の仮想マシンを立ち上げユーザ毎に割り当てる、とかいう運用をする場合がある。
その場合は、VMごとに差分データがあり、増えていくことになるが、基本的に減ることはない。
それを利用していない領域については減らしたり、整理したりすることができるようになるらしい。


とりあえず、気になったところとしては、こんなところです。