ESXiのDISK 最大I/Oブロックサイズの調整

なんかこんな情報を見かけた。

最大 I/O ブロック サイズを変更して ESX/ESXi を調整し、ストレージ パフォーマンスを改善する (2074666)

ESX では、最大で 32767 KB の I/O 要求があるけど、ストレージよっては大きすぎてパフォーマンスが落ちるらしい。

うちのESXIのストレージはNexentastorのZFSでのNFSなのですが、
現状ブロックサイズが128KBなので、最大I/Oサイズを128KBに調整してみる。

VMwareInfrastructure/vSphere Client を使用して、ストレージ デバイスに渡される I/O 要求のサイズを減らす方法

  1. ホスト > 構成 へ進みます。
  2. 詳細設定 をクリックします。
  3. ディスク へ進みます。
  4. Disk.DiskMaxIOSize を変更します。(128KBの場合128に変更)

注:この変更では、ESX/ESXi ホストを再起動したり、ESX/ESXi ホストをメンテナンス モードにしたりする必要はありません。

 

とりあえず、1台だけ変更して、様子見中

Workstation 10で仮想マシンを立ち上げる際のチューニングメモ

Workstation 10で仮想マシンを立ち上げる際のチューニングメモ

  • VMware Toolsをゲストにインストールする。ある意味基本。
    VMware Toolsはドライバ以外にもパフォーマンスアップのための機能が含まれています。

 

  • 仮想マシンの仮想DISKの配置場所はホストOSのOS保存先とは別の物理Diskを割り当てる。また、極力書き込みが早いDISKを用意。

パフォーマンスアップのためには、やっておきたいがなかなか難しい状況も多いので出来るだけ分けておきたい。
ハードウェアキャッシュなしのRAID5ボリュームとかは、極端にパフォーマンスが落ちる場合が多いです。

  • 仮想ディスクは「事前に割り当て」仮想ディスクを作成する際、ディスク容量を「事前に割り当てる」にする。
    最初の作成時に時間がかかるしDISK容量も食うので、実際の使用時確保になる「拡張可能」にしがちだけど、パフォーマンスを考えたらこちら。
    あと、2GBの分割保存などはせずに、単一ファイルにしたほうがよい。

 

  • ホストOS側でのDeflagをしっかりやっておく。

DISK I/Oパフォーマンス確保のために、ぜひ。

  • ホストOSのワクチンソフトで、仮想マシンの仮想ディスクの保存先は除外設定をしておき、余分なオーバーヘッドは極力カット。

 

  • スナップショットは極力使用しないVMwareのスナップショットはスナップショット取得後の更新
    データを差分ファイルに書き出しますが、その差分ファイルは実際の使用時に容量を確保するし、DISKアクセスのオーバーヘッドが増えるので、パフォーマンス低下の要因になります。

 

  • Windowsの仮想マシンを立ち上げるときは1パーティーション(C:,D:)=1VMDKを心がけるパフォーマンスとは直接影響無いけど、上記のようにしておくと、パーティーションの容量が不足したときにあとから簡単に拡張できる。1つのVMDKに複数のドライブをまとめておくと、拡張できない場合もある。
    Windows2000     ・・・ CD-Bootによる拡張ツール等でデータを残したままで
    パーティーション容量を増加できる
    Windows2003,XP   ・・・ OSのdiskpartコマンドでオンライン拡張できる
    Windows2008,Win7 ・・・ Diskの管理(GUI)からオンライン拡張できる

 

  • 仮想マシンか同時に極力メモリを使用する設定をVMXに追加

通常のPCで、仮想マシンを稼動させる場合は、一番ボトルネックになりやすいのがDISKI/O。
なので、極力メモリを使用する設定をVMXに追加

MemTrimRate = “0” : .vmemファイルを使用しない(定期的にメモリ状況をファイルに保存するのを抑止)
mainMem.useNamedFile = “FALSE” : メモリトリミングの無効化(Workstation6.5からはGUIでも設定可)
sched.mem.pshare.enable = “FALSE” : ページ共有機能の無効化
prefvmx.useRecommendedLockedMemSize = “TRUE” :

その他動かす環境について

  • ホストPCのCPUは極力多くのコア搭載でVT-x対応のものを
  •  ホストPCの物理メモリは多めに搭載

おまけ

Workstation 10の仮想マシンを「共有VM」にすると、
他のWorkstationやWSXツール経由でのWebアクセス で、別のPCからコンソールをリモート操作できるようになる。

WSXは別途インストールが必要だけど、html5ブラウザがあればコンソール表示できる模様。

ただ、以下のような制限があるのでご注意を

  • ゲストOSと外とのクリップボード経由でのコピーと貼り付けができない
  • ゲストOSと外とのdrag-and-dropができない
  • 仮想マシンとの共有フォルダが使えない
  • USB機器が接続できない
  • ユニティ モードが使えない

