・・・でも、これだけのBug Fixにしては随分と高い・・・本気で。

　さて、そろそろVMware Playerとの差額を払うだけの理由が無くなってきてしまったVMware Workstationなのだが、VMware 6.5には「複数VMを走らせて、同時にネットワークに負荷をかけると妙にホスト負荷が高くなってネットワーク接続が不安定になり、しまいには（ゲスト側のネットワークスタックが）落ちる」という問題があったのであり。

　これ、ネットワーク分散処理の確認やテストのためにVMを複数動かすような場面では正直結構致命的なのだが、どうやら症状の出方がホスト側の環境に依存するようで。
　そんな話聞いたことない、なんて言われたりもしたのだ、が。

　＃要するに「貧弱な環境」ではコケ易かったらしい・・・。

　今回イロイロとあってWorkstationを7.0.1にしたところ、どうやらこの症状は治まった模様。このblog記事を書いている裏でも複数VMが元気に動いているが、妙な重さも不安定さもなく、普通にデータが流れていますよ。

　・・・とはいえ、これだけのことをしていると普通に重いんですがね。

　＃いくら出来るって言われたってVMwareでAeroを動かす気にはなれないなぁ・・・。

　時々妙なエラーというか変換失敗というか、そんな状態になりません？

　元々結構アレな状態の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よりは明らかにパフォーマンス良さそうだしね（泣。