History of EBUG勉強会/20251122_vmmvmd (No. 9)

• History
• View the diff.
• View the diff current.
• View the source.
• Go to EBUG勉強会/20251122_vmmvmd.
  • 1 (2025-11-19 (Wed) 16:27:59)
  • 2 (2025-11-19 (Wed) 16:37:42)
  • 3 (2025-11-20 (Thu) 12:37:15)
  • 4 (2025-11-20 (Thu) 18:52:34)
  • 5 (2025-11-21 (Fri) 02:48:13)
  • 6 (2025-11-21 (Fri) 14:34:19)
  • 7 (2025-11-21 (Fri) 17:49:31)
  • 8 (2025-11-21 (Fri) 20:15:25)
  • 9 (2025-11-21 (Fri) 23:47:49)
  • 10 (2025-11-22 (Sat) 01:23:24)
  • 11 (2025-11-22 (Sat) 09:43:38)
  • 12 (2025-11-22 (Sat) 09:43:38)

---

vmm/vmd: OpenBSDの仮想環境†

構成要素†

• vmm(4) - 仮想機械モニタ(カーネル内ドライバ)
• vmd(8) - 仮想機械デーモン(仮想CPUスレッドの生成と制御)
• vmctl(8) - vmdの操作ユティリティ
• vm.conf(8) - 設定ファイル

資料: OpenBSD FAQ - Virtualization

特徴†

• シンプル。

• 以下の制限がある。
  • アーキテクチャ: i386, amd64 (UEFI未対応。Legacy BIOSのみ)

• ゲストではUniprocessorのみ

• ビデオ出力未対応(シリアルコンソールかネットワークからアクセス）

• 対応OS: OpenBSD, Linux

準備†

# #ハードウェアが対応しているか確認
# dmesg | egrep '(VMX/EPT|SVM/RVI)'

# #vmdを有効化
# rcctl enable vmd
# rcctl start vmd

# #ディスクイメージを作成
# vmctl create -s 4G OpenBSD78.img  # raw or qcow2

起動†

(ネットワークブリッジを使用しなければ)設定ファイルなしで動く。

OSのインストール†

# vmctl start -c -i 1 -L -m 2G -B cdrom -r install78.iso -d OpenBSD78.img obsd78

インストール後、起動†

# vmctl start -i 1 -L -m 2G -d OpenBSD78.img obsd78

設定†

vm.confの設定†

設定を/etc/vm.confに記述する。

# cat /etc/vm.conf
switch "uplink" {
        interface veb0
}

vm "obsd78" {
    disable
    memory 2G
    disk "/opt/vmd/OpenBSD78.img"
    interfaces 1
    interface { switch "uplink" }
}
(他にもVMがある場合は以下同様に記述)

ネットワークの設定†

前項のvm.confの設定ではVMをブリッジに接続し、外のネットワークに出られるようにしている。 これについて、ネットワークの追加設定が必要

# cat /etc/hostname.veb  # veb(4) (Virtual Ethernet Bridge)の設定
add re0
add vport0
up

# cat /etc/hostname.re0  # 実機のNICの設定
up  # 有効化するだけ

# cat /etc/hostname.vport  # vebに接続する仮想ポート。実機のアドレス設定はここで
inet autoconf              # 実H/WのNICvebを接続するとアドレスを割り振れなくなるため
inet alias 192.168.1.32 255.255.255.0
inet6 autoconf

イメージ図

VMが起動すると、tap(4)経由でveb0に接続される。

起動†

# vmctl start obsd78
vmctl: started vm 1 successfully, tty /dev/ttyp1
# vmctl status
      ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER    STATE NAME
       1 25809     1    516M    156M   ttyp1         root  running obsd78

/dev/ttyp1はVMのシリアルコンソール。以下のようにアクセスする。

# vmctl console obsd78

または、起動時に、

# vmctl start -c obsd78

内部的にcu(1)を呼び出している。

事例†

河豚板開発・ビルド環境の移行†

• シリアルコンソール設定
  • OpenBSD: bootプロンプトで、"set tty com0"、インストール時に、"Change the default console to com0?"に対しyesを指定
  • 河豚板: シリアルが有効になっていると自動的に対応する

IoTサーバの移行†

Linuxをguestとする†

実験&学習目的でLinuxを追加

• シリアルコンソール対応
  • インストール時、GRUB2でKernel Command Lineに"console=ttyS0,115200n8"を追加
  • インストール後には/etc/defaults/grubに同様に追加。
    併せて、/etc/systemd/system/serial-getty@ttyS0.service.d/override.confにServiceエントリを追加

    [Service]
    ExecStart=
    ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,9600 ttyS0 - $TERM

    その後、systemctl enable/start

※)今回は行わなかったが、過去にPlamo Linux, Alpine Linuxも動作実績あり。

雑多なトピック†

