元祖ワシ的日記

ホストであらかじめbridgeやtapを作っておく

/etc/rc.conf:

cloned_interfaces="tap0 bridge0"
autobridge_interfaces="bridge0"
autobridge_bridge0="re0 tap*"
ifconfig_bridge0="up"

diskイメージを作成しmdconfigでmd0にattachしてパーティションなどをつくっていく

# truncate -s 10G diskdev
# mdconfig -a diskdev
# gpart create -s gpt md0
# gpart add -b 40 -s 64K -t freebsd-boot -l boot0 md0
# gpart add -s 1G -t freebsd-swap -l swap0 md0
# gpart add -t freebsd-ufs -l disk0 md0
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 md0

ファイルシステムの作成/マウント/コピー

# newfs /dev/md0p3
# mount /dev/md0p3 /mnt
# tar cfzp - -C /SOURCE-DIR . | tar tvfp - -C /mnt

guestを起動させるには /etc/fstabを設定する必要がある。tarでパッケージを展開しただけやjailからコピーした場合は/etc/fstabは存在しないので作ってやる必要がある。

先程gpartで作成したパーティションでは

• 起動パーティションにはdisk0
• swapパーティションにはswap0

というラベルがついているので次のように書いておけばよいだろう

/mnt/etc/fstab:

/dev/gpt/disk0 / ufs rw 1 1
/dev/gpt/swap0 none swap sw 0 0

/etc/rc.confにて sshd等を起動するようにしておかないと淋しいことになるので、設定をしておく。自分の環境ではこんな感じ。

/etc/rc.conf:

hostname="test"
ifconfig_vtnet0="DHCP"
ifconfig_vtnet0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"

bhyveをコマンドラインから起動したあとにその端末を consoleとするように/etc/ttysを書換えておくとなんかあったときに楽

/mnt/etc/ttys:

console "/usr/libexec/getty Pc"         vt100 on secure

作業が終了したので /dev/md0を unmountする

# umount /mnt

vmrun.shを使って起動してみる（/usr/share/example/bhyve/の下にある）

# ./vmrun.sh -d diskdev vm0

こんな感じに起動した

railsはほっとくと大量のディレクトリとファイルをtmp/cachesの下に作るんでファイルだけは30日程度で消してました。これでファイルはすっきりするんですがこのファイルは123/456のような3文字/3文字のディレクトリを掘ってその下にファイルを置いてるため空のディレクトリも大量に存在してることに気がつきました。これが大量にあるとゴミ掃除が遅い・・というわけで空のディレクトリを削除する方法です

find . -type d -empty -print -exec rmdir {} \;

-emptyとか便利なオプションがあるんですね・・しかしこれだとディレクトリを削除したあとにそのディレクトリを辿ろうとするので

find: ./E0D/C70: No such file or directory

とか出てしまいます。

depth firstアルゴリズムにするのがおすすめ

 find -d . -type d -empty -print -exec rmdir {} \;

これですっきり

inodeを2%くらい減らす効果はあったようで

FreeBSDでqemuを使うためのメモ。基本的にはここのwikiを参考にしています。

基本

1) パッケージのインストール

# pkg install qemu

2) /boot/loader.confに以下の4行を追加する

if_bridge_load="YES"
bridgestp_load="YES"
if_tap_load="YES"
aio_load="YES"

再起動しておしまい。再起動が嫌ならkldloadでモジュールを読み込ませるとよいかと。

3)適当な起動可能なゲストのCDのimageを用意して起動させて動くのを確認する

以下の例ではFreeBSD-9.0のimageを使用しています。

# qemu-system-x86_64 \
-hda vm00.img -m 1024 -monitor telnet::4444,server,nowait -vnc :0 \
-cdrom Images/FreeBSD-9.0-RELEASE-amd64-disc1.iso 

確認は適当なvncclientで

% vncviewer localhost

とかやればOKです。

応用

動かすだけならこれでもいいのですが、これだけですとHostがDHCPサーバ＆ルータになり、ゲストと外界が遮断されている状態なので、もうひと捻りします。具体的には bridgeとtapデバイスを使って、ホスト側からのパケットをゲスト側にも持ってくるという作戦。

4) /etc/sysctl.confに以下の２行を追加

net.link.tap.up_on_open=1

これは tapデバイスがopenされたとき自動的にupするというものの設定らしいです。設定しなくてもqemu起動する度に ifconfig tap0 upとかしてやればいいのですが、煩雑なので設定しておいたほうがよいでしょう。

