Advanced Formant＋仮想マシンは要注意、かもしれない。
今更なんだけど、さ。
VMware Workstationネタ、続き。
というのは、つい先日。
調子に乗ってイロイロ置いていたらHDD空き容量が足りなくなってしまい、仕方ないのでWD20EARS・・・2TBでAdvanced FormantなHDDを導入、VHD置き場を移行したんですわ。
ところが、その後。何かVMの調子がおかしい。アクセスランプが盛大に光る割に、何かDisk I/Oが引っかかりまくる。OSだけでなく、アプリのパフォーマンスも明らかに落ちている。
結論。
Advanced FormatなHDDはVMware Workstationの仮想ディスク置き場には使わない方がいい。
上にどんなOSが乗るか分からない、というかイロイロ乗せられるのがメリットなVMware環境と、最新のOSでしかパフォーマンスの出せないAdvanced Formatの組み合わせは「やっぱり」ヤバい。
・・・まあ原理を考えれば当然なのだが。
実際使ってみたらかなりトンでもないことになりました、というお話でした、とさ。
＃つかここまで強烈に来るモンなのね。
ちょっと発熱が気になるが日立の7200rpmに交換すべきか？これは。
Tags: HDD, Virtualization
VMware WorkstationのDisk I/Oって、すごく・・・重いです・・・。
いやね、普通に重いとは思っていたんですよ。
でもね、まさかここまで重いとは思わなかったんですよ。
発端はDisk I/OとCPUを両方酷使する、某アプリをVMware Workstationで動かそうとしたこと。アプリの性質上VMware上で動かすと割と悲しいことになることは目に見えていたのだが・・・。
実際乗せてみたら、これが割とどころかもの凄～く悲惨なことになってしまったんですよ。
とはいえ、ここまで悲惨なことになるってのはきっと理由がある・・・ということであちこちつっついてみたんですが。
結論。VMware上の細切れ単位のランダムアクセスはもの凄～く重い。
ある程度の大きさのI/Oならばまだマシなものの、細切れアクセスに対してはもう「さすが仮想マシン」としか言いようがない。
で、これの解決方法は・・・無いよそんなの。
兎に角素のアクセスの重さは決定的なので、上位のOSなりアプリなりで吸収するしかない。といっても上モノのOSがWindows XPだったりするとOSレベルではもう手の出しようがないので、アプリ側でどうにかするしかない。
ということで、モノは試し。
アプリ側に手を入れて内部バッファをしこたま大きくして、且つDisk I/Oをある程度まとめて処理するようにしてみたところ。
何かものすごく調子よく動いているんですけど。
・・・と、ここまでやって気づいたのだが。
I/Oに足引っ張られるVMでこれだけ差が出たってことは、実環境でもI/O周りに手を入れたらパフォーマンスが上がる可能性があるってことでないのか、コレは。
んと・・・ちょっとやってみるかな・・・。
Tags: Virtualization
VMware Workstation 7で直った、かも知れない。
・・・でも、これだけのBug Fixにしては随分と高い・・・本気で。
さて、そろそろVMware Playerとの差額を払うだけの理由が無くなってきてしまったVMware Workstationなのだが、VMware 6.5には「複数VMを走らせて、同時にネットワークに負荷をかけると妙にホスト負荷が高くなってネットワーク接続が不安定になり、しまいには（ゲスト側のネットワークスタックが）落ちる」という問題があったのであり。
これ、ネットワーク分散処理の確認やテストのためにVMを複数動かすような場面では正直結構致命的なのだが、どうやら症状の出方がホスト側の環境に依存するようで。
そんな話聞いたことない、なんて言われたりもしたのだ、が。
＃要するに「貧弱な環境」ではコケ易かったらしい・・・。
今回イロイロとあってWorkstationを7.0.1にしたところ、どうやらこの症状は治まった模様。このblog記事を書いている裏でも複数VMが元気に動いているが、妙な重さも不安定さもなく、普通にデータが流れていますよ。
・・・とはいえ、これだけのことをしていると普通に重いんですがね。
＃いくら出来るって言われたってVMwareでAeroを動かす気にはなれないなぁ・・・。
Tags: Virtualization
MSのVMMの仮想マシン変換って…
時々妙なエラーというか変換失敗というか、そんな状態になりません？
元々結構アレな状態のOSをP2VしてVMDK（VMware Server）にした時点で結構色々とキている環境ばかりなのだが、それでも一応動いてはいるシロモノだったのだが。
とある事情でVMware ServerからMS Hyper-Vに一斉に乗り換えることになり、MSのVirtual Machine ManagerでゴリゴリとV2V変換していのだが、時々
「どう頑張っても起動も修復も出来ないADサーバ」
が出来上がってしまう模様。
具体的な症状としては「普通に起動すると起動中にエラーが出て強制リブートの無限ループに陥り」「AD修復モードで起動するとログインパスワードが（AD修復用に設定したモノですら）どう頑張っても通らずログイン不能のまま手の出しようが無くなる」という結構悲惨なもの。
まあ元々の環境が地雷を抱えていて、変換したついでにソレが炸裂した可能性も高いのだが、それなりの数（3桁には届かなかったけど）を変換したら割と確率高く出てしまったので（割合にすると1割程度？）、もしかしたら変換プロセス自体に潜在的な危険要素が混じっているのでは、と。
ちなみに当方の手元で試した限りでは、ADサーバ以外では起動しなくなる失敗はゼロだったので、対策としては
1・元イメージをVMwareで起動してADクライアントに一旦降格
2・そのイメージをHyper-Vへ変換
3・Hyper-V上で起動して再度ADサーバへ昇格
という作業をしました、えぇ。
あと、変換自体には問題は無さそうだが、Hyper-V統合サービスが上手くインストール出来ていない、という事例もいくつか。
こういうモノは、統合サービスインストーラが何故か途中でコケているものばかりだったのだが、取り敢えず手元の環境では
・WindowsUpdateを当て直して推奨モノを含めて最新にする
・統合サービスインストールディスクの中のsetup.exeでなく各環境用のバイナリを直接叩く
のどちらかで全て乗り切れた模様。
ついでに、MSのV2Vはvmxに「昔の設定の跡」、つまり「書いてあっても無くても意味のないモノ」が存在すると変換に失敗（エラーになる）ことが多い模様。
VMwareでは全く問題が起こらないので首を傾げてしまったが、エディタで項目を一つ一つ確認しながら削っていったら変換出来るようになったので。
＃一時的に普段使いでないvmdkをマウントして使ったりした場合、vmxにはその痕跡がきちっと残っているので、これはまず最優先で削除すべし、ということは分かった。
にしてもこうして多数の仮想マシンを振り回していると、やはり64bit OSと大量メモリは正義ですなぁ、と。
そしてGbEが遅くて。そろそろ10GbE、値崩れ起こしても…まだ無理かなぁ。
そいえばLGA1156 XEONが出るらしいが、ソレって当然メモリはReg.ECCだよね？
OpteronのDDR3化は当分先っぽいし、6ソケット装備（3ソケット＠ch）のM/Bの見本も出ているし、価格設定次第では大量メモリ搭載システムの台風の目になるかも。
既に出ているLGA1156周りのベンチ見ていると、LGA1366よりは多少落ちるようだが（というか多少しか落ちないのか）、現行Opteronよりは明らかにパフォーマンス良さそうだしね（泣。
Tags: Virtualization
もうIntel以外（のGbEは）駄目かも分からんね。
・・・というのは、ですね。
具体的に何が起こったかと言いますと。
まず、事実の確認。
YukonはVLANが作れます。
そして、WindowsでVLANアダプタを作ると、画面上はNICがいっぱい増えているように見えます。ちょっとお得な気分。
で、ここからは発生した問題。
VMware BridgeをYukonのVLANアダプタにかましても、ウンともスンとも言わないのですが。全く外と繋がらないのですが。
・・・えと、これね。自分が何かミスしたのかって、本気で全部イチから確認しましたよ、冗談でも何でもなく。でも、どう見てもミスは無い。
で、最後にまぁついでにという感じで、Intel PRO/1000を挿して（勿論Desktop版）同じことしてみたら何の問題も無く動いてしまったという。
まぁ、そもそもVLANアダプタ作成の段階でYukonはイマイチ挙動が怪しい風味ではあったのだけど。
まさか、ウンともスンとも言わないなんて不具合があるとは。
しっかし・・・遅いだけなら兎も角、その上病気持ちときたら、Yukonの立つ瀬は何処に・・・。
確かに蟹はシステム負荷は高いが、もしこれで安定度と速度でメリットがあるなら、Yukonより余程良い選択肢のような気さえするのだが。
とはいえ、当方r8168でVLAN使えるドライバって見たこと無いんだが。そもそも存在するのか？
つーか、全力でIntel回避を日々実践している当方をして、％TITLE％な発言をさせるなんて・・・
真面目な話、Intel以外で真っ当なGbE NICってのは無いんかい。
＃ちなみにIntel製アダプタを以ってしてもHost側にSEPが導入されているとVLANにBridge出来ないですな。
原因は分かり易くて、本来「VLAN:VLANID」と見えないといけないVMWareのVMNet設定画面に「Teefer2 Miniport」なんてのが見えてるのでね・・・。
Tags: GbE NIC, Virtualization
