2月 052024
 

以前のエントリで「bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する。」と、いうエントリを書きました。そして、一個前のエントリ「NiPoGi GK3Pro ミニ PC 購入。」では MINI PC には VMware ESXi ではなく bhyve で仮想環境を構築した。と、書いています。

bhyve は基本的にコマンドをチマチマ打っていく状態だったので『GUI で簡単に仮想サーバ構築とかできないのかなぁ?』と思って探してみるとあるようですねぇ。 FreeBSD の ports にはなっていないようですが、GitHub からダウンロードできるようです。

https://github.com/DaVieS007/bhyve-webadmin

ここから bhyve-webadmin-master.zip をダウンロードして展開します。
今回ダウンロードしたのは BVCP という bhyve をウェブベースの GUI で管理できるものになります。
インストール先の FreeBSD では bhyve の環境が整っている必要があります。上記の「bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する。」のエントリ中の『1. FreeBSD 母艦側の設定』の部分の設定をまず先済ませておく必要があります。

 
1.インストール
展開後にその中にある install.sh を実行します。以下、簡単なテキストキャプチャです。
指定するのは唯一データを管理するディレクトリを指定するのみです。今回は /opt/bhyve を指定しました。

# unzip bhyve-webadmin-master.zip
<略>
# cd bhyve-webadmin-master
# ./install.sh

                    ██████╗ ██╗   ██╗ ██████╗██████╗ 
                    ██╔══██╗██║   ██║██╔════╝██╔══██╗
                    ██████╔╝██║   ██║██║     ██████╔╝
                    ██╔══██╗╚██╗ ██╔╝██║     ██╔═══╝ 
                    ██████╔╝ ╚████╔╝ ╚██████╗██║     
                    ╚═════╝   ╚═══╝   ╚═════╝╚═╝     

            Bhyve Virtual-Machine Control Panel under FreeBSD
        
 N  2024-02-05 09:38:25 | BVCP | Initialising BVCP-Backend 1.9.8-p9 Application

  [>] Generating Entropy ... [9BA2FE3E0EC4B6D72CF2E6760FF5B0AA]

 Welcome to initial setup menu!
 The Software is located at: /var/lib/nPulse/BVCP

 The Software is producing pseudo filesystem scheme for virtual machines using symlinks
 Where to create metadata, iso_images, database, config, logs: (Does not need much space), default: [/vms]_> /opt/bhyve
<略>
 N  2024-02-05 09:40:08 | BVCP | Initialising BVCP-Backend 1.9.8-p9 Application
 N  2024-02-05 09:40:10 | BVCP | Starting Database ...
 (!) Admin Credentials recreated,
   - User: admin
   - Password: LmZH4kXD

 N  2024-02-05 09:40:10 | SW | Program exited gracefully...
Installation Finished!
Navigate: https://[your-ip]:8086
#

 
BVCP のデータ管理用ディレクトリを指定してインストールすると上記のようになって終わります。ウェブログインするパスワードが表示されているので覚えておきましょう。

インストール先についてですが、以下のようになっています。

  • BVCP のベースプログラムは /var/lib/nPulse/ にインストールされます
  • /etc/rc.conf に bvcp_enable=”YES” という文字列が追加されます
  • /usr/local/etc/rc.d/ 内に bvcp-backend bvcp-frontend bvcp-helper の三つのファイルが追加されます
  • データ保存先の /opt/bhyve/ が作成されます

 
上記のディレクトリ、ファイルを全て削除することによりまっさらな状態(uninstall した状態)となります。

 
2.仮想マシン作成前の準備
インストール後ウェブブラウザから https://wanchan.running-dog.net:8086 などとアクセスします。

インストール時に控えていた admin とそのパスワードでログインし、まずは右上をクリックしアカウントの管理として Account Settings から自分のメールアドレスを登録しましょう。

 
新規にアカウントを作成したら admin をログアウトして、新しいユーザでログインし直してと。
仮想マシンが利用する HDD イメージを保存するストレージを指定します。大容量のディレクトリを指定しましょう。

NFS 領域も指定できます。Active 系 bhyve 母艦がダウンすると NFS 上にゲスト OS のイメージがあるので Standby 系を Active にしてゲスト OS を起動できたりするので冗長構成が取れそうですね。

 
次にネットワークを設定します。
VLAN などの設定は母艦の FreeBSD 側で先に設定しておく必要があります。必要であれば設定しておきましょう。この辺り VMware ESXi 的に言うと vmnic0 に VLAN 単位の vSwitch を生成して、それを仮想マシンで利用する。みたいな雰囲気ですね。
母艦の FreeBSD が利用できないネットワークインターフェースは当然 bhyve でも利用できません。
pptdevs 経由で仮想マシン側にデバイス渡したくても BVCP の UI にデバイスを渡すオプションは今のところ無いようです。

ネットワークを作成する場合は em0 とか re0 などを一個含めておくと、bridge300 番台を生成してくれます。母艦側の FreeBSD の VLAN インターフェースも指定可能です。
その後、仮想マシンを作成したタイミングで tap300 番台を自動生成してくれ、かつ、それを bridge として追加してくれるようになります。
母艦側の NIC を含めないネットワークを作成すると、それは裏 LAN 的な、外に出ていかないネットワークとなります。

これで、アカウント・ストレージ・ネットワークの設定が完了しました。

 
3.仮想マシン作成
ここまで来たらいよいよ仮想マシンの追加をします。一番最初は OS の雛形を指定することになります。

対応している OS は FreeBSD・Linux・Windows になります。まぁ、それだけあれば十分か? macOS は FreeBSD かな?デバイスの形態が全く違うけど・・。 VyOS は Linux ですな。では Solaris は? まぁ、その話は置いといて・・f(^^;;。

雛形を作成したら次に作成した OS を選択して詳細を設定していきます。まぁ、GUI なので直感的に設定ができますよね。

色々細かい設定とかありますが、まずは OS をインストールしなければならない。
Virtual Hardware のところでは CPU 数やメモリ容量の変更ができます。

インストールのために CD-ROM Drive を指定します。ISO イメージを、データを管理するディレクトリ内に設置します。今回の環境での場所としては /opt/bhyve/iso_images/ になります。このディレクトリ内に保存します。

次に HDD イメージを作成します。登録したストレージ内に必要な容量を選択します。
その次に追加された HDD イメージの詳細設定を行います。

Name / Description は書いておいたほうが良いでしょう。 LUN Slot は気分的な設定値ですが、仮に HDD を複数接続したときに番号をずらしたほうが良さそうな雰囲気ですよね。
Attach Disk にチェックを入れると OS 側で HDD を認識するようになります。

作成した HDD は 今回の環境では NFS 領域の /media/Strage/ に vm_images というディレクトリが作成され、その中に格納され /media/Strage/vm_images/ubuntu01_disk01.img になります。 仮想マシン登録時に指定した Machine Name の ubuntu01 (小文字になる)と Name / Description で指定した disk01 を合わせたファイル名になります。

最後にネットワークを指定します。
自分が接続したいネットワークの指定と、ドライバを指定します。ドライバは FreeBSD 的に言うと vtnet0 と em0 の二つが選べます。 WindowsOS をインストールするときは Intel Pro 1000 を指定したほうが良いかもです。

 
これで設定がぜんぶ完了しましたかね。

 
4.いよいよ起動
では左上にある緑色の Start ボタンを押しましょう。そして起動後に現れる VNC Console をクリックすると別ウィンドでコンソールが表示され OS がブートするところを確認できます。その後 OS のインストールを進め、再起動してインストール完了。
apt -y update などで最新の OS 状態にしたり apt-get install でパッケージを色々インストールして最低限の環境を構築すれば良いですね。

ここで一旦 OS を停止して /media/Strage/vm_images/ubuntu01_disk01.img をバックアップしておけば、もう一個 OS を作成したいときにタネ用 HDD として利用できます。
新規に ubuntu02 とかを作成するときに Create Virtual Disk のところでうまいこと指定することができます。

あと、起動時に毎回コンソールに入る状態になっているのですが、一番上の Options の中の Wait for console: を No にすると、コンソール画面を開く必要はなくスルっと起動するようになります。

 
自分で作成した環境で、コマンドベコベコ打って仮想マシンを作成していたとき、WindowsOS は中々起動できなかったのですが BVCP を利用すると簡単に起動させることができます。
母艦側には潤沢な資源が必要になりますが、僕が試してみたところ Windows11 Pro と Window Ssever 2019 が起動できて動作しています。
まぁ、Windows11 の場合は BypassTPMCheck と BypassSecureBootCheck は必須になりますが、ここでは省略します;-)。

とまぁ、比較的簡単に bhyve を利用したウェブ UI の仮想環境が構築できました。

 
今回の BVCP を利用した bhyve 環境は、新規の仮想環境の構築となります。今までコマンドベースで自分の趣味を反映した bhyve 環境で用意したモノを再利用しようとしてもほぼ利用できません。
例えば BVCP 環境下で作成した FreeBSD のディスクイメージを自分がコマンドベースで作成した bhyve 環境に持っていって起動しようとしても、ブート時のデバイス認識のところでエラーになって起動しなかったりします。その逆もしかりです。

