XP Mode は提供当初は、CPU の仮想化支援機能が必須となっていましたが、以下の修正プログラムの提供で、
仮想化支援機能が無くても動作するようになりました。

Windows 7 を実行しているコンピューター上の Windows Virtual PC での Windows XP Mode のハードウェア支援による仮想化に関するエラー メッセージ

仮想化支援機能がなくても動作するようにするための修正プログラムをインストールすることで、Hyper-V の
ゲスト OS でも XP Mode の検証ができるのか試してみました。
# すでに試されている方はいらっしゃいますが、自分でもやってみたかったので。

Hyper-V 上でゲスト OS が起動することで以下の検証を仮想環境上で、実施することができるようになります。

• XP Mode
• MED-V v2
• (MED-V 1.0)

MED-V 1.0 は XP Mode ではなく Vritual PC 2007 ですが、ゲスト OS 上で Virtual PC 2007 を実行することも可能です。
以前、Windows Server 2008 のゲスト OS として実行した場合は、結構動作が重かった記憶があったのですが、
Windows Server 2008 R2 で実行したところ以前のようなストレスは感じることはなく、検証に使えるレベルでした。

?

■ゲスト OS で XP Mode

OS は Windows 7 Enterprise Edition x86 を使用しています。

仮想化支援機能が無い CPU で実行可能にするためのパッチを適用しない状態では XP Mode のセットアップを起動すると、
以下のエラーとなります。

KB977206 のパッチを適用した状態で XP Mode を実行してみます。
仮想化支援機能がなくても動くようにすると、XP Mode のセットアップを起動することができるようになります。

?

自宅には以下の CPU の検証環境があります。

• AMD Phenom X4 9950
  
• Intel Core i3 M330
  
• Intel Core? 2 Duo T7100
  ?
• Intel Xeon 3350
  

それぞれで稼働検証をしてみました。

?

■AMD Phenom X4 9950

Phenom X4 9950 では正常に起動しました。

?

■Intel Core i3 M330

Core i3 でも正常に起動することができました。

?

■Intel Core? 2 Duo T7100

Core 2 Duo の場合は、XP Mode のセットアップを完了することができませんでした…。

?

■Intel Xeon 3350

こちらもセットアップを完了することができませんでした。

ただし、Xeon 3350 ではそのまま放っておくと起動しました…。
?

仮想化の上で仮想化。CPU のスペックが求められる構成なのかもしれないですね。
Core 2 Duo の場合は、スタートメニューの XP Mode からではなく、KB977206 と Windows Virtual PC の統合機能を手動で
イ
ンストールして環境を作ると XP Mode の検証をすることができます。

?

今回は x86 で検証しているのですが、x64 の Windows 7 でも検証したところ OS がフリーズしてしまいました。
下がフリーズしている状態なのですが、パッと見は OS が起動しているように見えますが、

Hyper-V マネージャーでゲスト OS の状態を見ると、ハートビートが、[通信の切断] となってしまっています。

Windows Virtual PC ではなく、MED-V 1.0 SP1 用に Virtual PC 2007 をインストールして起動してみたのですが、
そうすると OS が突然落ちてしまいました…。
# こちらは、Corei3 で試した結果です。

Phenom X4 9950 だと x64 でも XP Mode が動作したのですが。

CPU のスペックや機能でこの辺の違いが出ているのでしょうか？？
情報を調べきれいていないため、原因まではわかっていません。

?

スペックの高い CPU (Nehalem 系)? があれば試してみたいのですが、さすがに自宅の検証環境として導入できるレベルは超えてしまいますね。

x86 であれば、動く環境が多そうなので MED-V v2 が提供されたときは、物理環境を用意しなくても初期の検証は実施できそうです。

[T2-401]? Effective Hyper-V R2 SP1 ? 詳説 Dynamic Memory ? で Dynamic Memory が有効になっている、
仮想マシンで Reservation の設定ができるという話がありました。

この設定は WMI で実施する必要があるとのことでしたので、先日の投稿で設定用のスクリプトを作成してみました。

WMI で仮想マシンに Reservation を設定

?

この設定をした時の動作を軽く検証してみました。

?

■仮想マシンの Reservation の設定箇所

Hyper-V 上の仮想マシンの構成情報は XML ファイルに記載されています。

WMI で [rootVirtualization] 名前空間の [Msvm_MemorySettingData] クラスから情報を参照することもできます。

