Tag Archives | vsphere

VMware vSphere 5: Feature Spotlight – Storage DRS

Overview

3,109 total views, no views today

1

vCenterとメモリ・メトリック

仮想マシンレベルで表示されるメモリーの詳細はvSphere クライントに数カ所配置されています。メモリ メトリックの解釈に戸惑う方も多くいるでしょう。というのも、用語的に似たような物が多く、それらが必ずしも同じことを指すとは限らないからです。サマリタブ内を見てみましょう。

ではまずはじめに全般(General)から。

de-2-1

原文: http://www.yellow-bricks.com

上記のスクリーンショットでは二つの項目がメモリーに関連します。

メモリ (2048MB)
メモリ オーバーヘッド (110.63MB)
最初の「メモリ」は、仮想マシンのために確保したメモリの量です。次の「メモリ オーバーヘッド」はVMカーネルが、該当する仮想マシンのために必要とするメモリのことです。ページテーブル、フレームバッファなどがそうです。

次にリソース(Resources)。

de-2-2

原文: http://www.yellow-bricks.com

同じく二つ、メモリに関連する項目があります。

消費されたホスト メモリ (1390.00MB)
アクティブなゲスト メモリ (61.00MB)
消費されたメモリとアクティブなメモリは一見すると理解しにくいかもしれませんが、頭を抱えるような物ではありません。「消費されたホスト メモリ」はゲストの為に割り当てられた、ホストの物理メモリです。メモリ オーバーヘッドも含まれるため、「消費された」メモリはゲストに与えられたメモリの容量を超えることもあります。余談ではありますが、パフォーマンス タブのパフォーマンス チャートの凡例内の消費カウンターには、実際のところメモリ オーバーヘッドは含まれません。

アクティブなゲスト メモリはVMカーネルが予想する、仮想マシンによって実際に使用されているメモリのことです。この「予想」は統計的なデータのサンプリングで計算された「予想値」です。

次のタブ、リソース割り当ては見る限りサマリより詳細です。

de-2-3

原文: http://www.yellow-bricks.com

メモリ セクションは三つのサブセクションから成り立ちます。

ホスト メモリ
消費 (1.36GB)
オーバーヘッドの消費 (42.00MB)

消費はゲストに割り当てられたメモリです。2GBの内、1.36GBがゲストによって消費されていることになります。オーバーヘッドの消費は仮想化オーバーヘッドによって消費されているメモリで、最初のスクリーンショットのVMカーネルが予想していた値よりも低いことが伺えます。簡単な方程式にするならば、こんな感じでしょう:
消費 = プライベート + オーバーヘッドの消費

ゲスト メモリ
プライベート (1.32GB)
共有 (700.00MB)
スワップ済み (0.00MB)
圧縮済み (0.00MB)
バルーン済み (0.00MB)
未アクセス (1.00MB)
有効 (102.00MB)

ゲスト メモリはいろいろあって、少々複雑に思えてくるでしょう。プライベートは物理的に確保されたメモリです。この場合1.32GBが物理的に確保されています。共有はTPS(Transparent Page Sharing*1)によって共有されるメモリです。スワップ済みはVMカーネルによって解放されたスワップ量。圧縮済みは仮想マシンの圧縮キャッシュに保存されたメモリの量。バルーン済みはバルーン ドライバによって開放されたメモリの量。後者三値はいずれも0が望ましいです。未アクセスは説明するのが厄介ですが、公式ドキュメントによると「ゲストによって決して参照されないメモリの量」です。

有効はアクティブに使用されているメモリです。コレも統計的なデータのサンプリングで計算された値です。(スクリーンショットを見て、61MBから102MBに変わったのがおわかりでしょう)最後のセクション、リソース設定ですが、ここにも二つ説明が必要な情報があります。
割り当ての最低限度 (2.14GB)
オーバーヘッド予約 (0.00MB)

割り当ての最低限度は全仮想マシンがフル稼働でメモリを消費するときに最低限に割り当てられるメモリのことです。仮想マシンに多大なメモリを割り当てる場合に要になるでしょう。オーバーヘッド予約はオーバーヘッド化メモリによって予約されているメモリの量。

元記事: http://www.yellow-bricks.com/2010/12/20/vcenter-and-memory-metrics/

16,217 total views, 11 views today

0

リソースプールと一斉移行

多くの組織がリソース・プールを使いホストにフォルダー構成を作り、vCenterのビューをクラスタ化します。仮想マシンはそのリソースプール内に置かれ、関連付け若しくはOS、アプリケーションの名前別にソートされるのが現状です。VMwareはこのためにリソースプールを開発したわけではありません。リソースプールは仮想マシンの負担を軽減し、仮想マシン群へのリソースを優先若しくは制限します。

ワークショップの際、リソースプールはフォルダー構成の為に用いられるものではないと参加者に教えております。 メインソリューションとしてリソースプールと仮想マシンのシブリング(兄弟)共有レベルを挙げます。

fd-1-1

原文: http://frankdenneman.nl/

シェア(共有)は仮想マシンへの優先度や他のリソースプールと同じ親リソースを持つ仮想マシンを指定します。要点はシブリング内でしか共有を直接比較することはできません。VM6とVM7の比率はどちらの優先度が高いのを示すのに対し、VM4とVM6の共有はどちらの優先度が高いのを示しません。

リソースプールについて以下の方々によって書かれました: “The resource pool priority-pie paradox”, (Craig Risinger)“Resource pools and shares” (Duncan Epping), “Don’t add resource pools for fun” (Eric Sloof) and “Resource pools caveats” (Bouke Groenescheij).