今までのコマンドベースで構築した環境・仮想マシンを捨てて、新しく BVCP 環境に移行するか、コマンドラインベース環境と同居するか悩みます。が、やっぱ GUI 環境のほうが楽だね。になると思いますが・・f(^^;;。

 
5.そろそろエンディング
前回のエントリでは Intel Celeron N5105 な NiPoGi GK3Pro ミニ PC で VMwareESXi が動作しないような環境(動作したとしてもデバイスを認識しないような PC の構成)においても FreeBSD が動作するのであれば bhyve による仮想環境が構築可能である。と記載しています。
そこに今回 GUI ベースで bhyve を動作させることにより、ますます bhyve のしきいが低くなりました。これで楽しさが広がりますねぇ;-)。

これは僕の仮想マシン一覧になりますが、母艦は FreeBSD/amd64 14.0-RELEASE で動作しております。仮想マシンとして動作している freebsd03 は FreeBSD/amd64 13.2-RELEASE で、現在起動中です。
この freebsd03 内では qemu を利用した chroot で中に入る環境があって、そこは FreeBSD/arm64 13.2-RELEASE の環境が構築されており ports のコンパイルなどを行っております。

こんな非常にややこすぃーい環境も構築できるのが良いっ!! ;-P

1月 272024
 

前回の Beelink MINI S 購入に引き続き、もう一個 MINI PC を購入してみしました。

と、いうのも比較的小型の OS が可動する装置としては Raspberry Pi を持っているのですが、どうも FreeBSD 14.0-RELEASE を arm7 とか arm64 で動作させるのに嫌気が差してきて『素直に amd64 で良いじゃん。』と、なり、今回の MINI PC の購入となったのでありました。

今回購入したのは NiPoGi GK3Pro ミニ PC というらしいです。これは Intel の第 12 世代プロセッサである Intel Celeron N5105 を搭載しています。メモリは 8GB で SSD は 256GB です。このスペックで 15,000yen 前後なので、随分と安い。今だと Raspberry Pi 4 とかと同じくらいではないかなぁ・・。値段的にも一緒であれば、 arm64 でなくとも良いよねぇ。みたいな・・。

ただ、値段が安いだけのことはあります。SSD は NMVe ではなく、SATA 接続の M2.SSD です。

安さの秘訣を一覧にしてみましょう。あ。全て FreeBSD/amd64 14.0-RELEASE で認識した内容です。

  • SSD は上にも書いた通り M2 SATA で 256GB の容量
  • サウンドカードは USB 接続の C-Media Electronics Inc. USB Audio Device で snd_uaudio.ko で認識
  • Bluetooth も USB 接続で Realtek Bluetooth Radio で ng_ubt.ko で認識されますが利用できるかは知りません
  • WiFi は Realtek RTL8821CE で if_rtw88.ko で認識できますが、まだ利用できません。これは PCIe にぶるさがっているっぽい

 
この辺りで基本的にプライスダウンしている感じでしょうか。ほとんどのデバイスが USB にぶるさがっているので BIOS の画面から Disable にできません。『FreeBSD で利用できないデバイスなんて要らないよー。』とか思って BIOS 画面覗いても Disable にする項目がないです・・。orz

pciconf -lv してみると none が 11 個もありますが、これは Intel の Celeron プロセッサを使っている PC のパターンでしょうか。

あと、悲しいことに、最近の PC のはずなのに USB-C ポートがありません。これは結構ショックでかい・・。orz。

 
この PC の使い方
さてと。気を取り直して・・。
例の如く、この手の中華製 MINI PC は付属の WindowsOS の出どころが非常に怪しいので、サクっと削除。
Windows Product Key Viewer という Windows のプロダクトキーを確認するアプリでチェックしてみると、やはり “B” のみが並んでおりました。これは Beelink SER4 を購入してチェックしたときにと一緒ですね。

しょーがないので FreeBSD 専用の PC にすることにしました。チョイスした OS は FreeBSD/amd64 14.0-RELEASE です。 CPU の Intel Celeron N5105 には Intel のバーチャリゼーション機能が搭載されているので vmm.ko を kldload した場合は bhyve で仮想環境が構築でき、また、起動時に vmm.ko を kldload していなければ virtualbox が起動できます。

この手の MINI PC って VMware ESXi が動作しなかったり、動作してもデバイスを認識してくれなかったりするので FreeBSD をインストールして仮想環境を構築するのはアリです。まあ、 VMware ESXi は Broadcom に買収されて、その後無料版の VMware ESXi がなくなることになるので FreeBSD+bhyve は今のところチョー注目株です;-)。
AlmaLinux+Docker の環境よりしきいが低いですかね。

ただ、その場合、メモリ 8GB はちょっと量が少ないので 16GB に拡張したほうが良いですかね。
Intel の Celeron N5105 のサイトを見ると対応メモリは 16GB までのようです。

HDMI の上の黒いパーツのネジを一本外して、横にスライドさせると内部にアクセスできます。

MINI PC の上のフタを開けると 2.5 インチの SATA SSD が装着できます。その下にメモリスロットが一個あって default で 8GB のメモリが入っいます。メモリ換装は簡単そうです。 M2.SATA SSD を換装するか、換装せずに 2.5 インチ STAT SSD を増設するか、微妙ではありますね。

ちなみに、上記の写真に写っているのは銅板ではありません。ただ単にテカリのあるプラスチックです:-|。

 
あ。そーそー。この MINI PC は、一個目の HDD として追加の 2.5 インチ STAT SSD が認識され、内蔵の M2.SATA SSD は二個目として認識されます。ちょっとーっ!! この辺りもおかしいよねぇ・・。 orz

以下は mount コマンドの結果。

/dev/ada1p2 on / (ufs, local, soft-updates, journaled soft-updates)
devfs on /dev (devfs)
/dev/ada1p1 on /boot/efi (msdosfs, local)
/dev/ada1p3 on /home (ufs, local, soft-updates, journaled soft-updates)
/dev/ada1p4 on /usr (ufs, local, soft-updates, journaled soft-updates)
/dev/ada1p5 on /var (ufs, local, soft-updates, journaled soft-updates)
/dev/ada0p1 on /opt (ufs, local, soft-updates)
<以下略>

 
何もかも怪しい筐体です・・。orz。

 
FreeBSD もインストールしたし virtualbox に WindowsOS もインストールしたので、これは外に持ち出しも OK っぽい。
仕事でデータセンタ行ったとき、IP アドレス付加したあとに inetd 経由で sredird が動作すればポートサーバ風に利用できてコンソール接続も可。なんてこともできるし。

小さいので夢が膨らみます;-)。

 
最後にですが、全然デバイスが認識できていない pciconf-lv の結果を添付してこのエントリは終了とします;-)。

hostb0@pci0:0:0:0:      class=0x060000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x4e24 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4e61 subvendor=0x8086 subdevice=0x2212
    vendor     = 'Intel Corporation'
    device     = 'JasperLake [UHD Graphics]'
    class      = display
    subclass   = VGA
none0@pci0:0:4:0:       class=0x118000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x4e03 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Dynamic Tuning service'
    class      = dasp
xhci0@pci0:0:20:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4ded subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
    subclass   = USB
none1@pci0:0:20:2:      class=0x050000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4def subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = memory
    subclass   = RAM
none2@pci0:0:21:0:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Serial IO I2C Host Controller'
    class      = serial bus
none3@pci0:0:21:1:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de9 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Serial IO I2C Host Controller'
    class      = serial bus
none4@pci0:0:21:2:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dea subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
none5@pci0:0:22:0:      class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de0 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Management Engine Interface'
    class      = simple comms
ahci0@pci0:0:23:0:      class=0x010601 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dd3 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = mass storage
    subclass   = SATA
none6@pci0:0:25:0:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc5 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
none7@pci0:0:25:1:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc6 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
sdhci_pci0@pci0:0:26:0: class=0x080501 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc4 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = base peripheral
    subclass   = SD host controller
pcib1@pci0:0:28:0:      class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x4db8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:1:      class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x4db9 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
none8@pci0:0:30:0:      class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = simple comms
none9@pci0:0:30:3:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dab subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
isab0@pci0:0:31:0:      class=0x060100 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4d87 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-ISA
hdac0@pci0:0:31:3:      class=0x040300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake HD Audio'
    class      = multimedia
    subclass   = HDA
none10@pci0:0:31:4:     class=0x0c0500 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da3 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake SMBus'
    class      = serial bus
    subclass   = SMBus
none11@pci0:0:31:5:     class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da4 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake SPI Controller'
    class      = serial bus
re0@pci0:1:0:0: class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
rtw880@pci0:2:0:0:      class=0x028000 rev=0x00 hdr=0x00 vendor=0x10ec device=0xc821 subvendor=0x10ec subdevice=0xc821
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8821CE 802.11ac PCIe Wireless Network Adapter'
    class      = network

 
では。さようなら。

9月 282023
 

いやぁ。まいった。 FreeBSD 14-RELEASE/amd64 になったら if_iwlwifi.ko が正常動作するようになって FreeBSD でいよいよ待ちに待った WiFi6 が利用できるようになるのかと思いきや・・。
ぜーんぜんそんなことはなくて FreeBSD 14.0-BETA3 で bhyve から Intel AX200 を試してみたけど、やっぱり 802.11a 止まりですな。 802.11ac さえも相変わらず利用できない。一体いつまで待てば FreeBSD で高速な WiFi が利用できることになるのやら・・。