以下の情報は WMI で取得したメモリの情報になります。

Address	?
AllocationUnits	MB
AutomaticAllocation	True
AutomaticDeallocation	True
Caption	メモリ
Connection	?
ConsumerVisibility	?
Description	Microsoft Virtual Machine メモリの設定です。
DeviceID	?
DeviceIDFormat	?
DynamicMemoryEnabled	True
ElementName	メモリ
HostResource	?
InstanceID	Microsoft:A4A7173B-7DA6-42B8-8EE1-4DA2849E91184764334d-e001-4176-82ee-5594ec9b530e
IsVirtualized	True
Limit	65536
MappingBehavior	?
OtherResourceType	?
Parent	?
PoolID	15129609-B465-4916-AA13-0CF4B109ADB0
Reservation	1024
ResourceSubType	Microsoft Virtual Machine Memory
ResourceType	4
TargetMemoryBuffer	20
VirtualQuantity	1024
Weight	5000

?

初期状態では、[Reservation] は [VirtualQuantity (スタートアップ RAM)] と同一の設定になっています。
また、Reservation を設定するためには、[DynamicMemoryEnabled] を [True (有効)] に設定する必要があります。
DynamicMemory を有効にしていない状態では、WMI でReservation の値を設定しても設定が保存されません。
また、仮想マシンが起動している状態では変更ができないので設定をするときには仮想マシンを停止状態にする必要があります。

仮想マシンの構成ファイルは [Hyper-V のサービス (Hyper-V Virtual Machine Management)] でファイルにロックがされていますので、
XML ファイルを直接変更して Reservation の設定をすることができないようです。
そのため、WMI を使用して設定を変更する必要があるようです。
# サービスを停止すればファイルを直接変更することが可能です。

?

?

■Reservation を有効にした際の現在のメモリの遷移

Reservation を設定していない仮想マシンは、初回起動時にはスタートアップ RAM のメモリで起動され、必要に応じてメモリは
拡張されますが、最小ののメモリ設定としてはスタートアップ RAM の値になります。
# 今回は 1,024 MB をスタートアップ RAM として設定しています。

?

パフォーマンスモニタでメモリの使用量を確認するとメモリも一定のサイズで遷移しています。
# アプリケーションは何も実行していない状態で稼働させています。

Reservation を 784 MB に設定して、メモリの遷移を見てみたいと思います。
起動時は、スタートアップ RAM の値で起動されるという動作は変わりません。

そのまま起動した状態にししばらくすると現在のメモリが下がります。

パフォーマンスモニタを見ていると、[Memory Remove Operations] が発生し、[Physical Memory] が
減っていることが確認できます。

Reservation の設定が働き、スタートアップ RAM 以下までメモリが減っていることが確認できますね。
Reservation を 8 に設定するとどうなるかも試してみました。
# 設定の最小値は 8 になるようです。

解放できるところまで解放しているようですね。

スタートアップ RAM と Reservation の使い分けをどうするかはまだ考えていませんが、設定して動作するところまで確認してみました。

昨日の Tech･Ed Japan 2010 の [T2-401]? Effective Hyper-V R2 SP1 ? 詳説 Dynamic Memory ? のセッション内で
以下のお話がありました。

• WMI のクラスにプロパティが追加されている。
• Reservation プロパティは WMI でしか設定できない。(GUI では設定できない)
• 安定稼働してきたときに最低限確保しておくメモリ。Startup RAM より小さく設定できる。

早速、PowerShell で WMI を使用してこのプロパティを設定するためのスクリプトを書いてみました。

