まずはやってみたらどうでしょう？趣味でやる分にはいくらでも設計できるし，誰にも迷惑かけません．何度もやってみたら，そのうち新しい知見が得られるかもしれません．もし設計書ができたらWebで公開してみるとか．だれか興味を持ってくれた人が実装を始めるかもしれません．その一人が私かもしれませんが．

ところで，「基本となる設計法方」とはなんでしょう？これを定義するような有力な文献があるのでしょうか．あるとすれば，その文献の主張はどのくらい有効性があるのでしょうか．有効性があるとしても，ドメイン依存だったりしないでしょうか．

私は，ドメインに依存しないような設計法が存在したとしても，それはドメインに最適化された設計法よりも劣ると考えています．なので，ドメインに依存しないような設計法や自動生成法に対して，私はあまり興味が湧きません．（大学院に進学したころはドメインに依存しないような設計法や自動生成法に興味がありましたけど・・・）ドメインに最適化された設計法自体も，新しい技術の採用やドメインの拡大でどんどん変化しているはずです．そのような状況下で勉強不足と経験不足を感じない人はいないのではないでしょうか．勉強不足と経験不足を感じない人がいるとすれば，その人は時代の変化に適応できず進歩がない人だと思います．

勉強不足と経験不足を感じていらっしゃるのであれば，まずはやってみることだと思います．やっているうちに勉強不足だったところを補えるし，経験にもなるでしょう．・・・って，そう言って自分にも言い聞かせていたりしますが．

先日shimashimaさんとこの記事の件で話して，そのあと少し考えていたのですが「正直＝誠実」としてしまうことに無理があるのではないかと思いました．以下，“誠実な対応＝顧客に誠意が伝わる対応”という考え方の立場で述べます．

例えば絶対的にトラブルを起こす可能性が強いプロジェクトがあったとします．始ってから1ヶ月もしないうちにやはり無理があることが確定し，正直に「納期内に間に合わすことが出来ません」と発注側に言ったとします．このとき，どうすれば誠意が伝わるでしょうか．その1ヶ月の間に残業して休日返上して働いた結果，生産された成果物が発注側の想像を超えていて，いかにも「努力してくれた」という認識を与えることができれば誠意が伝わるかもしれません．しかし，努力の痕跡もなく「無理です」と言われても，正直かもしれませんが誠意は伝わらないのではないでしょうか．

先日の話の中で，ACさんの言う『「悪い事柄を正直に言わないほうが傷が浅い」ケース』として具体的な例を挙げましたがこれも同様です．例えば，既にプログラミング工程に入ったときに影響度の大きな仕様追加を依頼されたときの対応です．「契約上，仕様追加は受け入れられない」「今から仕様追加すると納期が延びる」「品質に影響が出る」などと正直に言うこともよいのですが，このような説明だけでは誠意は伝わらないでしょう．こういう悪い事柄は隠し，「この仕様を加えるのであればこの機能も一緒に追加しないと業務効率につながらない」とか「そういう機能はユーザ嗜好に左右されやすいので事前調査した方がよい」などのように，半ばウソの説明をして発注者を納得させて，仕様追加を諦めてもらうほうが互いに傷は浅いと思うのです．ウソであっても誠意が伝わる対応は「プロジェクトのことを大事に扱ってくれている」という安心感を与え，「このプロジェクトが終わったら別途発注しよう」というような発注者側の意識を導く可能性を残します．

まぁ，いずれにしても，shimashimaさんがこの記事を書こうと思ったきっかけのプロジェクトは，早く顧客に「できません」を言うべきだと思いますが．

追伸：冗長性が不要なら，4台のHDDでRAID1+0組む代わりに，仮想OSごとに異なるHDDに配置したほうがパフォーマンスは得やすいでしょうね．管理は面倒ですが・・・．

　ディスクI/Oがボトルネックになりやすいというのはご指摘の通りですね．ディスクI/Oは仮想OSのスワップやESXi自体のスワップでも発生しますので，余裕ある物理RAMの実装と十分な論理RAMの割り当てをお勧めします．
　shimashimaさんはすでにご存じのように，私は仕事で運用系システムとしてVI3を管理している立場ですが，一方の開発で使っているESXiでは，本格的に使おうとするといろいろと面倒な問題に直面しています．以前話題にもなりましたようにUPSの問題があるのですが，ストレージ周りの問題も意外と悩ましいです．
　SATAのディスクでディスクI/Oの問題を改善しようとすると，RAID1+0あたりの活用が一つの解になると思います．そこで，ESXiがサポートしているRAIDコントローラが必要になるわけですが，今度はRAID管理ツールや管理エージェントをESXi上で動かせないという問題が出てきます．たとえばAdaptec製のRAIDコントローラは，ESXi上でASMを使えないことが明記されています．このほか，入手しやすいRAIDコントローラで，ESXiがサポートし，なお且つ管理ツールが使用できるものを探しているのですが，良い製品にめぐり会えていません（※）．
　管理ツールにこだわる理由の一つはHDDが止まった時にアラートを得ることです．上記の制約によりアラートが得られないのであればホットスペアを備えておきたいところですが，RAID1+0で組んでいる場合は5ポート以上のコントローラが必要になるので高価になります．それに，管理ツールが使えないならM/BにオンボードされているINTELのICHxR系のRAIDコントローラで安く済ませたいところですが，現状ESXiは非対応です．
　このあたりを考えると，ESXiよりもVMWare Server，XenやHyper-Vのほうが扱いやすいかなと思っている今日この頃です．

※DELLやIBMなどの主要ベンダーは，自社の管理ツールを埋め込んだESXiを提供しているのでこの問題をクリアしてます．

あ．すみません．ab.さんのやろうとしているのがまさに，RS-232C to USB over IP ですね．しっかり読んだつもりが寝ぼけてました．というわけでもう寝ます．
(-_-; zzz..

USB接続のものはそれでいけるかもしれませんね．同様に，私はRS-232c over IPのもの（たとえばこんなのhttp://strawberry-linux.com/catalog/items?code=36008）に目を付けているのですが，うまくいかなかったときに，それ以外の用途に流用しにくいのが難点だなと考えてます．RS-232c to USB は比較的製品が多く出回ってますので，RS-232C to USB over IP なんて感じでどうかな～とも思う今日この頃です．

自分のX22，最近使っていないので比較的元気なバッテリをお譲りできます．近いうちにバッテリヘルスの状態を送りますので，それを含めて検討してもらってもよいです．