私は、Windows Serverのことはかなり疎いのですが、なんとなくHyper-Vを試してみました。そろそろ知っておかないといけないかな、みたいな感じがしましたので。
CentOS 6などは、当たり前のように快適に動作してしまってつまらないでしょうから、FreeBSD 8.2-RELEASE/amd64 (64bit)をば、インストール。
Hyper-VではFreeBSDは正式にはサポートされていないみたいですね。よく知らずにやってましたが…。
☆
まず、最初のトラブル。
インストールは簡単にできちゃったんですが、ブートしない。ブートローダがBTX haltedというメッセージを出して止まってしまいます。
う~ん、なんじゃこりゃ?!と思いながら検索してみると、仮想ディスクの容量を大きくするとだめで、30GB未満にしときなさい、というようなアドバイスを発見。
そんな馬鹿な、ハハハ、と思いつつも、実際にやってみると、本当でした
☆
2つめのトラブル。
ZFSを試してみようと思って、物理ディスクを数個、SCSIデバイスとして見せてやって、さあzpool create えーと・・・
SCSIデバイスが一切認識されてません。Hyper-VでエミュレートするSCSIって、FreeBSDのGENERICカーネルではサポートされていない、ってことですかね?適当にkldloadしてドライバをロードしてみましたが、全然認識されず。
もういいや、Hyper-VのSCSIは、FreeBSD 8.2Rでは使えない、って思うことにします。
よくよく調べてみたら、物理マシンのほうに、RAIDコントローラがちゃんと存在していたので、そっちのほうでRAID5ボリュームを作成して、それをATAディスクとして見せてやることにしました。
☆
3つめのトラブル。
zfsは、ごく普通に動いているようでしたので、別のホストからネットワーク経由で、ファイルをコピー。
zfs snapshot hoge/fs@20111024
zfs send hoge/fs@20111024 | ssh VM-HOST zfs receive tank/fs
みたいな感じで。
う~ん、遅いなあ。ネットワークもディスクも、かなり遅い感じ。10数年前のサーバー程度の速度でした。さすがに、正式サポートされていないFreeBSDではこんなものですか。
でもって、コピーが終わって、コピーされたファイルを見てたら、I/O errorみたいなものが出ました。どういうこと? と思って調べていくと、コピーされたファイルがいくつか、ぶっ壊れているようです。
- ネットワーク
- ZFS
- ディスク
の、どこかに問題があるだろうと予想して、いろいろ実行条件を変更して実験。
わかりました。原因は、最初のと同じ。
どうやら仮想ディスクの容量が約32GB以上になると、ディスクの内容がぶっ壊れるようです。仮想ディスクのサイズを固定で割り当てても、同じように問題発生するようです。
数多くある「ディスク容量の壁」で、確か32GBにも壁があったような気がしますが、Hyper-Vでも、忠実にそれをエミュレートしてくれているんでしょうか?それともFreeBSDのカーネルがバグってる?
☆
こんな感じで、動作確認しました。
ATAなディスクは、こんな風に認識されています。
# atacontrol list
ATA channel 0:
Master: ad0 <Virtual HD/1.1.0> ATA/ATAPI revision 0
Slave: ad1 <Virtual HD/1.1.0> ATA/ATAPI revision 0
ATA channel 1:
Master: ad2 <Virtual HD/1.1.1> ATA/ATAPI revision 0
Slave: ad3 <Virtual HD/1.1.1> ATA/ATAPI revision 0
# diskinfo -v ad1
ad1
512 # sectorsize
34359214080 # mediasize in bytes (32G)
67107840 # mediasize in sectors
0 # stripesize
0 # stripeoffset
16448 # Cylinders according to firmware.
16 # Heads according to firmware.
255 # Sectors according to firmware.
# Disk ident.
ZFSなファイルシステムを作成。
# zpool create disk32 ad1
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
disk32 31.8G 75K 31.7G 0% ONLINE -
# zfs create disk32/test
適当にファイルを書き込んでみる。
# cd /
# tar cf - usr | tar xf - -C /disk32/test/
とりあえず確認。
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
disk32 282M 31.0G 22K /disk32
disk32/test 282M 31.0G 282M /disk32/test
scrubを実行。
# zpool scrub disk32
しばらく(数秒でOK)待ってから
# zpool status
pool: disk32
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h0m with 5763 errors on Mon Oct 24 16:50:45 2011
config:
NAME STATE READ WRITE CKSUM
disk32 ONLINE 0 0 5.63K
ad1 ONLINE 0 0 13.3K 1.60M repaired
errors: 5746 data errors, use '-v' for a list
Wow !! ぶっ壊れました。
☆
仮想ディスクの容量を31GBにしてみて、同じことをもう一度やってみます。
# diskinfo ad1
ad1
512 # sectorsize
33285611520 # mediasize in bytes (31G)
65010960 # mediasize in sectors
0 # stripesize
0 # stripeoffset
64495 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
# Disk ident.
# zpool create disk31 ad1
# zfs create disk31/test
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
disk31 100K 30.3G 21K /disk31
disk31/test 21K 30.3G 21K /disk31/test
# cd /
# tar cf - usr | tar xf - -C /disk31/test/
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
disk31 261M 30.0G 22K /disk31
disk31/test 261M 30.0G 261M /disk31/test
# zpool scrub disk31
# zpool status
pool: disk31
state: ONLINE
scrub: scrub completed after 0h0m with 0 errors on Mon Oct 24 17:02:15 2011
config:
NAME STATE READ WRITE CKSUM
disk31 ONLINE 0 0 0
ad1 ONLINE 0 0 0
errors: No known data errors
31GBなら、大丈夫みたいです。
てゆーか、そんなの使えるかー!
☆
FreeBSDを使いたいなら、VirtualBoxですかね。
☆
(2011-10-25 追記)
FreeBSD 9.0-RC1で試してみたら、1TBほどの仮想ディスク(物理ディスクをそのままVMに見せてる)でも、ZFSがぶっ壊れることは無かったです。
ただし、NFSがささってどうしようもなくなりました(NFSサーバが8.2R、NFSクライアントがHyper-Vの中の9.0-RC1で、amdを利用)。FreeBSD9.0からnewnfsというのに変わったせいでしょうか。
それからSCSIのディスクは、相変わらず認識されず。PCIデバイスとしても見えていないので、きっとHyper-V専用のドライバがVM側に必要なんでしょうね。
レガシーじゃない方のイーサネットが認識されないのも、きっと同様な理由と思われます。