# 設定をする仮想マシン $VMName = "RemoteFX" # Reservation として設定するメモリサイズ (MB) $MemReserve = 256 # 仮想マシンの管理サービス用のオブジェクト作成 (設定を Commit するのに使用) $VM_Service = Get-WmiObject -namespace rootvirtualization -Class Msvm_VirtualSystemManagementService # 対象の仮想マシンのベース情報を取得 (設定変更を Commit するにはこのクラスの PATH を指定する) $VMC = Get-WmiObject -Namespace rootVirtualization -Class Msvm_ComputerSystem -Filter "ElementName=’$($VMName)’" # 仮想マシンの設定情報を取得 # SettingType = 3 は現在の仮想マシンの構成情報 SnapShot が存在すると 5 の情報が増える $VMS = Get-WmiObject -Namespace rootVirtualization -Query "Associators of {$VMC}? Where ResultClass=Msvm_VirtualSystemSettingData" ` | Where-Object {$_.SettingType -eq 3} # 仮想マシンのメモリ設定情報の取得 $VMMS = Get-WmiObject -Namespace rootVirtualization -Query "Associators of {$VMS}? Where ResultClass=Msvm_MemorySettingData" # 変更前のメモリ情報 Write-Output "Before : $($VMS.ElementName) , $($VMMS.DynamicMemoryEnabled) , $($VMMS.Reservation)" # Reservation を設定するためには、DynamicMemoryEnabled を True にする必要がある。 $VMMS.DynamicMemoryEnabled = $true $VMMS.Reservation = $MemReserve # 変更後のメモリ情報 Write-Output "After : $($VMS.ElementName) , $($VMMS.DynamicMemoryEnabled) , $($VMMS.Reservation)" # 変更を確定 $Result = $VM_Service.ModifyVirtualSystemResources($VMC.__PATH, $VMMS.psbase.Gettext(1))

?

WMI でプロパティを設定する場合、[ModifyVirtualSystemResources] を設定しないと変更は確定されないですね。
また、[ModifyVirtualSystemResources] が True でないと Reservation の設定が反映されないようです。

今回、初めて WMI で仮想マシンを触ったのでこの辺がわからず、四苦八苦しました。
開発はもうあまり携わらいのですが、このようなスクリプトをもっと可読性と汎用性を高めて作成するようになりたいものです。
# 今回も見づらいコードですよね。

検証環境の一台には RemoteFX を検証するために 256 MB の GPU を搭載しています。
以下が、GPU-Z というツールで取得した GPU の情報になります。

この環境で何台 RemoteFX 3D ビデオアダプターが有効になっているゲスト OS を起動できるかを試してみました。
結論から言ってしまいますと 1 ～ 3 台起動することが可能です。
RemoteFX 3D ビデオアダプターの技術情報として以下の情報があります。
Hardware Considerations for RemoteFX
この情報の中に、解像度と使用するモニター数の設定による必要となるメモリについての記載があります。
RemoteFX 3D ビデオアダプターで使用される GPU のメモリですが、解像度とモニター数に依存するようです。
RemoteFX 3D ビデオアダプターを追加した直後のデフォルトの状態では、
– [モニターの最大数] が [1]
– [モニターの最大解像度] が [1280 × 1024]
となります。

この状態ですと、[125 MB] のメモリが消費されることになります。
[125 MB × 2 = 250 MB] ではありますが、GPU に搭載しているメモリがフルに使えるかといわれるとそうでもないはずですので、
この状態では 1 台までRemoteFX 3D ビデオアダプターが有効になっているゲスト OS を起動することが可能です。
2 台目を起動しようとすると GPU のメモリが不足して以下のエラーになります。

– [モニターの最大数] が [1]
– [モニターの最大解像度] が [1024 × 768]

以前、以下の投稿をしました。
仮想ハードディスクの拡張と縮小

縮小には VHD Resizer というツールも検証してみたのですが、仮想ハードディスクのサイズを
縮小することができませんでした。

以下の仮想ディスクを VHD Resizer で開いてみます。

現在 40 GB のディスクになっているのですが、[Min] が 40gb となっており、ディスクサイズを縮小することができませんでした。

前回はここで終わっていたのですが、先月以下の記事が投稿されました。
Shrink VHD size

VHD Resizer を使って、仮想ハードディスクのサイズを縮小する方法が紹介されていました。
「あれ。VHD Resizer でディスクサイズを縮小できるんだ。」と思って再度検証してみました。

?

■VHD Resizer で仮想ハードディスクを縮小するためには

VHD Resizer で仮想ハードディスクを縮小するためには、事前にパーティションを縮小して、[未割り当ての領域] としておく必要があるようです。

未割り当ての領域を作った仮想ハードディスクを VHD Resizer で開いてみます。

そうすると、前回 (未割り当ての領域を作る前) は [40 gb] となっていたのが [20 gb] となっています。

VHD Resizer はベースの仮想ハードディスクはそのままで、新規の仮想ハードディスクを作成します。
Min が 20 gb になっているので、New Size に 20 gb を指定しても [resize] を押すことができません。

Size を MB にすると理由がわかります。
MB だと 20531 mb となっています。New Size には Min より大きい数を入力する必要がありますので、今回の場合は、[21 GB] か
[20532 MB] を設定する必要があります。

