VMWare上のWindows環境をQemu+KVM上に移行する

debian linux kvm

まず、VMware上でvmware-toolsをアンインストールし、mergeide.regを実行しておく。

これをやる前に元環境壊しちゃったので、MacのVMWare Fusionからsamba経由でvmx読んできてがんばった。

qemu-img -O qcow2 -c xpclean.vmdk xpclean.img
virt-install --connect qemu:///system --name xpclean --vcpus=1 --ram 512 --os-type=windows --os-variant=winxp --import --disk /vm/xpclean/xpclean.img --network bridge=br0,mac=hogehoge --graphics vnc,port=5903 --noautoconsole

一回起動して確認。

あとはデバイスドライバをいれる：http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

仮想cdrom、virtioなnic, usbパススルー設定を追加

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/vm/isos/virtio-win-1.1.16.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>

    <interface type='bridge'>
      <mac address='asdffdsa'/>
      <source bridge='br0'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x04f9'/>
        <product id='0x01e9'/>
        <address bus='3' device='2'/>
      </source>
    </hostdev>

Qemu+KVM環境をdebian squeeze上に構築する

debian linux kvm

6年前ぐらいから使っている自宅サーバのVMイメージが度重なるdebianのdist-upgradeで壊れてきて、cronが自動で起動しなくなったりイミフな状態になっている。あと外向きサーバだったはずなのにいつのまにか内向きのサービスも走ってたりしてセキュリティ的にも良くない。

また、ハードウェアの移行に耐えられるようにVMWare Server2上の仮想化で動かしているのだけれど、
仮想化コンソールがよく固まってとても気軽にVMを建てたりできる環境ではないので、最近流行のqemu+kvm環境でVMホスト環境ごと再構築する。

参考資料：
http://wiki.debian.org/KVM

VMホストは最小限のdebian stable(squeeze)をいれる。あえてvirt-managerなしでトライ。

続きを読む

log書き込みてすと

linux

fdatasync(2) やっぱおそいよ。

timeは数回はかって最短のものをかいた。

$ wget http://static.nyaxtstep.com/misc/log.c
$ gcc -DALLOC_FALLOCATE -DSYNC_FDATASYNC log.c -o log_falc_dsync
$ gcc -DALLOC_FALLOCATE -DSYNC_SYNC_FILE_RANGE log.c -o log_falc_sfr

# ext2 
$ sudo mkfs.ext2 -b 4096 -E stride=32,stripe-width=32 /dev/sdd1
$ sudo mount /dev/sdd1 /work/ssd -onoatime

$ time ./log_falc_sfr ~/work/ssd/logtest 10000
real	0m2.499s user	0m0.000s sys	0m0.132s
$ time ./log_falc_dsync ~/work/ssd/logtest 10000
real	0m2.923s user	0m0.004s sys	0m0.136s

# ext4 (journal遅延書き込み)
$ sudo mkfs.ext4 -b 4096 -E stride=32,stripe-width=32 /dev/sdd1
$ sudo mount /dev/sdd1 /work/ssd -odata=writeback,noatime,commit=30

$ time ./log_falc_sfr ~/work/ssd/logtest 10000
real	0m2.473s user	0m0.000s sys	0m0.128s
$ time ./log_falc_dsync ~/work/ssd/logtest 10000
real	0m3.186s user	0m0.000s sys	0m0.132s

blktraceログはこちら：http://static.nyaxtstep.com/misc/blktraces.tar.gz

ログをみてみたかぎり、このサンプルプログラムだとメタデータ部分への変更はfdatasync/sync_file_rangeともにしていない。
fdatasyncのほうが無駄にでかい領域をwriteしているようにみえるしこの辺が速度差か。

後このプログラムだとext2/4で差がないのに対し、開発中のログ構造化ストレージでは11倍ぐらいext4のが遅くなるのも謎。
追記： sync単位が4kか128kかの違いぽいですね。4k単位のfdatasyncをext4でやると超遅い。

sync_file_range用の領域を確保する。

linux

確認にはColin King氏のfiemap.cを使わせてもらった。

1. ftruncate(fd, size)

sparseファイルができるだけ。データブロックの確保はされず

2. pwrite(fd, "", 1, size-1);

samba hack! sambaがファイルを書き込む際、領域予約するのにつかってる？でもNFSしか効果ないぽい？

ext2ではsparseファイルで最後のブロックが確保されるだけ。

3. b = malloc(size); pwrite(fd, b, size, 0);

データブロック確保されてる！でもなんかmallocが邪魔。

4. fallocate(fd, 0, 0, size);

データブロック確保されてるしmalloc排除できた...! でもext4じゃないと動かない

5. posix_fallocate(fd, 0, size);

せいかい。なければ3にfallbackする方針で。
追記：straceみてる限りファイルシステムのサポートがない場合は2にfallbackしてるみたい？