ちなみに FreeBSD 13.2-RELEASE/amd64 では一応 if_iwlwifi.ko は 802.11a では利用可能になりました。しかし、これが suspend/resume に対応していない。 resume すると利用不可になるデバイスなのでまるで利用する気にならない・・。orz。
なので、僕はずっと USB な if_rtwn_usb.ko を利用しています。一応 802.11a での通信になってしまうのだけど supend/resume には対応しているので、そこはかとなく使い続けている状態です。

 
今回は、今 FreeBSD をインストールして利用している ThinkPad X13 で Intel Wi-Fi 6 AX200 を 802.11ac or ax で利用するために bhyve を利用して ubuntu をインストールします。
そして ubuntu 側で Wi-Fi 6 AX200 を利用するのですが、一応、前提条件を書いておきます。

  • 今回 ubuntu はルータとして利用しません。IPv4/IPv6 のデアルスタクにすると設定むづかしくてしょーがない・・。
  • 母艦の FreeBSD はネットワーク的にはフツーに通信できる状態として、それとは別にブリッジ経由で bhyve の ubuntu と通信します。
  • データのやり取りは bhyve な ubuntu 側の wlp0s6 を利用し、母艦の ThunPad X13 上の FreeBSD に橋渡しします。
  • 母艦の FreeBSD の /home/takachan を bhyve な ubuntu に NFS マウントするとこでデータ転送の手間を省きます。

 
上記を図にするとこんな感じ。

 
母艦側の FreeBSD の default gateway を bhybe の ubuntu の 172.16.1.11 にすると母艦側の通信は ubuntu の wlp0s6 を抜けて WiFi6 な通信が可能になるのだけど、戻りパケットの設定などを上位のルータに設定して上げる必要があったりとか、IPv4/IPv6 デアルスタクにすると色々ややこしくなるのでやめました。

 
では、母艦の FreeBSD に必用な設定と bhyve 側 ubuntu のインストールと設定を見ていきましょう。

 
1. FreeBSD 母艦側の設定
まず、 FreeBSD の母艦側の設定を行います。

今回、 bhyve を動作させるために、まず packages をインストールします。今回はこれだけインストールしました。

$ pkg info | grep bhyve
bhyve-firmware-1.0_1           Collection of Firmware for bhyve
edk2-bhyve-g202308_3           EDK2 Firmware for bhyve
uefi-edk2-bhyve-csm-0.2_4,1    UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
vm-bhyve-1.5.0                 Management system for bhyve virtual machines

 
続いて起動時の設定を行います。

 
o./boot/loader.conf

# bhyve
vmm_load="YES"
hw.vmm.amdvi.enable=1
pptdevs="2/0/0"

 
bhyve を利用するには vmm.ko を kldload する必要があります。そして hw.vmm.amdvi.enable=1 にします。
しかし、 vmm.ko は仮想環境で排他利用となります。以前のエントリで書いていますが VirtualBox を利用する場合は vmm.ko を kldunload する必要があります。

pptdevs=”2/0/0″ は pciconf -lv で確認した PCI デバイスを bhyve で利用するための設定です。以下は pciconf -lv の例です。

$ pciconf -lv | grep -A 3 iwl
iwlwifi0@pci0:2:0:0:        class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0080
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network

 
if_iwlwifi.ko を利用したデバイス iwlwifi0 は PCI バスの 2:0:0 に割り当てられているので、/boot/loader.conf で上記のように割り当ててあげます。

次に bhyve の起動設定です。

 
o. /etc/rc.conf

vm_enable="YES"
vm_dir="/opt/bhyve"

 
vm_enable=”YES” と vm_dir=”hoge” を設定しました。他に zfs のオプションとかなんか色々あるみたいですが、ひとまず不要なので省き、一番簡単な設定のみとしました。

これで一旦再起動します。

 
2. bhyve の準備と OS のインストール

o.ネットワーク設定
bhyve では仮想スイッチを利用します。まぁ『仮想スイッチ』と、言ってもただ単にブリッジインターフェースを作成するのみです。

母艦側 FreeBSD のネットワークの状態は lo0 と wlan0 があるのみです。 wlan0 は if_rtwn_usb.ko を利用した 802.11a で 5G の周波数に接続するフツーの NIC です。

ここに bhyve の ubuntu と通信するための『仮想スイッチ』を準備してしてあげます。

# service vm start
# ifconfig tap0 create
# sysctl net.link.tap.up_on_open=1
# vm switch create -a 172.16.1.1/24 public
# vm switch add public tap0
#
# ifconfig -a
lo0: flags=8049 metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
<一部略>
wlan0: flags=8843 metric 0 mtu 1500
        inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::20f:ff:fe8d:2c72%wlan0 prefixlen 64 scopeid 0x2
        inet6 2001:470:fe36:5678::32:1 prefixlen 64
<一部略>
vm-public: flags=8843 metric 0 mtu 1500
        ether 3e:ce:d6:69:ff:84
        inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap0 flags=143
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        groups: bridge vm-switch viid-4c918@
        nd6 options=9
tap0: flags=8943 metric 0 mtu 1500
        options=80000
        ether 58:9c:fc:10:fc:0e
        groups: tap
        media: Ethernet autoselect
        status: no carrier
        nd6 options=21
        Opened by PID 2627

 
bhyve で利用する tap0 を作成します。次の sysctl はまぁ、おまじない。次に『仮想スイッチ』を public という名で vm switch create します。ついでに IP アドレスを付加します。

ifconfig -a で確認すると vm-public と tap0 が作成されました。
vm-public は bridge インターフェースで vm switch add public tap0 コマンドにより tap0 を内包しています。かつ vm-public には 172.16.1.1/24 の IPv4 アドレスが付きました。 bhyve 側の ubuntu は FreeBSD 側から見ると tap0 ですが ubuntu 側では enp0s2 として認識してそこに 172.16.1.11/24 のアドレスを付加すると母艦と bhyve 側の ubuntu で通信が可能になります。

母艦側の wlan0 は全く触ることはありません。

 
ネットワークの設定ができたので、bhyve の ubuntu をインストールしていきましょう。

まず、原型を作成します。

# service vm start
# vm create -t ubuntu ubuntu
# cd /opt/bhyve
# ls -aCF
.config/    .img/       .iso/       .templates/ ubuntu/
#
# vm install ubuntu .iso/ubuntu-23.04-live-server-amd64.iso
<以下略>

 
/etc/rc.conf に記載した vm_dir の /opt/bhyve の下に色々できています。 /opt/bhyve/.templates/ の下にファイルを一個作成します。

o./opt/bhyve/.templates/ubuntu.conf

loader="uefi"
cpu=2
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
graphics="yes"
graphics_port="5900"

 
このファイルを作成して、iso イメージを /opt/bhyve/.iso/ に設置してから vm install ubuntu を実行しましょう。そして、インストールします。あ。なんか、 ubuntu23 はメモリが 512MB ではインストーラが起動しないようです。1GB とか 2GB のメモリ量にしてあげましょう。

インストール中はネットワークは利用できないので利用する iso イメージは最低限インストールできるものをチョイスします。

これでイントールは完了しましたかねぇ。

o. bhyve の ubuntu の起動スクリプト

#!/bin/sh

case $1 in
'start' )
    bhyve -c 2 -m 1G -w -H -S \
          -s 0,hostbridge \
          -s 1,virtio-blk,/opt/bhyve/ubuntu/disk0.img \
          -s 2,virtio-net,tap0 \
          -s 3,fbuf,tcp=0.0.0.0:5900 \
          -s 4,xhci,tablet \
          -s 5,lpc -l com1,stdio \
          -s 6,passthru,2/0/0 \
          -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
          ubuntu
    ;;
'tm' )
    tmux new-session -d -s mugi-ubuntu 'sudo /opt/bhyve/bin/vm_ubuntu.sh start'
    sleep 3
    ifconfig tap0 | grep status
    ;;
'stop' )
    bhyvectl --force-poweroff --vm=ubuntu
    ;;
'ls' )
    bhyvectl --get-stats --vm=ubuntu
    echo;echo
    echo "tmux list-sessions"
    echo "tmux attach -t ubuntu"
    ;;
'*' )
    echo vm_ubuntu.sh { start | stop | ls | tm }
    ;;

esac

exit 1;

 
bhyve でゲスト OS を起動するにはずいぶんと難儀です。上記のスクリプトは /opt/bhyve/bin/vm_ubuntu.sh という名で準備しました。
ちと、説明が必要ですかね。

まず、 start オプションのパラメータですが、-s は PCI BUS を想定してください。ディスク・ネットワーク・コンソール・USB、そして pptdevs で渡された Intel Wi-Fi 6 AX200 になります。このパラメータでまず、ubuntu が起動できるかと思います。

