FreeBSD on Hyper-V

FreeBSD 10.0-RELEASE で各種仮想化対応が GENERIC カーネルに入ったことにより、カスタムカーネルを作らなくても freebsd-update で仮想化対応カーネルが利用できるという、非常に楽な感じになってくれました。

とはいえ、旧来環境を何も考えずにアップデートすると 2 箇所ほどハマる点があります。

ネイティブネットワークアダプターを利用する場合

Hyper-V のネイティブネットワークアダプターが利用できるようになりますが、これを利用する際、ガシーネットワークアダプター (de) からネイティブのネットワークアダプター (hn) に名前が変わるため、この点に注意する必要があります。

最低限 rc.conf で hn0 などへアドレスを付けることとなるかと思いますが、Hyper-V マネージャーなどからレガシー NIC を削除せずに起動する場合、依然として de が残ることとなります。

このため、アドレスの付け替えは再起動後に hn が生えていることを確認してから、一括で行った方が諸々簡単な感じです。

また、アドレスの付け替え以外にも、ファイアウォールのルールの他、例えば munin などで NIC のトラフィックやエラー状況を監視している状況などがあり得ます。

場合によっては IPv6 アドレスで ff02::1%de0 などのような指定があったり、daemon に割り付けるアドレスを「特定のインターフェースが持っているアドレス」としている場合もあるかもしれません。

こうした部分の変更を忘れると、監視系からエラーが飛びまくるなどの悲しい状況が発生します。

パーティションが見つからなくなる

Hyper-V ストレージ統合サービスをインストールすると (GENERIC カーネルで起動すると)、ストレージのデバイス名が変わる場合があります。この結果、kernel を読み込んだ後にパーティションのマウントに失敗します。

FreeBSD Integration Services for Hyper-V を見ると fstab を UUID ベースで指定する必要がある、ということとなっています。

が、実は良く見ると SCSI ストレージとしてアタッチされているので、ada0 なら da0 にするだけでも通ったりします。

dmesg 的にはこんな感じ。

da0 at blkvsc0 bus 0 scbus1 target 0 lun 0
da0: <Msft Virtual Disk 1.0> Fixed Direct Access SCSI-4 device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 204800MB (419430400 512 byte sectors: 255H 63S/T 26108C)

Hyper-V マネージャー側で IDE コントローラーの下に HDD をぶら下げていても da0 にアタッチされるので、Hyper-V マネージャーでコンソールを開けない状態でこの辺りを弄らずにうっかり再起動すると、かなり悲しいことになる可能性があります。

FreeBSD 11 on Azure のポイント

いやまぁ 10.3-R とかでも立ち上げてたけど、11.0-R でごりっと立ち上げたりした上でのポイントまとめとして。

  • とりあえず最初に pkg upgrade はしよう
  • sshd の listen port 変える場合は穴開けよう
  • パスワード設定されてないので wheel への追加と sudo passwd と sudo passwd (user) はしておこう
  • /etc/localtime はないよ

イメージを展開した直後にインストールされているパッケージはちょっと古いので、やっぱり pkg upgrade は必要な感じですね。

freebsd-version は 11.0-RELEASE-p10 だったから問題ないのだけど、うーん。(笑)

「security log 的にうぜー」という気持ちで sshd の listen port を変える場合、Linux 仮想マシン (扱い) は基本的に 22 番しかポート開いてないので、しっかり開けましょう。大事。

deploy 直後のイメージだと、(おそらく普通に作る) SSH 公開鍵認証の場合、ユーザーのパスワードは「非公開」とかになってるので、しっかりパスワードを設定しておかないと……うっかり freebsd-update upgrade のついでに pkg delete -af とかしたい気分になったときに「ちょ、sudo 使えない!」でハマります。wheel にも入ってないので、当然 su - root とかもできません。

「その時は仮想マシンごと壊せばいいや」で済むならともかく、済まなそうな事をするなら、しっかり sudo passwd で設定しておきましょう。

済む形にまとめられるのが (クラウド環境的には) 最善だとは思いますが、一応。

/etc/localtime がない (= 基本 UTC) ってのは、共通イメージ的には基本だし当然ではあるのだけど、穴と言えば穴なので、気にしておかないとハマる点ではあります。

/etc/mail/aliases の root なりをしっかり書き換えてホストレポート受信してれば「あれ、こんなタイミングで来るの?」とかで気付きやすい点ではありますが。

localtime をしっかり見て欲しいなら (日本の場合は) 'sudo cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime' ですね。(/usr/share/zoneinfo 以下は必要に合わせて調整で)