読者です 読者をやめる 読者になる 読者になる

きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

Trac Lightning と VMWare

VMWare上で、リポジトリを持つときは、
こういうことも考えたらどうだろう。
今日はそんな日記。


貧弱なPCにWorkstation入れて動かしてます。
なぜESXじゃないのかは知らない。
たぶんSANを用意するのが面倒だからかな。


ホストOSのディスクも、
ゲストOSのディスクも一杯。
あー、困った。


いまはホストもゲストも2003server。
ゲストにはCドライブしかない。
Trac Lightningを含め全部がCドライブ。
もうちょっと後先考えて作っといてくれやー。


そんなこったで後先を考えてみた。
ダイナミックボリュームを採用するべ。


新しいパソコンを用意。
(HDD増設でもいいけど)
ゲストOSのVMをコピー。
まあ、バックアップ用もどこかに残す。
VMに新しい仮想ディスクの追加。
ゲストOS上でダイナミックボリュームにする。
Trac Lightningの一部を新パーティションへ引越し。


今後svnが肥大化したならば、
vmware-vdiskmanager.exe
の-xを使って拡張して未割当領域を作り、
ゲストOSでボリュームの拡張をする。
当然だが、-xで増やすのは、
ダイナミックボリュームにした仮想ディスクだ。
ダイナミックボリュームではない場合、
サードパーティーのパーティショニングツールが
どうしても必要になってくるのでウザい。
タダもしくは保有してるライセンスの範囲内で使える方法がいい。


trac+svnのデータは、
ダイナミックボリュームに置こうぜ。
ダイナミックボリュームについては、
DiskPart.exeってキーワードでも調べられる。
これは、古いWindowsにはいない。
XPと2003server以降だったかな。


データの引越しは、
まだどうやるのか試してないが、
確かそれらしきpyが居たはず。
今後試して覚えてたら日記に書いておこう。
ちょいと古いバージョンのTrac Lightningなので
書ける情報は無いかも知れないが。。。


データの引越し以外の箇所は実験済。
性能的なことは評価してない。
ボリュームを拡張すると言っても、
svnの成長見合いなので、
数年に1回の頻度で数十GBを割当てるつもりだ。
大事なデータなんだから、
長いこと使える構成がいいよ。


ちなみに、システムボリュームは、
ダイナミックボリュームに出来ない。
ダイナミックボリュームのメリットデメリットはあるんだろうけど、
ほとんどhttpでしかアクセスしないのだから、
ぜんぜんOKだって。


ワガママを言うと、
別ハードへのバックアップもせねばならんから、
今後SMB2.0で通信することを期待して、
2008serverにしたいところだが、
僕らが使ってるライセンスだと
やや問題がありそう(数に限りが)なのと、
VM作るのが面倒だからやめた。
それにバックアップ先のTerastationが、
SMB2.0で会話するのか分からなかったから。
まあ、Vistaでアクセスして、
パケット覗けば分かるんだけども、
Vista入れるのが面倒だったからやーめた。


ほんと面倒臭がりですみません。