しかし、ここまでたどり着くまでにはずいぶんと色々苦労したので bhyve の起動オプションは本当に難儀したぞぉ。簡単に bhyve の ubuntu とか FreeBSD が起動するとは思わないほうが良い。色々検索して情報を探してくだされ。 BIOS でのブートとか UEFI でのブートとか、google に聞くと古い情報とかごまんとあって、最新の情報を拾ってくるのは中々悩ましい・・。

 
次の tm オプションですが、これは tmux を介してバックグラウンドで動作させます。 tmux については個別に勉強してください。コマンドのサワリだけ書いておきます。

# tmux list-sessions
ubuntu: 1 windows (created Wed Sep 27 12:31:41 2023)
# tmux attach -t -ubuntu
<以下略>

 
tmux list-sessions で tmux のセッションを確認して、そのセッションに tmux attach -t -ubuntu でアタッチするとコンソールが表示されます。コンソールから抜けるには tmux のコマンド C-b d を打ちます。

もしかしら ubuntu では tmux 使えないかも・・。
もうひとつのコンソールへのアクセス方法があります。 ports から net/tigervnc-viewer をインストールします。そして、以下のコマンドを打ちます。

$ vncviewer localhost:5900
<以下略>

 
上のほうで /opt/bhyve/.templates/ubuntu.conf というファイルを作成しましたが、そのとき graphics_port=”5900″ を指定していると思います。また bhyve 起動時にも -s 3,fbuf,tcp=0.0.0.0:5900 というオプションを指定しています。これが vncviewer でアクセスするポートになります。

コンソールに接続できたので ubuntu の設定を色々していくことにします。まぁ、僕は ubuntu はあまり得意ではありませんので、このあとはサワリだけ説明することにします。

そして、次に行きます。

 
3. 母艦と bhyve の ubuntu との通信
bhyve の ubuntu 側で ip addr をたたくと以下のインターフェースが確認できると思います。

$ ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp0s2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlp0s6:  mtu 1500 qdisc noqueue state UP group default qlen 1000

 
enp0s2 が 母艦側との通信インターフェースで wlp0s6 が WiFi6 です。

まず、母艦の 172.16.1.1 と通信する enp0s2 設定からです。

o./etc/netplan/99-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s2:
      dhcp4: false
      addresses: 
        - 172.16.1.11/24
#     gateway4: 172.16.1.1
      nameservers:
        addresses: [192.168.1.34]
        addresses: [192.168.22.251]

 
さーっ!! yaml の設定に悩んでくだされーっ!! なんでまともに設定できんのだ?! とウンザリすることでしょう・・。orz
設定完了後 sudo netplan apply のコマンドを打って、で設定を反映して、そしてうんと怒られてください;-P。

無事に設定が完了すると、FreeBSD 母艦と bhyve との間の 172.16.1.0/.24 のセグメントで通信ができるようになります。

ここまでできたら母艦側から ssh 接続できるようになるので、作業が格段にしやすくなります。

 
続いて wlp0s6 側の設定を見ていきます。 enp0s2 は母艦との接続のためだけのインターフェースですが wlp0s6 は外部との通信を行います。 ubuntu は WiFi6 に対応しているので Intel Wi-Fi 6 AX200 を利用する通信はむちゃくちゃ速いです。

o./etc/netplan/50-cloud-init.yaml

network:
    wifis:
        wlp0s6:
            optional: true
            access-points:
                "AP80211AX":
                    hidden: true
                    password: "PASSWORD"
            dhcp4: false
            addresses:
              - 192.168.1.48/24
              - 2001:470:fe36:abcd::48:1
            gateway4: 192.168.1.1
            nameservers:
              addresses: [192.168.1.34]
              addresses: [2001:470:fe36::ffff:34]

 
WiFi の SSID は AP80211AX で パスフレーズは PASSWORD です。この AP はステルス機能を有効化しているので hidden: true を設定しています。
IP アドレスについては IPv4/IPv6 デアルスタクです。 IPv4 gateway は設定していますが IPv6 gateway は ra で降ってきます。ネームサーバも IPv4/IPv6 両方のアドレスを指定しました。

これまた書き方にうんと悩んだあと sudo netplan apply のコマンドを打って設定を反映して、そしてうんと怒られてください;-P。

これで ubuntu 側の設定は完了です。

 
4. bhyve の ubuntu の設定と実際に利用してみる
ubuntu では設定というか、dep を apt-get install で色々好きなものをインストールしてください。
ここでは特には書かないです。

唯一必要だったのが NFS クライアント側の設定でしょうか。母艦の FreeBSD 側で NFS Server を有効にして /etc/exports を書きます。 /home/takachan を NFS のマウントポイントとして 172.16.1.0/24 から許可します。
ubuntu 側では /etc/fstab に母艦の FreeBSD の /home/takachan を /home/takachan/takachan 辺りにマウントするようにします。

NFS の設定が完了したら、試しに iso イメージをダウンロードしてみましょう。

まずは母艦の FreeBSD で wget を実施し、次に ssh で bhyve の ubuntu にログインしたあとに wget してみました。

$ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 1%[                    ]   7.35M  1.84MB/s   残り3m 49s  
^C
$ ssh 172.16.1.11
ubuntu $ cd takachan
ubuntu $ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 4%[>                   ]  20.66M  10.2MB/s   eta 38s
^C
ubunru $

 
母艦側の FreeBSD のホームディレクトリで wget で iso イメージを取得すると大体 16Mbps の速度が出るか出ないか。これは USB の if_rtwn_usb.ko を利用して 802.11a で通信する FreeBSD で一番速い WiFi の速度です。
次に bhyve の ubuntu に ssh して NFS マウント先で wget すると FreeBSD側 の $HOME で wget するのと同じ状態になります。ただ、ubuntu 側で wget すると速度が全然違い 80Mbps 出ています。これは Linux での iwlwifi ドライバが正常に動作していることを示しています。そして、この速度はうちの外部接続ネットワークの限界です。

 
宅内の他の PC やサーバとデータをやりとりするときは ubuntu 側の 192.168.1.48 側のアドレスでデータをやり取りすることにより高速に転送することが可能です。

 
こんな感じで、いつまで待っても FreeBSD で WiFi の 802.11ac or ax が利用できないのを bhyve の ubuntu で通信速度を稼ぐ。と、いうちょっと荒業を、今回は使ってみました。

おかげで bhyve にずいぶんと詳しくなったぞぉーっ!! みたいな f(^^;;。

一点だけ注意点があるかも。母艦の FreeBSD は suspend/resume に対応していても bhyve で動作する OS が動作しないかな? FreeBSD の resume 後 vm lsit で Running 状態だったゲスト OS は動作がおかしくなる傾向が見受けられました。
が、これは当然でしょうかねぇ・・。考えてみると FreeBSD 側で Intel Wi-Fi 6 AX200 は supend/resume に対応してないので、たとえ pptdevs で ubuntu に渡していても resume 後は利用出来ない状態に陥ります・・。orz。

FreeBSD 14-R で if_iwlwifi.ko が suspend/resume に対応してくれるとともっと幸せになれるのだけれど、それはリリースされてみたいと解らないかなぁ。

 
と、いうことで、皆さんもせっかく持っている内臓の、 FreeBSD では中々利用できない Intel 系の WiFi チップ。 bhyve の ubuntu で有効利用するのもありなのかなぁ。と、いうのが今回のネタだったのでありました。

bhyve のこと、今後、ネタとして書く機会あるかな?

9月 182022
 

自宅のデスクトップ機自宅サーバに HP ProDesk 405 SFF/CT を購入しました。時期的にデスクトップ機は G6 、自宅サーバは G8 というタイミングです。

で、この二台は AMD Ryzen7 PRO CPU が搭載されています。 BIOS (UEFI) メニューを見ると AMD DASH というのに対応しているようです。

そもそも “AMD DASH” とはなんぞや?

簡単に言うと iLO みたいにリモートで BIOS を管理でる機能らしい。あくまで『らしい』のであります;-)。

AMD DASH を利用するためには PC 側に AMD DASH で利用するための IPv4 アドレスの設定が必要です。これは iLO と一緒ですね。

そして、管理用のマネージャーが必要です。マネージャーは以下の URL にアクセスしてダウンロードすることができます。

https://developer.amd.com/tools-for-dmtf-dash/

『AMD MANAGEMENT CONSOLE』ってのがそれにあたります。

確認してみると Windows 用の GUI と CLI 、各種 Linux 対応の CLI がダウンロードできるようです。
まぁ、『手元の Linux で CLI』より『手元の Windows で GUI』のほうが楽だろうと思い AMC-setup-7.0.0.956-AMD.exe をダウンロードし、手頃な WindowsOS にインストールします。

これでマネージャー側の準備は完了。では早速、デスクトップ機にアクセスしてみることにしましょうっ!! ってんですが、これが大変。

PC 側で AMD DASH を有効にして IP を付加させるまでの工程は随分と苦労するので、今回はそちらをメインに書いてみます。

 
1. BIOS (UEFI 画面。以降 BIOS 画面と記載) で AMD DASH を有効化
その通りですね。 BIOS 画面で [詳細設定] -> [システムオプション] を選択して下から二番目にある「AMD DASH」にチェックを入れます。



 
2. UEFI ドライバーからの「他社製オプション ROM の管理」へアクセス
「AMD DASH」にチェックを入れたあと、次に BIOS 画面で [UEFI ドライバー] を選択し、そこに表示されている「他社製オプション ROM の管理」の項目を選択します。 選択したあと、保存して終了します。そのタイミングで再起動します。