5) /etc/rc.confに以下の3行を追加 (re0は使用しているNICの名前に適宜読み替えてください）

cloned_interfaces="bridge0 tap0"
autobridge_interfaces="bridge0"
autobridge_bridge0="re0 tap*"
ifconfig_bridge0="up"

cloned_interfacesにbridge0と書いただけでは bridge0がupされた状態でやってこないので、ifconfig_bridge0="up"を書いています。もっとスマートな手法があるかもしれませんが。ここまで設定したら念のため再起動します。これも再起動が嫌だというひとは4の設定も含めてsysctrlやifconfigで自力で設定するという手法もあります。

6) 適当な起動可能なゲストのCDのimageを用意して起動させて動くのを確認

qemu-system-x86_64 -net nic -net tap,name=tap0,script=no \
-hda vm00.img -m 1024 -monitor telnet::4444,server,nowait -vnc :0 \
-cdrom Images/FreeBSD-9.0-RELEASE-amd64-disc1.iso

VNCで起動を確認し、LiveCDやshellに移行し dhclient ed0等するとDHCPサーバからアドレスが振られるのがわかるかと思います。

どうも現状のportsだと、glib20は /usr/local/include/iconv.hがあれば使わないようにconfigureしても絶対それをincludeしちゃうようです。なら gnuのiconvを削除すればいいんじゃね？と思ったわけですが、libiconvを pkg remove -fで削除したら（当然ながら）いろいろなモノが動かなくなり、それでもまぁもっかいビルドすればいいかと思ってたんですが、portsそのものがコンパイルできなくなるという状態に(pythonとか動かないので）。これはいかんと、いうことで　zfs rollbackで戻しました。いずれiconvは削除できるのは削除するという方向にして、 とりあえずは /usr/local/include/iconv.hだけを別名に renameして glib20をごまかしてやることにしました。（あとで忘れそうだな

この状態で

portmaster -a -w -d

としたら、大部分がリビルドできるように。たまに出るエラーは手動で修正。大抵は依存関係の問題なんで、先に別なほうをビルドしちゃえばOKですが（めんどうくさいw

全部まっさらにして入れ直したほうが早かったかなー？しかしFreeBSD8から継ぎ足して使ってきた秘伝の・・・（略

いくつか標準から外れたものがあるようだ。とりあえず cvsは消えてくれてサンキューだが、digは無いと困るので入れた。

portsのリコンパイルはportmasterにお任せなんですが、それでもiconv関連で以下のようなメッセージが出て、

error: GNU libiconv not in use but included iconv.h is from libiconv

エラーで止まって悩みました。

これ以前別のプロジェクトでもハマったんだよな。おそらくconstがついてるか否かとかそういう（些細な）問題だったような記憶があるけど、これは古い何かと何かがかち合って、何かと何かのiconv.hの宣言がかみ合ってないのか？まずはググるが、適切な回答みつからず。しゃーないから自分で調べる

/usr/ports/devel/glib20のMakefile

を眺めると

ICONV_LIBというのが定義されていると、 configureに  --with-libiconv=gnuが渡されるようである。エラーで止まったあとに workの下で ./config.statusしてみると

# ./config.status --config
'--enable-static' '--disable-gtk-doc' '--with-html-dir=/usr/local/share/doc' '--disable-man' '--without-xml-catalog' '--with-pcre=system' '--disable-fam' '--disable-dtrace' '--with-libiconv=native' '--disable-modular-tests' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd10.0' 'build_alias=x86_64-portbld-freebsd10.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing' 'LDFLAGS= -L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include -DLIBICONV_PLUG' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG' 'PKG_CONFIG=pkgconf' 'PYTHON=/usr/local/bin/python2.7'

と、nativeなiconvを使おうとしてるので、これが効いていないっぽい。devel/glib20/Makefileを強引に gnuを使うように書き換えたらちゃんとコンパイルが通った。

つまるところ、nativeな iconvを使おうとしてるのに /usr/local/include/iconv.h をincludeしているのがよくないのであろう。ここまではわかった。

コンパイラのインクルードパスを見る順番という問題な気もするが、iconvを全削除して、portsをリビルドするとうまくいくような気もする？それはそれでいろいろ別な問題が発生するような気がするが、さてどちらの対処でいくかべきか？

放置していたFreeBSD RELEASE-10へのアプグレードですが、OSはほぼ問題なく移行できました。まぁ問題はその後の設定なんですけどね。

• jailの起動でいろいろ言われるので、警告どおり jail.confに書き換える
• パッケージ管理システムがpkgへ移行したのでpkg2ngでコンバート（なにやら色々と嫌な感じの警告が沢山でてる）

とりあえずここまで。あとlinux関係のモジュールでいくつかエラーが出てたのう・・・

9.1まではこちらの記事にあるこちらのパッチが適用できたのですが、9.2からは数ヶ所rejectされるようになってしまいました(ちなみに /usr/ports/net/stf-6rd-kmodから入れても同じようなことになるような感じ）

なので手動でセコセコ直す作業が発生。疲れた～。 一応sakuraのVPSではちゃんと動いているようです。 疲れたついでに9.2用のパッチをここにおいときます。

前は/etc/rc.confに

jail_sysvipc_allow="YES"

としとけば動いたんですが、9.2からは

jail_jail171_parameters="allow.sysvipc=1"

のように書かないとダメっぽい。これ以上詳しくは追ってない・・

cannot start jailと出て起動しなく。手動では起動するので/etc/rc.d/jailが何か変更になったぽい。で追っていくとIPv6の指定の仕方が不味いということに気がつきました。パラメータのIPのリストをみてIPv4のときはip4.addr, IPv6のときはip6.addrで指定するように変わったようです。で、/etc/rc.confには以下のようにかいていたのですが

jail_jail171_hostname="jail171.jail"
jail_jail171_ip="192.168.253.171,2400:XXXX:100::192.168.253.171"
jail_jail171_rootdir="/jails/jail171"
jail_jail171_procfs_enable="YES"
jail_jail171_devfs_enable="YES"
jail_jail171_exec_start="/bin/sh /etc/rc"
jail_jail171_exec_stop="/bin/sh /etc/rc.suhtdown"
jail_jail171_mount_enable="YES"

2400:XXXX:100::192.168.253.171が *.*.*.*にマッチしてしまいIPv4のアドレスだと思われてしまうようです。故に全部:で区切って書けば問題なさげです。あるいは/etc/rc.d/jailの以下の部分:

    # Identify type {inet,inet6}.
    case "${_addr}" in
    *\.*\.*\.*)     _type="inet" ;;
    *:*)            _type="inet6" ;;
    *)              warn "jail_extract_address: type not identified"
                    ;;
    esac