[resize] を押すと、Destination に指定したパスに縮小した VHD が作成されます。

[resize] を押すとオリジナルの仮想ハードディスクが読み込まれ、新規の仮想ハードディスクに順次書きだされていきます。

終了するとダイアログが表示されます。
今回は他の仮想ハードディスクのサイズは変更しませんので、[いいえ] をクリックします。

VHD Resizer で縮小が完了した仮想ハードディスクがこちらになります。

未割り当ての領域もなくなってディスク全体が縮小できていることが確認できました。

未割り当ての領域にしないと [Min] が変更されないとは気づきませんでした。

前回、RemoteFX 3D ビデオ アダプターを試してみようとしたときには、オンボードのグラフィックチップだけでしたので、
ゲスト OS を起動した際に以下のエラーが発生してしまいました。

ちょっと、悔しかった (?) ので会社帰りに大手家電量販店に行って、以下のグラフィックボードを購入してきました。
RH4350-LE256HD/HS2

定価で 3,500 ぐらいで、たまっていたポイントを使って 1,900 円でお買い上げできました。
まぁこれぐらいの値段なら失敗しても、「悔しくなんかないやい！！」と強がってちょっとしょんぼりするレベル。

この グラフィックボードをML 115 G5 に搭載して、RemoteFX 3D ビデオ アダプター を試してみました。

?

■ML115 G5 に搭載した時の問題

わくわくしながら、ML115 G5 にグラフィックボードを搭載して、電源を入れてみたらなぜか画面が表示されない…。
BIOS のアップデートしたら何か変わるかな～と思ったのですが、状況に変化はなし…。
# オンボードのディスプレイアダプタ / 追加したグラフィックボードのディスプレイアダプタのどちらにさしても表示されない。

まぁ、OS 自体は起動しているようなので、リモートデスクトップで接続ができれば支障はないので今回は無視して進めることにしました。

デバイスドライバはこちらから入手可能です。(Windows 7 x64 用を使っています。)
Display Driver Only

?

■RemoteFX の情報

RemoteFX の情報をいろいろと調べてみました。
以下の技術情報を参考にすると良さそうです。(全部英語…。)

Deploying a Single Microsoft RemoteFX Server Step-by-Step Guide
Deploying Microsoft RemoteFX for Personal Virtual Desktops Step-by-Step Guide
Deploying Microsoft RemoteFX for Virtual Desktop Pools Step-by-Step Guide
Deploying Microsoft RemoteFX on a Remote Desktop Session Host Server Step-by-Step Guide

Hardware Considerations for RemoteFX
Microsoft RemoteFX

?

■RemoteFX 3D ビデオ アダプター を有効にする

今回はグラフィックボードを追加しているので、RemoteFX 3D ビデオ アダプターを追加してゲスト OS を起動することができます。

こちらが起動直後のゲスト OS のデバイス マネージャーの画面になります。
ディスプレイ アダプターは [標準 VGA グラフィック アダプター] となっています。
不明なデバイスとして表示されているのが、3D ビデオ アダプターになります。

3D ビデオ アダプターを使うためには Windows 7 を SP1 Beta にする必要があります。

In order to use RemoteFX in a virtual desktop, you must be running one of the following editions: WindowsR 7 Enterprise with SP1 WindowsR 7 Ultimate with SP1

?

ということでさっそく SP1 をインストール。

?

■RemoteFX 3D ビデオ アダプターを追加すると、VM のコンソールから接続できない。

インストールが終わったらさっそく接続をしてみます。

そうすると以下のような画面が表示されます。

RemoteFX 3D ビデオ アダプターを追加すると、[仮想マシン接続コンソール] (VMConnect.exe) から接続ができなくなるようですね。
メッセージに表示されているようにリモート デスクトップ接続からは接続が可能です。

ちなみに SCVMM で接続をしようとすると以下のようなちょっとさびしい画面になります。

■リモートデスクトップで接続して確認

リモートデスクトップであれば接続することができます。

Windows Server 2008 R2 SP1 で統合サービスも更新がされていますのでインストールしました。

?

Windows 7 SP1 Beta をインストールした環境で、RemoteFX 3D ビデオ アダプターを追加すると、ディスプレイ アダプターが
[Microsoft RemoteFX Graphics Device ?WDDM] に変更されます。
# 統合サービスはインストールしなくても変更はされていました。
?

テストするための方法はこれから調べていきたいと思います。