再起動して起動してくるタイミングで F3 キーを押してください。画面の左下に以下のように表示され、その後「他社製オプション ROM の設定」画面が表示されます。

F9 はブートセレクト画面、 F10 は BIOS 設定画面が表示されますが、 F3 キーを押すと「他社製オプション ROM の管理」画面が表示されます。これは裏技か? どこにも書かれてないぞぉー。

 
3. AMD DASH のネットワークと認証設定
「他社製オプション ROM の管理」画面にはいりました。青ベースの画面になりますね。

僕の場合はオンボードの Realtek の NIC と PCI-e x16 スロットに HP 純正の Intel の 2Port NIC のカードが入っているので MAC アドレスが 3 個見えますが、ここから Realtek の NIC の設定画面に入ります。Realtek は一番下の NIC ですね。

NIC を選択すると設定画面に突入。

右上には「AMD DASH の設定をしているよー。」って、表示されています。

ネットワークの設定については、まぁ、ややこすぃーのでとりあえず DHCP の設定をしてから抜けます。
個別の IP アドレスを指定しても良いと思いますし VLAN-ID を設定しても良いと思います。が、一番最初は勝手がわからないので DHCP でアドレスを取得するようにします。
この画面、良く見てみるとネットワークの設定するところが二ケ所あるんですよ。どっちが AMD DASH 用か良くわからない。なので、両方のネットワーク設定で DHCP の設定としました。

Realtek RealManage Setup のところで Setup and Configuration の中に入ると Security 関係の ID とパスワードが求められます。これには Administrator/Realtek で認証が通過します。

AMD MANAGEMENT CONSOLE からアクセスする際の認証に利用されます。 Administrator/Realtek は default 値です。

完了したら「他社製オプション ROM の設定」画面を抜けて再起動します。

 
4. しかし、実際の IP アドレスの割当は?
今回はデスクトップ機の HP ProDesk 405 G6 SFF/CT 側で AMD DASH を設定したので、こちらを利用します。 PC 上で動作している OS は FreeBSD/amd64 13.1-RELEASE です。

まず、自分のネットワークの網内に dhcpd を起動します。 FreeBSD 的ですが tail -f /var/db/dhcpd/dhcpd.leases して、 Realtek の NIC がどの IPv4 アドレスを取得するか確認します。

PC の電源を入れた段階でただちに IPv4 が取得されると思います。

『オンボードの Realtek の NIC は FreeBSD でも利用するのに AMD DASH で IPv4 アドレス取得して FreeBSD でも IPv4 使うの、無理じゃね?』

となるのであります。

その昔、HP DL320G5p 辺りに iLO とオンボード NIC が一緒のポートで VLAN で IP アドレスを使い分けろ。とかいうのがありました。その後、この仕様はなくなり iLO と OS が利用する NIC は別ポートなのが主流になりましたが・・。

「他社製オプション ROM の設定」画面で VLAN の設定もできるので、そこで PC セグメントと AMD DASH 用管理セグメントを分けた VLAN-ID を設定する。と、いうのも一つの手ではあります。

と、いうことで、この部分の IP アドレスの使い分けが非常にややこしい。自宅に Cisco 891FJ があるとはいえ・・。既に VLAN を利用して自宅のネットワークを構築しているとはいえ・・。

 
と、いうことでオンボードの re0 は AMD DASH 専用ポートに、PCI-e の 2Port NIC を FreeBSD 側で利用 (em0・em1 で認識している)することにします。

FreeBSD ではオンボードの Realtek の NIC は /boot/kernel/if_re.ko では動作しません。 ports から net/realtek-re-kmod をイントールした /boot/modules/if_re.ko を利用する必要があります。

 
PC に電源を入れて DHCP で取得した IP アドレスに ping を打ち続けるのですが、 FreeBSD が起動して re0 が認識した時点で ping が止まります。 AMD DASH と FreeBSD の IP アドレスがグチャグチャになるのでしょうなぁ。

それにしても AMD DASH 対応の NIC のために FreeBSD の標準 if_re.ko では動作しないのかな?
まぁ、FreeBSD は em0 を利用して通信するので re0 を認識させる必要さえありません。

 
ちなみに、自宅サーバ側の HP ProDesk 405 G8 SFF/CT は VMware ESXi 7.0 が動作していますが、ESXi7 はそもそも Realtek の NIC を認識しないので、こちらは問題なく AMD DASH で利用できますね。ただ、もう ESXi7 が起動している状態なので AMD DASH の設定してませんが・・f(^^;;。

 
オンボードの Realtek NIC の IP アドレスの設定について FreeBSD のみで動作確認したので WindowsOS ではどういう振る舞いをするのか確認さえしていません。もしかしたらドライバが優秀なのかもしれませんが、僕は見ようとも思ってません;-)。

と、いうことで AMD DASH 用に IPv4 アドレスが付いたでしょうか?

では次に進みましょう;-)。

 
5. AMC Console を起動
Windows にインストールした AMD MANAGEMENT CONSOLE を起動します。
一番最初にセットアップ画面が表示され、認証用 IP とパスワードを指定するように求められます。先程の default 値の Administrator/Realtek を指定します。
次に AMD DASH 対応 PC をネットワークから探査します。一番左にある “DISCOVER” と書かれたアイコンをクリックします。

  • hostname
  • IP Address
  • TCP/IP Range
  • Active Directory

 
上記で探査可能ですが、dhcpd のログを確認して IPv4 アドレスは解っているので素直に IP Address で探査します。

探査できるとこんな感じです。

 
6. AMC Console を使い込んで行こう
一旦認識されると All Systems というコンピュータグループに登録されるので、確認します。
探査された PC の状況や BIOS の情報を表示してくれます。色々見て楽しんでください;-)。

あとは AMC Console の上のアイコンにあるメニューを順に確認していく。と、いう感じでしょうか。機能的に色々試す。と、いう感じです。

 
僕的には右から 4 番目の “REMOTE ACCESS” がえらい気になったですが・・。 iLO5 だと HTML5 コンソールとか起動して、 PC の画面が表示できるのですか、『AMD DASH もできるのかっ!?』うひっ!! ・・。 まぁ、甘かったですね・・。orz

ちょっと使ってみたのですが、 BIOS 設定など表示できるのはうれしいです。が、その程度かなぁ・・。 iLO にはほど遠いみたいな雰囲気でしょうか。まぁ、CPU メーカがここまでよくやった。うんうん。

 
あ。ここまで書いて、思い出したっ!! AMD DASH は iLO の対抗ではなかったですね。 Intel の vPro 対抗の機能だったっ!! 失礼しましたっ!!

と、いうことで機能的には Intel vPro と同等なのかな?

 
興味がある方は色々試してみてください。

上にも書いた通り、ネットワーク設定が通過できると比較的容易に遊べるようになるかと思われます。

 
このエントリは AMC Console の利用方法について記載したものではなく、どこにもドキュメントが無い AMD DASH を利用する PC 側のネットワーク設定について書かれたモノなのであります。なので AMC Console の Linux CLI とか Windows GUI とか、そんなのはどうでも良いことなのでありますっ!! ;-P。

 
(参考にしたサイト: https://www.reddit.com/r/Amd/comments/ism4wg/trying_out_dash_remote_access_on_a_thinkpad_t14s/)
どこにもドキュメントが無いないわけではなかった・・。ほっ。

8月 132022
 

いやぁ。自宅のサーバを更新しました。富士通の PRIMERGY MX130 S2を使い続けて約 10 年。そろそろ潮時だろうと・・。

小型の PC を探していたのだけど、中々良いのがない。自宅のサーバとはいえ、VMwareESXi7.0 を起動させるので RealTek の NIC では無理。PCI-e スロットがあって、 2Port NIC なんかが内蔵できるようなやつが必要。

と、いうとこで、最近は PC 高いし、納品遅いのですが、以前購入したデスクトップ機と同様の HP ProDesk 405 G6 SFF/CT にしました。ただし時代は変わっているので今回購入したモデルは G8 になります。

CPU は AMD Ryzen7 PRO 5750G で 8Core/16 スレッド。サーバにはバッチリ。 HP から購入したときの構成は 4GB のメモリと 500GB の HDD でだいたい 62,000yen くらいでした。「価格.com 限定モデル」にすると相場より 10,000yen くらい安く買えるようです。

ここに別途 64GB のメモリっ!! 大体 25,000yen くらい。
3TB の HDD と 1TB SSD は今年の頭くらいに購入したものがあったのでそれを使い回しします。
PCI-e x2 接続の 2Port NIC は家に腐るほどあるので、Broadcom と Intel どちらにしようか悩んだけど、Intel の em0 にしました。

と、いうことで 8Core/16 スレッドで、メモリ 64GB 、ネットワーク 2NIC と、それはもう VMware ESXi7.0 を動かすのにはバッチリな環境が整ったのであります。

 
今回メモリは Crucial DDR4-3200 288pin UDIMM 64GB(32GB×2枚) CT2K32G4DFD832A をチョイスしました。『 PayPay モールで初めてお買い物』で 1,500yen 引き。その他 PayPay ポイントが 5,400 ポイントくらい付いたので、実質 22,000yen くらいでの購入でした。
HP ProDesk 405 G8 SFF/CT とも相性は良いみたいで、特に問題もなく 64GB を認識してくれました。うひひ;-)。

 
さてと。まずは default で入っている WindowsOS のアクティベーションを行います。が・・。 orz