これを

    # Identify type {inet,inet6}.
    case "${_addr}" in
    *:*)            _type="inet6" ;;
    *\.*\.*\.*)     _type="inet" ;;
    *)              warn "jail_extract_address: type not identified"
                    ;;
    esac

とするとよいようです。

起動して何かしようとすると、

VirtualBox cannnot talk to klauncher Not connected to D-Bus server. FreeBSD

のようなエラーが出て動かないという。まさかファイルのダイアログが開けなくて動かないとか・・・うーん。

で、検索してみると、このあたりがズバリそれのようです。

[Solved] DBus running but not working - The FreeBSD Forums

上のリンクを読んでみると分かる通り解決方法はdbusのダウングレード。何か負けてるような気もしますが、詳細を追ってる時間がないのでオイラもそれに習いダウングレードで解決を目指すことにしました。負け犬。

ダウングレードは古いソースをもってきて自分でmakeしてinstallすればいいんですけど、どうせならportsで管理しておきたいところ。そこで、 portdowngadeとportmasterでダウングレードすることにしました。portdowngradeは /usr/ports/ports-mgmt/portdowngrade/にあるのであらかじめ installしておきます。

ちなみにこのブログ書いてる時点でdbusのバージョンは 1.6.12 です。このバージョンがinstallされていると仮定します。

# portdowngrade devel/dbus

とやるとdbusの更新履歴がずらずらと出てきます。見ると

r312209

が 1.4系の最終バージョンのようなので、このときのportsのディレクトリをチェックアウトしてきます。

# cd /home/hoge
# portdowngrade devel/dbus 312209

このチェックアウトは/usr/portsの下とかでやらないほうがよいでしょう。自分のホームディレクトリとかでやります。するとdbusというディレクトリにr281729のportsのdbusのディレクトリが現れます。

その後

# portmaster -w -o <dbusを展開したディレクトリ> /var/db/pkg/dbus-1.6.12

とやります。これでdbusを再起動したら大体動いているようです。もっとも他のdbusを使うpkgはdbusのバージョンが1.6.12だと思ってるから何か予期せぬ問題が発生するやもしれませんけどね・・・まぁそんときはそんときということで。とりあえず今は何事もなく動いているようです。