続いては Dynamic Memory について調べてみたことをまとめたいと思います。

■Dynamic Memory の設定

Dynamic Memory の設定ですが、ゲスト OS のメモリを [動的] に設定することで使用することができます。

動的なメモリでは [スタートアップ RAM] と [最大 RAM] の 2 種類を設定します。
# Hyper-V でバッファーとして予約しておくべきメモリの割合についてはヘルプに記載がないので正確なことは言えないのですが、
　おそらく ホスト OS 用のメモリ予約なのかな～と思っています。

今回は複数のゲスト OS は起動していないので、[メモリの優先度] に関してはデフォルトのままとしています。

?

■ゲスト OS 起動後の状態

Dynamic Memory を設定して、ゲスト OS を起動してみます。

起動時には、[スタートアップ RAM] のサイズまでメモリが確保されます。

SP1 を適用すると Hyper-V マネージャー も表示が変更され、[現在のメモリ] と [使用可能なメモリ] が表示されるようになります。
こちらも 512 MB となっており、[スタートアップ RAM] まで確保されていることが確認できますね。

?

■動的なメモリ拡張を発生させる

それでは、この状態で Dynamic Memory による動的なメモリ拡張を発生させて見たいと思います。

てっとり早くメモリを消費させるため、[fsutil コマンド] を使用して、ファイルサイズの大きいテキストファイルを作ってみたいと思います。

fsutil file createnew c:test.txt 536870912

これで 512 MB のテキストファイルが作成できました。

それでは、このテキストファイルをメモ帳で開いてメモリの割り当てがどのようになるか確認してみたいと思います。

実装メモリが [1.67 GB] に拡張されていることが確認できます。
Hyper-V マネージャーの [現在のメモリ] も拡張されています。

再起動をしないでも動的にメモリを拡張できるのが Dynamic Memory の機能となります。

同じファイルを別のメモ帳で開き、さらにメモリを使用してみたいと思います。

今回は、[最大 RAM] を [2048 MB] に設定していますので、メモリが [2 GB] で止まります。

こちらがホスト OS のタスクマネージャの内容です。
利用可能メモリが 1.3 GB 程度となっていることが確認できます。

?

?

■メモリを使用していたプログラムを終了する

大量のメモリを使用していたメモ帳を終了するとどうなるか試してみます。

閉じたタイミングで、Hyper-V マネージャーの [使用可能なメモリ] が増えていることが確認できます。
# 1.6 GB 程度が使用可能なメモリとなっています。

メモ帳を閉じてしばらく待つと、[現在のメモリ] が [スタートアップ RAM] のサイズまで縮小されます。
# 今回はメモ帳以外プログラムは実行していないため、最小まで縮小されています。
?

一度拡張されたメモリですが、ゲスト OS の実装メモリから見ると縮小はされないみたいですね。

Hyper-V マネージャーの [現在のメモリ] が縮小されたタイミングで、ホスト OS の [利用可能] メモリが増えていますので、
ゲスト OS では [2GB] と表示されていても使用していたメモリが解放されていることが確認できます。

?

■パフォーマンスカウンター

Dynamic Memory のメモリの割り当て、解放ですがホスト OS のパフォーマンスモニターから確認することができます。

Balancer に関しては、[System Balancer] というインスタンスしか表示されていないのですが、VM に関しては起動している
ゲスト OS をインスタンスとして選択することができます。

VM の Added Memory / Physical Memory / Removed Memory を取得するとゲスト OS で動的にメモリの変化があった時の
状況を確認することができそうです。

オブジェクト	カウンター	説明
Hyper-V Dynamic Memory Balancer	Added Memory	このカウンターは、VM に追加されたメモリの累積量を表します。
	Available Memory	このカウンターは、ノード上に残されたメモリ量を表します。
	Averag Pressure	このカウンターは、バランサー ノード上の平均負荷を表します。
	Memory Add Operations	このカウンターは、追加操作の合計数を表します。
	Memory Remove Operations	このカウンターは、削除操作の合計数を表します。
	Removed Memory	このカウンターは、VM から削除されたメモリの累積量を表します。