リソースプールをフォルダー構成として使わない他の理由として、vMotionのプロセスに影響を及ぼすおそれがあることが挙げられます。ネットワークの通信速度によりますが、vSphere4.1では同時に8つのvMotionプロセスを実行することができます。しかしこれらはリソースプールを変更しない場合、同じクラスタ内でしか実行することができません。以下のナレッジベースにてこの事が確認されました。(Knowledge Base article 1026102)幸いにもvMotionでは異なるリソースプールに一斉移行を実行する事は可能ですが、ターゲットが同じリソースプールの場合はこの限りではありません。 クラスタは最上位のリソースプールであるため、クラスタ間の移行は同時に一つのvMotionのオペレーションに限定されます。

fd-1-2

原文: http://frankdenneman.nl/

 

リソースプールをフォルダー構成の用に使用することがリソースの可用性に障害を及ぼす恐れがあるだけではなく、仮想マシンが他のリソースプールに移行される際に日常的なメンテナンスにも影響する恐れがある。

元記事: http://frankdenneman.nl/2010/09/resource-pools-and-simultaneous-vmotions/

7,277 total views, no views today

0

vSphereでWindows 2008 R2とWindows 7を使う

vSphere 上で Windows Server 2008 R2 または Windows 7 をゲスト VM として実行している人ならば、VMware Tools のインストール時に SVGA ドライバをインストールしないよう、VMwareのナレッジベースの記事(KB 1011709)で勧告されていることはご存知かもしれない。記憶が正しければ、これは特定のシナリオにおいてみられる安定性の問題が背景にあったはずだ。

ESX 4.0 で Windows 7 または Windows 2008 R2 をゲスト OS として使用することを考えているのであれば、VMware Tools に同梱されている SVGA ドライバの使用は避けた方がいい。代わりに標準の SVGA ドライバを使用することをお勧めする。

通常インストールでは SVGA ドライバがデフォルトでインストールされるため、これらのゲスト OS ではカスタムインストール(もしくはスクリプトによるインストール)を行い、SVGA ドライバを除外する必要があった。あるいは通常どおり VMware Tools をインストールし、後からデバイスマネージャで SVGA ドライバを削除していた。そうすると当然、VM は最初のスクリーンショットに表示される VMware Tools の SVGA ドライバではなく、Microsoft Windows が提供する SVGA ドライバを使用することになる。Microsoft Windows が提供する SVGA ドライバでは正常に機能し、安定性も良かったが、VMware Remote Console を介したマウスの動作が若干遅く感じられるという副作用があった。

jb-1-1

原文: http://www.boche.net/blog

 

 

 

 

 

 

 

 

 

 

 

 

 

VMware は ESX(i) 4.0 Update 1(2009/11/19 リリース)から挙動を変え、2 月に上記 KB 記事を改訂した。これによると、最新の VMware Tools には新しいバージョンの SVGA ドライバが同梱されており、通常のインストールでファイルは格納されるが、有効にはならない。

最も効果的な解決法は ESX 4.0 Update 1 にアップデートすることである。これには新しいWDDM ドライバが含まれており、VMware Tools と一緒にインストールされ、動作も保証されている。VMware Tools のアップグレード後、C:Program FilesCommon FilesVMwareDriverswddm_video に格納される。

通常どおり VMware Tools をインストールした後、標準の SVGA ドライバがインストールされているのが確認できる。KB の記事にしたがい、Windows デバイスマネージャを開いて  C:Program FilesCommon FilesVMwareDriverswddm_video に保存されたファイルにドライバを更新する

jb-1-2

原文: http://www.boche.net/blog

 

 

 

 

 

 

 

jb-1-3

原文: http://www.boche.net/blog

 

 

 

 

 

 

 

すると、新しいバージョンの VMware Tools に同梱された新しい WDDM ドライバがインストールされる。

jb-1-4

原文: http://www.boche.net/blog

 

 

 

 

 

 

 

 

 

 

 

 

再起動すると、長年 VMware を使用していて慣れ親しんだ、マウス動作のサクサク感と正確さが戻った。残念なのが、古いバージョンの Windows ゲスト OS では適切な VMware SVGA ドライバがインストールされるが、Windows Server 2008 R2 と Windows 7 では、Linux の ゲスト VM で VMware Tools をインストールする時と同じように手動でインストールする必要があることだ。その上、VMware Update Manager(VUM)を介した VMware Tools の自動インストール/アップグレードでは、WDDM ドライバが有効化されない。つまり、多くの VM では、適切な WDDM ドライバをインストールするには手動操作あるいはスクリプトの記述が必要となる。1 つできることは、WDDM ドライバを Windows Server 2008 R2 と Windows 7 のVM テンプレートにインストールすることだ。これにより、これらのテンプレートからデプロイされた VM では、WDDM ドライバがインストールされ、有効化された状態となる。

VMware が提供する WDDM ドライバのインストール方法は、短期的に見れば有用だが、スケーラビリティと堅牢さを備えた長期的ソリューションではない。VMware には WDDM ドライバが自動的にインストールされる自動化ソリューションが求められる。VUM にそれを組み込むべきだ。VMware Tools の次のアップグレードでは果たしてどうなるか―WDDM ドライバがそのまま残るか?それとも WDDM 版に代わり標準版が採用されるか?今後も目が離せない。

元記事: http://www.boche.net/blog/index.php/2010/03/28/windows-2008-r2-and-windows-7-on-vsphere/

6,057 total views, 5 views today

0

Powered by WordPress. Designed by WooThemes