トラブル(シューティング)†

構築中に、VMが最大4つまでしか起動できず、5個目からはエラーとなる現象に遭遇した。 現象の再現状況

# rcctl start vmd
vmd(ok)
# vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER    STATE NAME
    1     -     1    512M       -       -         root  stopped OpenBSD-7.8-01
    2     -     1    512M       -       -         root  stopped OpenBSD-7.8-02
    3     -     1    512M       -       -         root  stopped OpenBSD-7.8-03
    4     -     1    512M       -       -         root  stopped OpenBSD-7.8-04
    5     -     1    512M       -       -         root  stopped OpenBSD-7.8-05
    6     -     1    512M       -       -         root  stopped OpenBSD-7.8-06
    7     -     1    512M       -       -         root  stopped OpenBSD-7.8-07
    8     -     1    512M       -       -         root  stopped OpenBSD-7.8-08
# vmctl start 1
vmctl: started vm 1 successfully, tty /dev/ttyp1
# vmctl start 2 
vmctl: started vm 2 successfully, tty /dev/ttyp2
# vmctl start 3 
vmctl: started vm 3 successfully, tty /dev/ttyp3
# vmctl start 4 
vmctl: started vm 4 successfully, tty /dev/ttyp4
# vmctl start 5 
vmctl: start vm command failed: No such file or directory
# vmctl start 6 
vmctl: start vm command failed: No such file or directory
# vmctl start 7 
vmctl: start vm command failed: No such file or directory
# vmctl start 8 
vmctl: start vm command failed: No such file or directory
# vmctl status  
   ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER    STATE NAME
    4 32605     1    516M    123M   ttyp4         root  running OpenBSD-7.8-04
    3 31865     1    516M    123M   ttyp3         root  running OpenBSD-7.8-03
    2  7926     1    516M    156M   ttyp2         root  running OpenBSD-7.8-02
    1 25809     1    516M    156M   ttyp1         root  running OpenBSD-7.8-01
    5     -     1    512M       -       -         root  stopped OpenBSD-7.8-05
    6     -     1    512M       -       -         root  stopped OpenBSD-7.8-06
    7     -     1    512M       -       -         root  stopped OpenBSD-7.8-07
    8     -     1    512M       -       -         root  stopped OpenBSD-7.8-08

ネットワークの設定を行わないと、正常に起動することが判明した。

vm.conf

vm "OpenBSD-7.8-05" {
    disable
       memory 512M
    disk "/home/vmtest/OpenBSD-7.8-05.raw"
    # interfaces 1                   ←コメントアウトすると
    # interface { switch "uplink" }  ←動く
}

この現象をOpenBSD ML (misc@、あるいはbugs@)に報告するべく、報告の英訳と推敲のためのやりとりをAIと行っているなかで「そういえば/dev/tap?はどうなっている？」となり、調査。

$ ls -l /dev/tap*
crw-------  1 root  wheel  93, 0 Nov  8 08:59 /dev/tap0
crw-------  1 root  wheel  93, 1 Nov  8 08:59 /dev/tap1
crw-------  1 root  wheel  93, 2 Nov  8 08:59 /dev/tap2
crw-------  1 root  wheel  93, 3 Nov  8 08:59 /dev/tap3

tap(4)のデバイスファイルが４つまでしか作られていないのが原因と判明。MAKEDEV tap4とし、解決。

先に説明したように、vmctlのエラーメッセージは、

vmctl: start vm command failed: No such file or directory

となっていた。これが、

vmctl: start vm command failed: /dev/tap4: No such file or directory

などとなっていれば、より迅速にトラブルシューティングできたと思われる - エラーメッセージ重要

電力収支†

これより、集約によって著しく電力効率が改善されたわけでも、悪化したわけでもない。
ただし、河豚板のビルドだけに限ってみると、概ね

• 従来: 18時間(i386) + 18時間(amd64) = 36時間
• 現在: 13時間(i386, amd64並列)

となり、処理時間が短縮された分、効率は上がった。

VMが増設されれば、改善する方向にゆくと思われる。

バックアップ†

河豚板のファイルシステム構成に沿った設計

• OS本体
  → immutable(配布系から不変)なので、バックアップせず

• ホストの動作環境(MFS上)
  → usbfadm sync でUSBメモリにバックアップ (定期的に usbfadm archive)
  → 定期的に予備HDD (1T)にコピー

• VMのイメージファイル
  → 予備HDD (1TB) に rsync で差分コピー

SAG†

仮想基盤の動作モニタ結果

• 現時点で各リソースは概ね足りている

• 興味深いのはメモリの使用状況。activeが常に1GB以下と非常に低い値で、かつ、VMの活動に影響されない。
  逆にcacheがVMの稼働に伴い大幅に変化しており、VMへははホストのcacheからメモリを割り当てているようだ。