Hyper-V Dynamic Memory VM	Added Memory	このカウンターは、VM に追加されたメモリの累積量を表します。
	Averag Pressure	このカウンターは、VM の平均負荷を表します。
	Current Pressure	このカウンターは、VM の現在の負荷を表します。
	Guest Visible Physical Memory	このカウンターは、VM で表示されるメモリ量を表します。
	Maximum Pressure	このカウンターは、VM の最大負荷帯域を表します。
	Memory Add Operations	このカウンターは、VM に対する追加操作の合計数を表します。
	Memory Remove Operations	このカウンターは、VM に対する削除操作の合計数を表します。
	Minimum Pressure	このカウンターは、VM の最小負荷帯域を表します。
	Physical Memory	このカウンターは、VM の現在のメモリ量を表します。
	Removed Memory	このカウンターは、VM から削除されたメモリの累積量を表します。

?

アイドル時にはメモリを解放してくれるようなサービスが実行されているとメモリが有効活用できそうですね。
VDI 環境で、クライアントアプリを実行するような場合も有効に利用できそうですね。

昨日より提供が開始された Windows Server 2008 R2 SP1 Beta ですが、昨夜に環境を構築し、今朝の通勤時間から
少し触り始めてみました。

SP1 で大きな機能としては、RemoteFX と Dynamic Memory の 2 つかと思います。

まずは、RemoteFX について調べて見た事をまとめて見たいと思います。

?

■ゲスト OS で RemoteFX を有効にするためには

SP1 を適用することで、Hyper-V のゲストで RemoteFX を有効にすることができるようになります。
RemoteFX の有効化ですが、ゲスト OS に [RemoteFX 3D ビデオ アダプター] を追加することで有効にできます。

ただし、SP1 を適用したらすぐに使えるようになるというわけではありません。
適用直後の状態で、ハードウェアの追加に項目が表示されるようになるのですがグレーアウトした状態となっています。

RemoteFX 3D ビデオ アダプターを追加するためには、リモート デスクトップ サービスの [リモート デスクトップ仮想化ホスト] の
[RemoteFX] の役割をインストールする必要があります。
?

この役割は VDI 環境を作成するときにインストールするものになります。
Windows Server 2008 R2 SP1 の RemoteFX ですが、VDI 環境での利用を意識しているみたいですね。

役割のインストールが終わると、ゲスト OS で RemoteFX 3D ビデオ アダプター が追加できるようになります。

?

■RemoteFX 3D ビデオ アダプターを追加して起動

それでは、RemoteFX 3D ビデオ アダプターを追加してみます。

ゲスト OS のハードウェアの追加をすると、アダプターの項目が追加されます。

モニターの最大数は [1 / 2 / 3 / 4] 、モニターの最大解像度は [1024×768 / 1280×1024 / 1600×1200 / 1920×1200] から
選択することが可能となっています。

アダプターを追加して [さぁ起動しよう] と起動したところ、私の環境では以下のエラーとなってしまいました…。
?

今回の環境ですが、ThinkPad x201i を使っています。
この環境では Intel のオンボードのグラフィックアダプターが使われており、グラフィックボードを追加してはいません。
このような環境だと、RemoteFX を使ってゲスト OS を起動できないみたいなんですよね…。

今回発生したエラー [Microsoft Synthetic 3D Display Controller] を元に調べて見たところ、グラフィックボードのメモリとして、
最低でも 200 MB は必要みたいでした。
推奨のグラフィックボードは 1GB のメモリのようで、私の環境にはそのような環境は一台もありません。
ということで、今回は RemoteFX を試せませんでしたとなっている次第です。

?

■パフォーマンスカウンター

Remote FX 用のパフォーマンスカウンターがありましたので少しまとめてみました。

オブジェクト	カウンター	説明
RemoteFX Hardware	Available General Memory	Displays RemoteFX available general memory
	General Memory Pool Size	Displays RemoteFX size of the general memory pool
	Number of Active Sessions	Displays RemoteFX number of active sessions
RemoteFX Software	Capture Rate	RemoteFX キャプチャ比率を表示します。
	Compression Ratio	RemoteFX 圧縮率を表示します。
	Hardware Blt	Displays ASIC Blt Processing Time
	Hardware DmaIn	Displays DmaIn Processing Time
	Hardware DmaOut	Displays ASIC DmaOut Processing Time
	Hardware Encode	Displays ASIC Encode Processing Time
	Hardware Frame Count	Displays RemoteFX Frame Count
	Hardware Sessio ID	Displays RemoteFX Session ID
	Hardware Total Frame Count	Displays ASIC Total Frame Count
	Output Bytes	RemoteFX 出力バイトを表示します。

?

?

ML115 G5 にグラフィックボードを追加すれば何とかなりそうな気もするのですが、すぐに環境を整備するのも難しそうです。