あと、共有VMと通常の仮想マシンを同じフォルダにも設定できるけど
あとでトラブルの元となるので、別にしとくことを推奨です。

 

Proxy経由のvCloud接続でコンソールが表示できないのを調査する(紆余曲折ぶりをお楽しみください

先日、客先でインターネット上にあるクラウドにProxy経由でvCloudで構成されたクラウド環境に初めて接続してみた。

管理ポータルにはログインできたが、仮想マシンのコンソールを開こうとすると、
「接続しています」→「切断状態」となってコンソールが表示されない。

VMware Remote Console Plugin(VMRC Plugin)のログを確認すると、
proxy:8080というプロキシ経由でアクセスしていることが確認できるが、
サーバ名が確認できていない模様。

C:\Users\(ユーザ名)\AppData\Local\Temp\vmware-(ユーザ名)\vmware-vmrc-6092-6008.log

クラウドのマニュアルには

「接続端末がインターネット接続時にプロキシ認証が必要なネットワーク環境の場合、仮想マシンのコンソール操作ができない可能性があります。」

との記述がありますが、使用しているPROXYは認証が不要なことは確認済み・・・・・・

なお、vCloudのバージョンは5.1な模様。

 

で、いろいろ試行錯誤した結果、やっと原因見つけました。

 

ちなみに解決までの紆余曲折ぶりはこちら

  • インターネット上のポータルにはつながるのにコンソールにつながらなくてあせる。
    →コンソール出ないとOSインストールできない~
    →埒が明かないし次のスケジュールがあるので、仕方が無く、自社のリモート環境にアクセスして、そこからインターネット経由でOSセットアップ+SP適用を始める。計5台(ぉぃ
  • なんとかセットアップが終わり、紆余曲折タイムスタート
  • IEのセキュリティ設定を変えてみる。
    →× 変わらず
  • Firefoxでも試してみる
    →× 変わらず
  • OS変えてみる
    →× XP,WIndows7ともに一緒で表示されず。
  • どうしようもなくなったので、ダメ元で、
    インターネット間をつなぐProxyと、自PCとの間にもう一個Proxyを自PC内に立ててみる。
    いわゆる多段プロキシ。自PC->localhost:8080->proxy:8080->vCloud
    →○ なんとコンソール表示される(え、まじで
  • では、自PCとは別のPC(他PC)のプロキシ設定に上記多段プロキシを設定してみる。
    (自PCはMyPCという名前でDNS登録済み)
    他PC->MyPC:8080->proxy:8080->vCloud
    →× 表示されない・・・・・(なぜだ
  • 自PCのプロキシのログを見る
    →Cloud管理ポータルのログインは記録に残っているけど、
    コンソールアクセス時にプロキシにアクセスしている気配がない・・・だと・・・(??
  • 他PCのプロキシ設定の自PCサーバをコンピュータ名からIPアドレスにしてみる
    他PC->192.168.11.11:8080->proxy:8080->vCloud
    →○ コンソール表示される(え~
  • もしかしてと思い、IEプロキシ指定で最初のプロキシをサーバ名(Proxy)でなくIPアドレス(192.168.11.3)を入れてみる
    自PC->192.168.11.3:8080->vCloud
    →◎ コンソール表示される(やっぱり
  • IEプロキシ指定で最初のプロキシをサーバ名に戻してして、hostsに最初のプロキシサーバを登録して再挑戦
    →◎ コンソール表示される(原因確定

なに、この回り道状態。

 

本来は、クラウド提供会社に回答をもらうはずで、ログとかも送ったけど、
先に解決したのでとりあえず情報提供はしといた。

だって、クラウド提供会社って私の勤めている会社だし。別事業部だけどさ。

 

というわけで、最終的な原因はPCから外部のインターネット接続のため、IEのプロキシ設定で、プロキシの「サーバ名」を入力していたことでした。でもこれって普通ですよね。
DNSには「proxy」というサーバ名で登録済みで各クライアントからNSLOOKUPで「proxy」でIPアドレスができることも確認していましたので盲点でした。

これは 単にVMwareのコンソールプリケーション(vmrc plugin)のプロキシサーバのサーバ名-IP変換の問題でDNSを参照してくれていないのが原因のように見えるので、
以下の2つのうち、いずれかを追加で行うことにより、対応可能な模様です。

Windows7およびXPのPCで確認済み
(Windows8/8.1はそもそもvCloud5.1の対象外みたい)

方法1

操作PCのIEのプロキシ設定を、プロキシサーバ名をサーバ名からIPアドレスに変更
(例:Proxyから192.168.11.3に変更)

方法2

操作PCのIEのプロキシ設定を、プロキシサーバ名にサーバ名を設定のままで、
操作PCの「C:\Windows\System32\drivers\etc\hosts」ファイルに
プロキシサーバのIPおよびサーバ名の行を登録
(例:192.168.11.3          proxy)

 

うん、なにやってるんだ、オレ。