画面がまともに映らないではないか・・。 orz。

HP の PC は法人向け PC を購入した場合 HP wolf security というのが default でインストールされているそうです。個人向けの PC の場合はインストールされてないです。今回は HP で購入したとき「TAKANO Network Service.」として購入したので法人扱いになったようです。従業員 10 名未満f(^^;;。

 
で、これが悪さしているのか解らないのですが、画面の下半分に起動時の画面がそのまま残ってしまい、OS インストール時は画面が上半分しか表示されない状態です・・。orz

しかし、この状態で本当によく Windows11 のアクティベーションができたモノだ・・。原因がどこにあるのか、さっぱり解らない。UEFI(BIOS) 画面でセキュリティに関する項目を根こそぎ OFF にしたけどだめ。

純正メモリ 4GB を 64GB にしたからかぁ?などと思い、もとに戻したりもしたけど、ダメ。
PCI-e x16 スロットに nVidia のグラフィックスカードを接続してそっちから画面だそうとしたら真っ白に表示されるし・・。orz

が、原因が特定できました。

PCI-E x16 のスロットに何か刺していると画面が半分に表示されるようです。それも WindowsOS のときのみ。
VMwareESXi7.0 のインストーラは ESXi の画面では半分表示にならない・・。ひどい話だぁ・・。

と、いうことで、 500GB の未使用となる WindowsOS がインストールされている HDD は再利用されることもなく、そのままお蔵入りとなるのでありました。あ。Windows のライセンスは引っこ抜きましたけどねぇ。 ESXi 上で動作させるか;-)。

 
それでは本命の VMwareESXi7.0 をインストールですが、こちらは PCI-e スロットに接続した 2Port NIC も問題なく、メモリ 64GB もサクっと認識して無事に起動して動作するのでありました。

こちらはインストールしている最中の新旧サーバの図。 ESXi のインストールが完了したら、ネットワークの設定とか VMware vCenter Converter を利用して OS の引っ越しです。

 
ESXi 上に存在している仮想マシンは全部で 17 台。常時動作しているのは VyOS と TrueNAS 、 WindowsServer2019 を含めて 8 台。ってところでしょうか。
メモリジャブジャブ、FreeBSD ports のコンパイルなどで CPU 負荷かけても大丈夫。そして音も静か。

中々良い感じのリプレイスではないかなぁ。と、思った次第なのでありました。
PCI-e スロットが付いている小型の HP ProDesk 405 G8 SFF/CT 。サーバとしてもちょうど良い感じでした。

 
さてと。前回購入した自宅サーバは約 10 年利用しました。今回購入した自宅サーバは、特に問題もなく壊れないと想定して 10 年持ったとした場合、もしかしたら、これが最後の『自宅サーバ購入』になるのかもしれません・・。 ちなみに自宅サーバ、今回が 9 代目となります;-)。

どうなることやら。

1月 072020
 

Vmware ESXi 上で動作している FreeBSD 12.0-RELEASE を freebsd-update upgrade -r 12.1-RELEASE で 12.1-RELEASE したところ、パッタリと通信が止まった。

まぁ、ssh でログインして ls とかたたく分には問題はない。ログイン先から scp でファイルを転送しようとしたときや、 12.1-RELEASE のサーバが nfs サーバだったりすると、データの転送が全くできない状態。

FreeBSD 12.1-RELEASE はアップロード (受信側) はなんとか速度が出る状態だけど、ダウンロード (送信側) は最初チョロョロそのうちストール。状態で全く利用できない状態。

 
どうしてそうなったのか? と、言えば FreeBSD 12.1-RELEASE になって、 if_vmx.ko は fib に対応したのですが、そこにバグがあるようです。fib については簡単にですが以前書いていますので、そちらを参考にして頂ければと思います。僕的には ubuntu の VRF のような動作ができない機能なので、全く使う気にはならないのですけども。

 
12.1-RELEASE でバグが入り込んでしまったのは if_vmx.ko のみなので、 Vmware ESXi で動作している FreeBSD 12.1-RELEASE は NIC を E1000 、つまりは em0 に変えることにより通信が復活するようになります。ただし、 NIC を変更すると /etc/rc.conf などに記載している設定を変更する必要があるために、インパクトがそれなりに大きいです。

12.0-RELEASE のカーネルソースツリーが手元にある人は 12.1-RELEASE 上で sys/modules/vmware/vmxnet3/ までたどり着いて、そこで make install 叩けばフツーに利用できるようになります。

とは、簡単に行かないか・・。

 
1). 12.0-RELEASE のソースツリーを 12.1-RELEASE 上に用意
2). 12.1-RELEASE 上で 12.0-RELEASE の sys/modules/vmware/vmxnet3/ を make install
3). カーネル再構築時は 12.1-RELEASE のソースを利用
4). GENERIC カーネルを利用しているのであれば GENERIC コンフィグから device vmx をコメントアウトしてカーネル再構築 && インストール
5). /boot/modules/ にインストールされた 12.0-RELEASE の if_vmx.ko を /boot/kernel/ に移動
6). /boot/loader.conf に if_vmx.ko をロードするように記載
7). FreeBSD の再起動

 
これだけやる必要があります。

 
今の所 12.1-RELEASE にバージョンアップして通信ができなくなるのは if_vmx.ko が原因になるので、他の NIC では発生していないと思われます。

 
僕は、物理 NIC を割り当てていない vSwitch 経由の FreeBSD の NIC は if_vmx.ko を利用して MTU を 9000 にしています。
物理 NIC を割り当てている vSwitch では if_vmx.ko を利用していますが MTU は 1500 のままにしています。
どちらの場合も通信が滞るので MTU は関係ありません。

バグレポートも上がっているようです。が、直接的な解決策はまだ見つかっていないようです。

Bug 236999 – vmx driver stops sending network packets and resets connections (TCP) but allows ICMP

某 BSD 系な Slack で仲間連中と色々話したり試験したりしているのですが、再現性は 100% で、かつ、今日現在 if_vmx.ko での回避策を見出せていません。

 
なお、 Vmware ESXi 上に FreeBSD をサーバとして if_vmx.ko を利用しているサービスはほぼ全滅です。ウェブ・ FTP ・ svn サーバ・ NFS サーバ、その他諸々。

FreeBSD 12.0-RELEASE を Vmware ESXi 上で稼働させていて、FreeBSD 12.1-RELEASE にバージョンアップした人、しようとした人はお気をつけください。

5月 182017
 

と、いうことで非常に簡単なエントリーですが、困っている人もたくさんいるのではないかと思うので書いておきます。あ。 ports-CURRENT を追いかけている人向けです。

Vmware ESXi 上で FreeBSD を動作させている人は ports から emulators/open-vm-tools/ もしくは emulators/open-vm-tools-nox11/ をインストールしているかと思われます。

これ、ずいぶん前から FreeBSD/amd64 10.3-RELEASE ではコンパイルが通らなくなっているんですよね・・。
lib/user/utilBacktrace.c の中でエラーが出ています。

FreeBSD な ML でも話題になっていますが、誰も相手にしてくれないようで・・。 orz

https://lists.freebsd.org/pipermail/freebsd-virtualization/2017-January/005186.html

けどもまぁ、一応、パッチを当てて FreebSD/amd64 でコンパイルが通るようにしたので、そのパッチをここに記載しておきます。
以下がパッチです。

--- lib/user/utilBacktrace.c.orig       2017-05-17 22:23:46.088791000 +0900
+++ lib/user/utilBacktrace.c    2017-05-17 22:23:53.932119000 +0900
@@ -54,7 +54,6 @@

 #ifdef VM_X86_64
 #   if defined(__GNUC__) && (!defined(USING_AUTOCONF) || defined(HAVE_UNWIND_H))
-#      define UTIL_BACKTRACE_USE_UNWIND
 #   endif
 #endif

 
これを patch-utilBacktrace.c という名で保存して emulators/open-vm-tools/files/ 辺りにでもほーりこんで make してみてください。

このパッチですが、注目点としてその上の行の ifdef VM_X86_64 の部分です。

実は手元に Vmware ESXi 上で動作する FreeBSD/i386 があるのですが、これでは無事に emulators/open-vm-tools-nox11/ のコンパイルが通りました。

ってことは、つまりはなんだい?

VM_X86_64 のとき(それはつまりはアーキテクチャが x86_64 のとき。と、いうことですね)に UTIL_BACKTRACE_USE_UNWIND が define されて lib/user/utilBacktrace.c をコンパイルすることになって、それがエラーになるのでコンパイルが通らない。と、いうことですね。

ならば UTIL_BACKTRACE_USE_UNWIND を define させなければ良いんじゃーねーのかい? FreeBSD/amd64 だからといってもデバッグ用のロジック(本当か? f(^^;)は FreeBSD/i386 にもないんだからいらねーだろ。って発想です;-)。