サーバー機ではグラフィックボードは最低限のものになっていることが大半だと思いますので、RemoteFX を使用する際には
気をつける必要がありそうですね。

今日はコマンドで Live Migration / Quick Migration を実行する方法について。

[Quick Migration の実行]

まずは Quick Migration の実行から。
ゲスト OS のクラスターグループを移動することで QuickMigration を実行することができます。
Hyper-V のコマンドではなく、クラスターのコマンドを使ってグループを移動させることで実行することが可能です。

• PowerShell (Windows Server 2008 R2)
  

  Import-Module FailoverClusters Move-ClusterGroup “<クラスターグループ名>” ?Node “<ノード名>” 例) Import-Module FailoverClusters Move-ClusterGroup "SCVMM 2008R2-OWA-01 Resources" -Node "T60-01"

• Cluster コマンド
  

  Cluster Group “<グループ名>” /MOVETO:”<ノード名>” 例) Cluster Group "SCVMM 2008R2-OWA-01 Resources" /MOVETO:"T60-01"

• SCVMM 2008 R2
  

  Move-VM -VM "<ゲスト OS 名>" -VMHost "<ノード名>" -UseCluster 例) Move-VM -VM "2008R2-OWA-01" -VMHost "T60-01" ?UseCluster

?

[Live Migration の実行]

続いて Live Migration の実行です。
Live Migration ですが Cluster コマンドでは実行できないようです。
PowerShell と SCVMM 2008 R2 からは実行可能です。

• PowerShell (Windows Server 2008 R2)
  

  Import-Module FailoverClusters Move-ClusterVirtualMachineRole "<クラスターグループ名>" -Node "<ノード名>" 例) Import-Module FailoverClusters Move-ClusterVirtualMachineRole "SCVMM 2008R2-OWA-01 Resources" -Node "T60-01"

• SCVMM 2008 R2
  

  Move-VM -VM "<ゲスト OS 名>" -VMHost "<ノード名>" 例) Move-VM -VM "2008R2-OWA-01" -VMHost "T60-01"

?

今回は単純なコマンドベースで実行してみたのですが、WMI を使っても実行できるようですね。

[関連情報]
I want to know the wmi function for live migration as moveToNode perfrom quick migration
CLUSCTL_RESOURCE_VM_START_MIGRATION Control Code
ClusterResourceControl Function
ExecuteResourceControl Method of the MSCluster_Resource Class
CLUSCTL_RESOURCE_VM_START_MIGRATION Control Code
External Resource Control Codes
Internal Resource Control Codes

param ( ??? $Name = $(throw New-Object ArgumentNullException -Args "Name"), ??? $Target = $(throw New-Object ArgumentNullException -Args "Target") ) # Get the desired virtual machine resource from the Failover Cluster WMI Provider $Query = @" ??? Select * From MSCluster_Resource Where Type=’Virtual Machine’ And Name=’$Name’ "@ $Vm = Get-WmiObject -Namespace rootmscluster -Query $Query # Tell the virtual machine resource to move. try { ??? $vm.ExecuteResourceControl(` ??????? 23068676, [System.Text.Encoding]::UNICODE.GetBytes($Target)) } catch [System.Management.ManagementException] {

以前、Twitter でつぶやいた内容をブログとしてまとめてみました。

私の家の検証環境は ThinkPad で 3 ノードクラスターを構築している環境があります。

ThinkPad では、CPU としては Intel の Core 2 Duo が使用されています。

それとは別に AMD の Phenom 9950 を使用している ML115 G5 もあります。
?

同一のベンダーの CPU であれば、プロセッサ バージョンが異なった場合でも、ゲスト OS の設定で CPU の機能制限をすることで、
Live Migration / Quick Migration を実行することができます。
?

この動作を全く別のベンダーの CPU で実行するとどうなるんだろうというのが今回の検証です。

私の検証環境に Intel のマシンとして、ML110 G5 がありこちらは Xeon を使用しているのですが、Core 2 Duo とさほど
機能的には変わらなかったので、ThinkPad と ML115 G5 間でゲスト OS を移行させてみたいと思います。

参考となりますが、Xeon の CPU 情報はこちらとなります。

?

[クラスターを構築]

Live Migration / Quick Migration をするためにはまずは、クラスターを構築しなくてはいけません。
ThinkPad は T60 と T61 を使って 3 ノード構成のクラスターを構築しているので、ここに ML115 G5 を追加させたいと思います。
# ML115 G5 は共有ディスクに接続済みです。

?

クラスターにノードを追加する前に [ノードの検証] を実行します。
すでにクラスターを構築しているノードと今回使用する ML115 G5 を選択して検証を実行してみます。

テスト項目としては全テストを実施するようにしています。

テストが終了するとレポートを表示することができるので、今回は CPU についてのレポートを確認してみたいと思います。
CPU については [同じプロセッサ アーキテクチャの検証] というテストで確認されるのですが、このテストではベンダーの
確認はしていないようです。
?

そのため、異なるベンダーの CPU を使っていてもクラスターを構築することは可能です。

SCVMM でも 4 ノードクラスターとして認識できています。
# クラスターとしてノード追加した後に追加したサーバーを最新の状態に更新すれば自動的にクラスター配下の
　 サーバーとして認識されます。

それでは、Live Migration と Quick Migration を実行していきたいと思います。

?

[SCVMM で Live Migration を実行]

Live Migration ですが、SCVMM とフェールオーバークラスターマネージャーで実行することができます。
まずは SCVMM で Live Migration を実行したいと思います。

• 今回、[2008R2-OWA-01] というゲスト OS を CSV 上に配置していますので、このゲスト OS であれば
  Live Migration をすることができます。
  # このゲスト OS は Intel の CPU の T61 で実行されています。
  対象のゲスト OS を右クリックして、[移行] をクリックします。
  ?
• T61 から ML115 に移行をしようとすると、異なる CPU ということで移行対象として選択することができないようになっています。
  [t61-01] に監視ては単純にメモリが足りていないので移行ができないのですが、[t61-02] に
  関しては Live Migration で
  移行可能なサーバーとして選択ができるようになっていますね。
  

SCVMM を使用している場合、異なるベンダーの CPU のホスト OS には移行ができないように制御がされていますね。

?

[フェールオーバー クラスター マネージャーで Live Migration を実行]

つづいて、クラスターの管理ツールで Live Migration を実行してみたいと思います。

• 管理ツールで ML115 に Live Migration を実行してみます。
  ?
• クラスターの管理ツールでも同様にエラーとなりますね。
  メッセージとしてはこちらの方がわかりやすい気がします。
  ?

異なるベンダーの CPU 間では Live Migration の実行はできないようですね。
続いて Quick Migration を試してみたいと思います。

?

[フェールオーバー クラスター マネージャーで Quick Migration を実行]

Quick Migration の実行ですが、Live Migration が可能な場合は SCVMM からは実行できないようです。
# ライブ移行しかできないようです。

Live Migration が実行できる環境で、Quick Migration を実行するためにはクラスターの管理ツールで実行する必要があります。

• ML115 に [クイック移行] をしてみます。
  
• 異なるベンダーの CPU を使用しているホスト間で Quick Migration を実行すると以下のエラーになります。
  Quick Migration は [保存→移動→開始] という流れになるのですが、この方法は使用できないようですね。
  [はい、仮想マシンをシャットダウンして移動します] をクリックするこちで [シャットダウン→移動→開始] という形で
  クラスターのノード間でゲスト OS を移行することが可能です。
  
• [はい、～] をクリックするとシャットダウンが開始され
  
• 他のノードに移動がされます。
  ?
• ここまでの操作は、[クイック移行] で試してみましたが、[仮想マシンの移動] を実行することでも、Quick Migration を
  実行することができます。
  
• 移動をするとゲスト OS が保存され、移動先として指定したノードに移動がされます。
  
• 保存された状態を復元するのですが、失敗します。
  
  

@IT の以下の記事では Quick Migration が成功することもあるということが書かれているのですが、私の環境では NG でした。
Hyper-V実践サーバ統合術 第4回

保存されたままでは、元のノードでしか起動できませんのでこの状態で他のノードで起動したい場合は、[保存された状態を破棄する] で
保存状態を破棄して、解除する必要があります。

異なるベンダーの CPU 間でゲスト OS を Live Migration / Quick Migration を実行することはできないみたいですね。
ゲスト OS の CPU に関してはこのような技術情報もあるようで
す。
Partition Properties

今回は GUI から実行してみましたが、Live Migration / Quick Migration はコマンドでも実行することができます。
次の投稿でコマンドから Live Migration / Quick Misgration を実行する方法をまとめてみたいと思います。