果たして、上記パッチを適用することにより FreeBSD/amd64 でも emulators/open-vm-tools-nox11/ のコンパイルが無事に通ったのでありました。

あ。コンパイルが通っただけでなく、利用もしていますが、今の所問題は出ていないです;-)。

 
すげー、お気楽なパッチですが、最新版の emulators/open-vm-tools-nox11/ が FreeBSD/amd64 に今すぐ必要・直ちに必要などという人は参考にしてみてください。

 
ずいぶん前からコンパイルが通ってないのだけど、まだまだ当分、直らないんだろうなぁ。などと思っております・・。

9月 302015
 

僕は VMWare ESXi 5.1 上で何個かの FreeBSD/amd64 を動かしているのですが、 9.2-R -> 10.0-R -> 10.1-R と来て、今回いよいよ 10.2-R にしてみました。

しかし、 10.2-RELEASE にした途端 powerd が動かなくなりました。あれ? 9.2-R から 10.1-R まで利用しているときには powerd が動いていて sysctl の dev.cpu.0.freq や dev.cpu.0.freq_levels が見えていたのですが、 10.2-R にした途端に見えなくなりました。おかげで powerd を起動すると以下のような感じ。

# service powerd start
Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc.d/powerd: WARNING: failed to start powerd

 
cpufreq.ko はロードしているのに有効になっていないようですね。あたたた。

そもそもハイパーバイザの上で動作する OS では cpufreq は見えないんじゃね? という話があります。例えばさくらの VPS では、その上で動く FreeBSD は powerd は動かないし Virtualbox 上の FreeBSD でも powerd が動かない。 dev.cpu.0.freq_levels が無いからですね。

しかし、 VMWare ESXi ではその上で動作する FreeBSD で cpufreq.ko が有効になって dev.cpu.0.freq_levels が生えてきて powerd が動作します。

powerd が動かないと CPU が最速でブン回って地球に優しくないよねぇ。などと思うので何とかしたいのであります。

 
で、色々調べたり、人に聞いた話だと FreeBSD 10.2-RELEASE ではとあるパラメータが追加になって、物理マシンではない場合には default で disable になったようです。なのでそのパラメータを変更して上げると以前のようになるらしいです。

/boot/loader.conf に以下の行を追加して上げると 10.2-R は 10.1-R の頃のように cpufreq.ko が有効になり dev.cpu.0.freq_levels が生えてきて powerd が動くようになります。

hint.acpi_throttle.0.disabled="0"
hint.p4tcc.0.disabled="0"

 
/boot/device.hints の最後に上記の行が追加になってますね。それも “1” で。これを “0” にすると cpufreq.ko が利用可能な状態になってくれます。

この設定が有効なのは今のところ VMWare ESXi のみのようです。実機では必要ありません。実機では default の設定でも cpufreq.ko が有効になります。
また、上記設定を書いても KVM や Virtualbox では dev.cpu.0.freq_levels が無いままだと思われます。

 
参考になる URL としては https://svnweb.freebsd.org/base?view=revision&revision=276986 を見るのが良いかと思われます。

それにしても VMWare ESXi (僕は 5.1 を利用) で FreeBSD を動かしていたけど 10.2-R にしてから powerd が動かなくなったとお嘆きの方は上記の行を /boot/loader.conf に書いてみることをおすすめします。

 
2015/10/04 加筆
上記の設定は VMWare ESXi のときのみの設定ではなく、物理マシンにおいても有効のようです。 10.2.-RELEASE では default で 1 なので、とりあえず powerd をどうにかしたいとか、 dev.cpu.0.freq_levels で表示される数を増やしたいなどあったら上記の設定を入れて試してみるのも一つの手でアルと思われます。

1月 242015
 

離れた二点間で IPv6 を L2 で利用したいなぁ。と、ずっと思っていたんだけど、中々手段がなかった。 FreeBSD の gif トンネルを使うと L3 接続になるし gre を使うと bridge が利用できないのでややこしいネットワークになってしまうし、そもそも FreeBSD の gre は IPv6 の L2 抜けが 10.0-RELEASE になってもできないみたいだし・・。

と、いうことで今回は離れた二点間で同一の /64 の IPv6 セグメントを利用できるようなネットワークを構築してみたいと思います。
ただ、ネットワーク機器としての FreeBSD の利用は今回あきらめました。今回は VyOS 1.1.1 を利用してみました。
VyOS 1.1.1 はフリーで利用できる仮想環境用のルータ OS です。

VyOS のインストールについてはここでは記載しないので他のウェブサイトでご確認頂ければと思います。

 
でもって、今回構築するネットワーク環境は以下になります。

IPv6_L2TPv3_2

ちょっと説明を。

  • 既存ネットワークのセグメント1: 10.123.1.0/24
  • 既存ネットワークのセグメント2: 192.168.123.0/24
  • 上記二つの異なる IPv4 のセグメントにおいて 2001:470:fc1e:10::/64 の IPv6 セグメントを利用したい。
  • IPv4 は 172.16.101.0/24 もあるけど、ついでに利用できるのであればそれはそれで嬉しい;-)。

と、いうような感じ。 IPv4 を L2 で抜けるソリューションは色々あるようなんだけど IPv6 の L2 抜けってのはどうも対応してない OS があったりして中々手強いモノがあったのであります。

セグメント2 側に IPv6 が無いので L2 で抜けて行って IPv6 使えるようにしましょう。ってのが今回の要件でしょうかね。

dtcp を利用した gif インターフェース使えば良いじゃん。と、いうソリューションもあるのですが、その場合 dtcps を起動する側には /48 が必要で dtcpclient 側に /64 を配布。って形になるので /64 しか無い場合には L2 抜けしてあげないとちょっとつらいんですね。

 
と、いうことで上の図は構成図です。物理的にはセグメント1 にもセグメント2 にも VMwareESXi 5.1 がいます。そこにサーバ(今回は FreeBSD をチョイス。と、いうか、いつも FreeBSD だけど;-)と VyOS が入っている状態です。

  • セグメント1: FreeBSD-01・FreeBSD-02・VyOS-01
  • セグメント2: FreeBSD-03・VyOS-02

では以下に手順を書いていきます。

 
1). VMWareESXi 5.1 の設定
サーバと VyOS が vSwitch で接続された状態にします。そして vSwitch ではプロミスキャス・モード (promiscuous mode) を有効にしておく必要があります。
日本語版では「無差別モード」と言っているようですが。

以下は VMWareESXi の vSwitch の設定のキャプチャです。

IPv6_L2TPv3_1

[構成]タブ -> ネットワーク -> vSwitch のプロパティを開きます。
[ポート]タブの「編集」ボタンを押します。
表示されたウィンドの[セキュリティ]タブの「無差別モード」を “承認” にします。

以上で準備は完了です。これをやっておかないとあとで痛い目にあいますX-(。

 
2). VyOS-01 側の設定
VyOS のインストールが済んで、ログインユーザ名とパスワードの設定が完了した状態からの設定です。

まずはホスト名の設定と ssh を有効にしておきましょうかねぇ。

set system host-name VyOS-01
set service ssh port 22

 
続いて既存ネットワークのセグメント1 側の IPv4 アドレスを指定します。

set interfaces ethernet eth0 address 10.123.1.11/24

 
続いてブリッジインターフェースを作成します。

set interfaces bridge br0

 
そして、新規 IPv6 ネットワークに接続する eth1 をブリッジグループに入れます。 eth1 にはアドレスを付加しません。ブリッジするのでイーサーネットインターフェースとして利用します。

set interfaces ethernet eth1 bridge-group bridge br0

 
ここまで各セグメントに接続するインターフェースの設定が完了しましした。
続いて二つのセグメントを接続するための L2 トンネル部分の設定をします。今回は VyOS の L2TPv3 を利用します。
一応 VyOS の gre でも試してみたのですが bridge-group のメニューが出てこないのでブリッジグループに入れることができません。以前の vyatta では gre も bridge-group に入れることができたようなのですけどねぇ。まぁ、 IP インターフェースは bridge-group に入れることはできない。と、いうことなのでしょうなぁ。

さて。 L2TPv3 を利用するために以下のコマンドを投入します。

set interfaces l2tpv3 l2tpeth0
set interfaces l2tpv3 l2tpeth0 local-ip 10.123.1.11
set interfaces l2tpv3 l2tpeth0 remote-ip 192.168.123.21
set interfaces l2tpv3 l2tpeth0 session-id 10
set interfaces l2tpv3 l2tpeth0 peer-session-id 11
set interfaces l2tpv3 l2tpeth0 tunnel-id 20
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id 21
set interfaces l2tpv3 l2tpeth0 source-port 2030
set interfaces l2tpv3 l2tpeth0 destination-port 2031
set interfaces l2tpv3 l2tpeth0 encapsulation udp
set interfaces l2tpv3 l2tpeth0 bridge-group bridge br0

 
ちょっと説明しますと、

  • interfaces l2tpv3 を l2tpeth0 として create します。
  • local-ip は自分の IPv4 アドレスを、 remote-ip は接続先 IPv4 アドレスを指定します。
  • session-id は好きな数値を、 peer-session-id は接続先の session-id を指定します。
  • tunnel-id と peer-tunnel-id も上記と同じルールで指定します。
  • source-port と destination-port も同じ要領で指定します。それにしてもどうして peer-source-port じゃないんだろ?;-)
  • encapsulation は udp にしました。他には ip も指定できるようです。
  • 最後に l2tpeth0 を ブリッジグループに登録します。

以上で L2TPv3 トンネルの設定が完了しました。最後に commit して save して exit すれば configure モードを抜けます。
VyOS-02 側にも同じ設定を入れるとトンネルが張られます。

eth1 と l2tpeth0 はブリッジされたのでこれで IPv6 が L2 でズドーンと抜けられるようになります。

 
3). VyOS-02 の設定
まぁ、基本的には VyOS-01 で設定したのと一緒です。サクサク行きます;-)。

ホスト名と ssh の設定と eth0 に IPv4 アドレスを付加する設定。

set system host-name VyOS-02
set service ssh port 22
set interfaces ethernet eth0 address 192.168.123.21/24

 
ブリッジグループの設定

set interfaces bridge br0
set interfaces ethernet eth1 bridge-group bridge br0

 
L2TPv3の設定。


set interfaces l2tpv3 l2tpeth0
set interfaces l2tpv3 l2tpeth0 local-ip 192.168.123.21
set interfaces l2tpv3 l2tpeth0 remote-ip 10.123.1.11
set interfaces l2tpv3 l2tpeth0 session-id 11
set interfaces l2tpv3 l2tpeth0 peer-session-id 10
set interfaces l2tpv3 l2tpeth0 tunnel-id 21
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id 20
set interfaces l2tpv3 l2tpeth0 source-port 2031
set interfaces l2tpv3 l2tpeth0 destination-port 2030
set interfaces l2tpv3 l2tpeth0 encapsulation udp
set interfaces l2tpv3 l2tpeth0 bridge-group bridge br0

 
session-id・peer-session-id と tunnel-id・peer-tunnel-id そして source-port・destination-port は VyOS-01 で指定したものと値を逆にします。

以上で設定が完了ですね。

 
4). 確認方法
VyOS-01 と VyOS-02 の間で無事に L2TPv3 インターフェースが接続できているかの確認方法は以下になります。

vyos@VyOS-02:~$ show bridge br0 macs
port no mac addr                is local?       ageing timer
  2     01:05:73:a1:0f:ff       no                 2.16
  1     02:0c:29:f2:ec:f3       yes                0.00
  2     03:15:2c:73:dc:00       no                 2.07
  2     04:19:30:14:2e:c8       no                 1.14
  2     e5:9b:30:55:4e:c8       yes                0.00

 
ブリッジインターフェースの br0 の Mac アドレスを確認します。 今回はサーバ三台とスイッチポートが二つなので全部で五つの Mac アドレスが載りました。 “is local?” ってのは判りやすいですね。 yes が自分のネットワーク側で no が向こう側のネットワークに接続された機器のようです。

ついでなので VyOS の br0 にもテストのために IPv4 アドレスを付加してしまいましょう。

・VyOS-01

set interfaces bridge br0 address 172.16.101.101/24

 
・VyOS-02

set interfaces bridge br0 address 172.16.101.102/24

 

これでサーバやルータのインターフェースに ping を打って到達性が確認できれば L2 トンネルは成功です。
172.16.101.0/24 の IPv4 や 2001:470:fc1e:10::/64 の IPv6 アドレスに対して ping6 して到達性があることを確認します。

もし、この時に ping や ping6 が当たらない場合には一番上に戻って VMwareESXi の vSwitch において「無差別モード」が “承認” になっているか確認してみましょう。
僕はこの設定をすっかり忘れていて ping6 が通らずに随分と悩んでしまいましたf(^^;;。

 
5). ゲートウェイの設定
VyOS 自体に IPv6 を付加する必要が無いのであれば VyOS でのルーテイングの設定は何も必要ありません。サーバ側には IPv6 の default gateway を設定してあげます。

・FreeBSD

# route add -inet6 default 2001:470:fc1e:10::1

 
三台全てのサーバで同一のコマンドを打ちます。そして、全てのサーバはグローバル IPv6 なサイトに対してアクセス可能になったことを確認しましょう。

 
とまぁ、こんな感じで VyOS を利用することによりようやっと念願だった /64 の IPv6 の L2 トンネルができるようになりました。
本当は FreeBSD 単体でできると良いのですけどね。まぁ、それはしょーがない。

 
あと、今回のエントリでは VPN や IPSec については書いてないです。暗号化されてない L2 トンネルになります。
と、いうのも、僕は思うんですが、最近はプロトコル単位で暗号化されているのでトンネルを暗号化する必要ねんじゃね? みたいな。
ウェブ・メール・ssh・scp によるフアイル転送などはプロトコルで暗号化されています。唯一 samba かな? だったら ssh トンネル掘れば良いんじゃね? みたいな。

あ。 mDNS も L2 トンネルを抜けていくかな?だとしたら暗号化が必要だけど、考えてみるとマルチキャストを通すためには設定が一個必要だったような気がしたなぁ;-)。
まぁ、ザレゴトだということで;-)。

 
今回の設定は以上になります。ふぅ。

11月 232014
 

僕は自宅のサーバとして VMware ESXi 5.1 を利用していますが、ゲスト OS としては FreeBSD がメインで、他の OS も合わせてだいたい 10 台が動作しています。

今回は VMware ESXi 上に FreeBSD/amd64 10.0-RELEASE をインストールして、それをポートサーバとして運用し、他の FreeBSD のゲスト OS に対して FreeBSD のポートサーバから各ゲスト OS に対してシリアルコンソールからログインできるようにしてみたいと思います。

まずは今回の構成図を先に掲載しましょう。

console_cap0

o.FreeBSD でポートサーバを作成します
o.実際に D-sub 9pin ケーブルではなく VMware の機能を利用します
o.ポートは /dev/cuau0,1,2,3…. と、ゲスト OS の数だけ増やせます

 
1. ポートサーバ側のシリアルコンソールの設定
さて。まずは FreeBSD のポートサーバにシリアルポートをたくさん生やします。ポートサーバを shutdown した状態で VMware vSphere Client からポートサーバの「仮想マシン設定の編集」画面を開きます。その画面でシリアルポートを追加します。

一個目に追加したのは FreeBSD 的には cuau0 、二個目に追加したものは cuau1 になります。

console_cap3

追加するシリアルポートの「シリアルポート出力」は [名前付きパイプに接続] を選択し [次へ (>)] を押します。

console_cap1

次に「パイプ名及び属性」の設定ですが、以下の設定をします。

console_cap2

1).パイプ名
ポートサーバとゲスト OS を接続するときに利用する名前を指定します。
今回は “vm01-vm02” という名前にしました。vm01 とvm02 を接続する。と、いう意味がこもっています;-)。ポートサーバと二個目のゲスト OS を接続ときは “vm01-vm03” などと指定すれば分かりやすいでしょう。

2).近端
ポートサーバ側で利用方法ですが、ポートサーバなので [サーバ] をを指定しました。

3).遠端
[仮想マシン] を選択します。

3).デバイスのステータス
パワーオン時に接続にチェック

4).入出力モード
ポーリング時に CPU を放棄は良くわからないのですが、チェックを外しましたf(^^;;。

 
以上の手順でゲスト OS に接続する数だけシリアルポートの設定を追加し作業は完了です。ポートサーバな FreeBSD を起動しましょう。

 
2. ゲスト OS 側のシリアルコンソールの設定
1. ではポートサーバ側のシリアルポートを、ゲスト OS の数だけ追加しましたが、ゲスト OS 側ではシリアルポートは一個で十分です。

「パイプ名及び属性」の設定時に「パイプ名」のみ気をつけます。ポートサーバの cuau0 に相当する “シリアルポート 1” はパイプ名に vm01-vm02 と付けました。それと同じ名前にします。

図にするとこんな感じでしょうか。

console_cap11

接続したいモノ同士で「パイプ名」を揃える。と、いうことになり VMware ESXi 内部で結びつけてくれるようです。

 
3. ゲスト OS 側のシリアルポートの設定
これについては FreeBSD がゲスト OS であった場合には以前書いているのでそちらの URL を参考にしてください;-)。

PRIMERGY MX130 S2 を FreeBSD で利用する。

 
以上で全ての準備が整いました。必要であれば、各サーバをリブートして実際に接続できるか確認してみましょう。
僕の場合は cu(1) コマンド を利用しています。

$ cu -l /dev/cuau0
can't open log file /var/log/aculog.
Connected

FreeBSD/amd64 (freebsd-02.running-dog.net) (ttyu0)

login:

 

こんな感じになれば OK で、あとは cuau の数だけ試してみましょう。

 
さてと。最後にもう一点。では、ポートサーバのシリアル接続はどうするのだ?と、いう話があるのですが、ふむー・・。実は /etc/ttys とか変えたり、シリアルポートを追加したりして色々試したのですが、ダメでした。orz と、いうことで、今回はポートサーバと化した FreeBSD に対するシリアル接続の設定についてはナシということで・・。

ちょっと弱いような気がしないでもないんですけどねぇ・・f(^^;;。