それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

LXCの起動済みのコンテナにmacvlanのネットワークを足してホスト側ネットと通信する

LXCの起動済みのコンテナにmacvtap/macvlan を足す。

既存のコンテナ・インスタンスがあって、そこにmacvtap を追加する。

すでにあるコンテナは、次の通りのsample01を作ってある。これはlxdbr0を経由して外部と接続する。

takuya@ubuntu:~$ lxc start sample01
takuya@ubuntu:~$ lxc list
+----------+---------+---------------------+-----------+-----------+
|   NAME   |  STATE  |        IPV4         |    TYPE    | SNAPSHOTS |
+----------+---------+---------------------+-----------+-----------+
| sample01 | RUNNING | 10.135.9.111 (eth0) | CONTAINER | 0         |
+----------+---------+---------------------+-----------+-----------+

ネットワークを追加する

次のコマンドで起動中のコンテナ・インスタンスにネットワーク・インターフェイスを追加する。追加するNICはmacvlan でホスト側のネットワークに直接接続することに。

追加するコマンド。

lxc config device add sample01 mytap0 nic nictype=macvlan parent=eth0

lxc config device add で、インスタンスを指定しデバイス追加する。追加するのはnic です。

実行するとNIC接続される。

この追加したネットワークをdhcp 有効にして設定を書いておく。

cloud-init ファイルは永続化ファイルじゃないのでOS再起動で変更が消失云々と書かれているのですが、実験なのでとりあえず書く。

/etc/network/interfaces.d/50-cloud-init

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp

書いたらネットワークを再起動

/etc/init.d/networking restart

DHCPが降ってきた。

root@sample01:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:45:89:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.135.9.111/24 brd 10.135.9.255 scope global dynamic eth0
       valid_lft 3018sec preferred_lft 3018sec
    inet6 fd42:d79a:8b11:68a4:216:3eff:fe45:89a7/64 scope global dynamic mngtmpaddr
       valid_lft 3557sec preferred_lft 3557sec
20: eth1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:cc:85:e2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.11127/24 brd 192.168.11255 scope global dynamic eth1
       valid_lft 42621sec preferred_lft 42621sec

ついかしたNICはホスト側でも確認できる

takuya@ubuntu:~$ lxc list
+----------+---------+----------------------+-----------------------------------------------+-----------+-----------+
|   NAME   |  STATE  |         IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+----------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| sample01 | RUNNING | 192.168.11127 (eth1) | fd42:d79a:8b11:68a4:216:3eff:fe45:89a7 (eth0) | CONTAINER | 0         |
|          |         | 10.135.9.111 (eth0)  |                                               |           |           |
+----------+---------+----------------------+-----------------------------------------------+-----------+-----------+

ネットワークを再起動して接続したら、 ホスト側にveth が増えた。

ホスト側で ip a を叩くと veth が増えていた。

19: veth466e08c2@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
    link/ether 5e:04:fc:b6:ee:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0

んんんん。vethかぁ。macvlan の空間に接続するveth なのかなぁ。とりあえずmacvtapではなさそう

仮想マシンに追加された、ホスト側との接続用IPを確認する。ホスト側のネットワークからDHCPでIPをもらってくる

takuya@ubuntu:~$ lxc exec sample01 ip addr show eth1
20: eth1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:cc:85:e2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.11127/24 brd 192.168.11255 scope global dynamic eth1
       valid_lft 43014sec preferred_lft 43014sec
    inet6 fe80::216:3eff:fecc:85e2/64 scope link
       valid_lft forever preferred_lft forever

このIPアドレスについて、疎通を確認する。

とうぜんだけど、ホスト・ゲスト間で通信はできない。macvlan をホスト側に作っておくと通信できる。

ping 192.168.11127 -I eth0
ping 192.168.11127 -I macvlan1

永続化設定

先程は、とりあえずで /etc/networkに書いたが、macvlan の設定に問題なければ、永続化の設定を書く。または デフォルト・プロファイルに記述する。

cloud-init を使って起動されたコンテナはcloud-init の流儀に従う。debian なら /var/lib/cloud/seed/nocloud-net/network-config 、 ubuntuなら netplanですかね。

/var/lib/cloud/seed/nocloud-net/network-config

version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: dhcp
        control: auto
    name: eth1
    subnets:
      - type: dhcp
        control: auto

この他の追加方法

今回は、コンテナに直接デバイスmacvlan を追加した。

この他にも、コンテナ作成時のデフォルト設定(プロファイル)にデバイスを追加しておくと、コンテナ作成時に最初から追加された状態で初期化される。という方法を取ることもできる。

参考資料

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0535?page=2

https://linux-svr.com/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E4%BB%AE%E6%83%B3%E5%8C%96/59.php#default-bridge

https://lxd-ja.readthedocs.io/ja/latest/cloud-init/

macvtap でできた仮想マシンとホストと通信してみる。macvlan/macvtap

macvtap でできた仮想マシンとホストと通信してみる。

macvtap でできた仮想マシンとホストと通信してみる。

macvtap を使った場合、ホスト・ゲスト間の通信ができない。

しかたないので、ホストに別にNICをmacvlan で定義して、そこを経由して通信するとしてみる。

sudo ip link add dev macvlan1 link eth1 type macvlan mode bridge
sudo ip addr add 192.168.11.112/24 dev macvlan1
sudo ip link set macvlan1 up

macvtap に向けてパケットを送ってみる、応答がきて通信がができることがわかる。

ping 192.168.11.103 -I macvlan1

削除するには

sudo ip link set macvlan0 down
sudo ip addr del 192.168.11.112/24 dev macvlan0
sudo ip link del dev macvlan0 

ちゃんと macvlan 経由で出ていくことがわかる。

takuya@ubuntu:~$ ip route get 192.168.11.103
192.168.11.103 dev macvlan1 src 192.168.11.101 uid 1001
    cache
    

ちょっと理解が追いつかず怖いなと思った箇所が次の通り。

パケットはごちゃまぜ(?)になって eth0から出たはずのパケットは、内部でeth1 へ到達している。

ホストに [eth1,eth0] の2物理NICがあって、macvlan1@eth1として設定。ゲストでは macvtap はmacvtap@eth0 に割り当てたのだが、

ゲスト側のネットワークは次の通り

root@OpenWrt:/# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:00:ab:ff:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.12/24 brd 192.168.11.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feab:ff35/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:00:3a:09:af brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.107/24 brd 192.168.11.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe3a:9af/64 scope link
       valid_lft forever preferred_lft forever

ホスト側のネットワークは次の通り。

takuya@ubuntu:~$ ip a
### もともとの物理NIC
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:dd:23:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.111/24 brd 192.168.11.255 scope global dynamic eth0
       valid_lft 42628sec preferred_lft 42628sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether e8:fc:af:c7:aa:21 brd ff:ff:ff:ff:ff:ff
### ここが macvlan
5: macvlan1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:85:1b:0e:e4:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.101/24 brd 192.168.11.255 scope global dynamic macvlan1
       valid_lft 42623sec preferred_lft 42623sec
### ゲストの eth0
10: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/ether 52:54:00:ab:ff:35 brd ff:ff:ff:ff:ff:ff
### ゲストの eth1
11: macvtap1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/ether 52:54:00:3a:09:af brd ff:ff:ff:ff:ff:ff

[ホスト macvtap0@eth0 , ゲスト側eth0]、[ホスト macvtap1@eth1 , ゲスト側eth1]、がそれぞれペアとなる割当にしてある。

ここで、ホストの macvlan1@eth1 から ゲストの eth0 へ向かってping を投げると・・・到達するんですよね。ホスト外部には出ません。これがちょっと気持ち悪いと思った点。

macvlan はホスト内部で処理されてしまう。つまりホスト内部のvlan という扱いなのですかね。ちょっとモヤっとする。

ホスト・ゲストで通信ができた。

これで無事に macvtap と疎通する事ができるとわかる。

ただし、これを起動時に最初からやるのはしんどいのです。if-up / if-down スクリプトをこのご時世に書いて管理するのもちょっと。

そこでnetworkd が動いているなら、それを使うと、macvlan を起動時にと来ることができるはずです。

3つのファイルを作ります。

ぱぱっとファイルを作ります。

touch /etc/systemd/network/{eth1.network,macvlan1.netdev,macvlan1.network}

つくった。

takuya@ubuntu:~$ ll  /etc/systemd/network/*
-rw-r--r-- 1 root root 46  3月 24 22:25 /etc/systemd/network/eth1.network
-rw-r--r-- 1 root root 60  3月 24 22:22 /etc/systemd/network/macvlan1.netdev
-rw-r--r-- 1 root root 44  3月 24 22:18 /etc/systemd/network/macvlan1.network

eth1 に macvlan1 をbridge定義する 設定 macvlan1 をネットワークデバイスとする 設定 macvlan1 にIPアドレスを割り当てる 設定

ですかね

/etc/systemd/network/eth1.network

[Match]
Name=eth1

[Network]
MACVLAN=macvlan1

/etc/systemd/network/macvlan1.netdev

[NetDev]
Name=macvlan1
Kind=macvlan

[MACVLAN]
Mode=bridge

/etc/systemd/network/macvlan1.network

[Match]
Name=macvlan1

[Network]
DHCP=ipv4

再起動

sudo systemctl restart systemd-networkd.service

結果を確認

takuya@ubuntu:~$ sudo systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-03-24 22:48:36 JST; 7s ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 3526 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9257)
     CGroup: /system.slice/systemd-networkd.service
             └─3526 /lib/systemd/systemd-networkd

 3月 24 22:48:36 ubuntu systemd-networkd[3526]: macvlan1: Gained IPv6LL
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: eth1: Gained IPv6LL
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: eth0: Gained IPv6LL
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: Enumeration completed
 3月 24 22:48:36 ubuntu systemd[1]: Started Network Service.
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: macvlan1: IPv6 successfully enabled
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: eth1: IPv6 successfully enabled
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: eth0: IPv6 successfully enabled
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: macvlan1: DHCPv4 address 192.168.11.101/24 via 192.168.11.1
 3月 24 22:48:36 ubuntu systemd-networkd[3526]: eth0: DHCPv4 address 192.168.11.111/24 via 192.168.11.1

これで、networkd でも macvlan が作成されるとわかる。

netplan は非対応

raspi 4 に ubuntu を入れているので、ubuntu だしnetplan で設定しようかと思ったが、netplan は macvlan を作れないらしい。

なので if-up/if-down を書くか、/etc/network/interfacesを書くか、networkd を書く必要がある。今回は networkd に書くことで対応した。

参考資料

https://tenforward.hatenablog.com/entry/20111221/1324466720

https://major.io/2015/10/26/systemd-networkd-and-macvlan-interfaces/

Raspberry Pi4 にKVM+qemu で仮想マシンの仮想環境を作る/raspi+kvm

Raspberry Pi4 にKVM+qemu仮想マシンの実行環境を作る

Raspberry Pi4 もメモリが8GBもあれば、仮想マシンを動かすのに十分な性能があると思うんですね。

仮想マシンを動かしたらいろいろ便利そうなので、仮想マシンを動かすことにした

SDカードにOSを準備

KVMが有効な仮想マシンを動かすために、通常のRaspbianではちょっと厳しい。

Raspbian はKVMのサポートが無効化された32bit版が配布されている。動くには動くだろうが、KVMのサポートは欲しい。

そこで、KVMサポートがされたOSをインストールする。

選択肢はこの通りになる。

  • Raspbian 64bit
  • Ubuntu for raspi arm64 server
  • Arch とか

raspbianの64bit版は、KVMが有効化された状態でコンパイルされているので、Raspbianなら64bit版を使う。

わたしは、初回インストールの手間を考えて、ubuntuにした。

ubuntu には、arm4でraspiようにビルドされたイメージが配布されているので楽そうだった。

ubuntuの場合は、次のイメージを探してきて、SDカードに書き込む

ubuntu-20.04.2-preinstalled-server-arm64+raspi.img

初回起動後

初回起動したら、そのままSDカード容量に合わせて、ext4がリサイズされる。

初回アップデートも初回起動時に行われる。

ssh など必要な初回インストール作業が少なくて済むのがubuntu-server版の魅力

いつもの通り、piユーザーの代わりになる、自分のユーザーを作り、piユーザーはログインを無効化しておく。

ubuntu版の場合は、piユーザーではなく id/pw=ubuntu/ubuntu がプリインされている。

ユーザー作成

sudo adduser takuya
sudo usermod -aG ubuntu takuya
sudo usermod -aG adm takuya
sudo usermod -aG dialout takuya
sudo usermod -aG cdrom takuya
sudo usermod -aG floppy takuya
sudo usermod -aG sudo takuya
sudo usermod -aG audio takuya
sudo usermod -aG dip takuya
sudo usermod -aG video takuya
sudo usermod -aG plugdev takuya
sudo usermod -aG netdev takuya
sudo usermod -aG lxd takuya

ssh 設定

PasswordAuthentication no
Match User ubuntu Address 192.168.100.0/24
  PasswordAuthentication yes

カーネル確認

ubuntu で raspi4 にインストールしたら、この表記になった。

takuya@ubuntu:~$ uname -a
Linux ubuntu 5.4.0-1030-raspi #33-Ubuntu SMP PREEMPT Wed Feb 24 11:20:11 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

apt 設定

インストールを最小限にしておく。

echo -e  "APT::Install-Suggests 0;\nAPT::Install-Recommends 0;" | sudo tee /etc/apt/apt.conf.d/00-no-install-recommends

apt ミラーサーバー設定(わからない

apt ミラー設定は、ミラーサーバーの設定がわからない・・・ちょっと特殊なバイナリ( arm64 )なのであとに回す

たとえばJAISTミラーには、ARM64がない。arm/arm64バイナリはミラー郡の提供に含まれないっぽい。

ちょっと特殊みたいなので、いつものUbuntuミラーサーバーは使えないっぽい。

apt の更新

sudo apt update && sudo apt upgrade -y

タイムゾーンの設定

sudo timedatectl set-timezone Asia/Tokyo

ロケール設定

sudo apt-get install language-pack-ja
sudo update-locale LANG=ja_JP.UTF-8
sudo locale-gen
sudo locale -a

または

sudo dpkg-reconfigure locales

GUIでやるなら後者が確実。

http://www.dreamedge.net/archives/111

LXD 最初から入ってる。つおい

ちなみに、ubuntuだと、Snapcraftの snapd がLXDで最初から導入されているので、qemu/libvirtを使わなくても仮想マシン(コンテナ)を手軽に作れる。

わざわざqemukvmを動かさなくても、殆どの場合LXC/lxd で十分な気もする。

takuya@ubuntu:~$ sudo snap list
Name    Version   Rev    Tracking       Publisher   Notes
core18  20210128  1990   latest/stable  canonical✓  base
lxd     4.0.4     19040  4.0/stable/…   canonical✓  -
snapd   2.49      11115  latest/stable  canonical✓  snapd

kvm qemulibvirt で仮想環境を作る

kvm が使えるかどうか、念のためにチェック

sudo apt install cpu-checker

KVM が使える!。raspberry Pi4 でもKVMが使えます。

takuya@ubuntu:~$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

kvm qemu 一式をインストールする

kvmqemulibvirt 経由で使うために、つぎをインストール。

sudo apt -y install qemu-kvm libvirt-daemon-system \
libvirt-daemon virtinst bridge-utils libguestfs-tools virt-top

uefi をインストール

qemu-efi がないと動かない。(aarch64用)

sudo apt install qemu-efi

virtio で ネットワークを扱う。

インストールしてないと、failed to find romfile "efi-virtio.rom" になり、ネットワークを扱えない仮想マシンになった。

sudo apt install ipxe-qemu

virbr0 を使う。

libvirtd が提供する virbr0 を使うために、dnsmasq が必要だった。インストールが必要だった。

sudo apt install dnsmasq

virt/kvm グループに参加

自分のユーザーで、system virshを使いたいのでグループに参加しておく。ユーザーセッションでもいいんだけど、qemu://system も使えたほうが楽だし。

sudo usermod -aG libvirt takuya
sudo usermod -aG libvirt-qemu takuya
sudo usermod -aG kvm takuya

qemu仮想マシンを起動(openwrt)

とりあえず、OpenWRTでも動かしてみようか。

openwrt には、arm64の仮想マシンで動かすための armvirt/64bit のバイナリが配布されていて、起動方法も公式Wikiに記載されていたのでこれを起動しようと思う。

openwrtの公式→ https://openwrt.org/docs/guide-user/virtualization/qemu#openwrt_in_qemu_aarch64

イメージをダウンロード → https://downloads.openwrt.org/releases/19.07.6/targets/armvirt/64/

ダウンロードしたら、ext4squashfs は qcow2 に変えておく qemu-img convert -f raw $in -O qcow2 $out

とりあえず、起動してみる。

KERNEL_IMAGE=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-Image
INITRAMFS=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-Image-initramfs
DISK=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-root.squashfs.qcow2
sudo qemu-system-aarch64 --enable-kvm -m 1024 -smp 2 -cpu host -M virt -nographic \
  -kernel $INITRAMFS \
  -drive if=none,file=$DISK,id=hd0 \
  -device virtio-blk-device,drive=hd0 \

OpenWRTがちゃんと起動する。

qemuの起動方法をよく知らないので、マニュアルが助かった。

virt-install仮想マシンを作成

qemukvm 仮想マシン起動ができたので、同じように、virt-install から libvirt経由で使える仮想マシンとしてインストールしてみる。

ネットワークはとりあえず、br0 を作ってそれを使うことに。

br0を作成

sudo brctl addbr br0
sudo brctl addif br0 eth1
sudo ip link set br0 up

eth1 を使ってるのは SSH接続が切れないように。USB-LANをRaspiに挿してeth1として使ってる。SSH経由で作業するeth0 (メイン・オンボード)をbr0に入れるとSSH経由で完結しなくなる面倒が起きる。それを避けるために eth1を使った。

virt-install仮想マシン作成。(openwrt)

KERNEL_IMAGE=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-Image
INITRAMFS=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-Image-initramfs
DISK=/var/lib/libvirt/images/openwrt-19.07.7-armvirt-64-root.ext4.qcow2

sudo virt-install   \
  --connect qemu:///system \
  --name=wrt01  \
  --disk path=$DISK,format=qcow,device=disk,bus=virtio  \
  --ram=512 \
  --arch=aarch64 \
  --cpu host-passthrough \
  --virt-type kvm \
  --graphics none \
  --network bridge=br0,model=virtio \
  --boot kernel=$KERNEL_IMAGE,initrd=$INITRAMFS,kernel_args='root=fe00' \
  --import \
  --features acpi=off \
 

acpiをOFFにしないとエラーなる。仕方ないこととはいえ、ちょっとめんどくさい。

acpiが使えないので、virsh から shutdown が使えない。デメリットである。終了はdestroyをする必要がある。

ただ、macvtap などネットワークの管理がvirt-managerに任せられるのでメリットである。

ubuntu仮想マシンを起動。

qemuubuntu 仮想マシンを起動しよう。とおもったんだけど、LXCあるから別にいらないのでパス。

raspbian の仮想マシンを起動

Raspbianがちゃんと動かせたら、RaspiAP のプロジェクトRaspberry Pi - Wifi Routerのプロジェクトの成果物を仮想マシンで動かせるじゃん。

って思ったんだけど、よく考えたら、仮想マシンWifi渡せないしRaspApプロジェクト動かせないんだよね。。どうせWifiバイスをUSBパススルーは地獄なんだし。OpenWRTが仮想マシンで動いてたら、スマホから扱えるルーターにはなるわけだし。

とりあえずraspbian を このraspi ubuntu で起動しよう。とおもったんだけど、よく考えたら、raspiのarmのあれこれだとか吸収しても、ちょっと風変わりなDebianになるだけなので、労苦の割に使いにくいものにしかならない。Debian欲しいならLXDで素のDebian起動したらいいじゃないかと思ったのでパス。

adguard home

Raspiにadguard homeとか入れたら面白そうだと思ってて、仮想マシンでやろうと思ってたんだけど、UbuntuにしたのでLXD/Docker使えるので、これもVMじゃなくても良くなってしまった。

kvm+qemuな wrtから iperf3をやってみる。

仮想マシンで起動したwrt から

root@OpenWrt:~# iperf3 -c 192.168.100.1
(...
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.06 GBytes   912 Mbits/sec  352             sender
[  5]   0.00-10.05  sec  1.06 GBytes   905 Mbits/sec                  receiver
iperf Done.

ubuntuをインストールしたraspiから

takuya@ubuntu:~$ iperf3 -c 192.168.100.1
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec  119             sender
[  5]   0.00-10.01  sec  1.09 GBytes   937 Mbits/sec                  receiver

仮想マシン化による速度低下は気にならないレベルだった

まとめ raspi4で kvm + qemu 起動

8GBのメモリがあると快適に動く。

Ubuntuを使うと楽ちん。ubuntuのRaspi arm64 server版だと、最初からKVMが有効になってた。

らくにqemu と libvirtdで仮想マシンを扱えるのだけど、UbuntuだとSnapdとLXDがインストール済みで配布されているので。よくあるLinux仮想マシンを扱う場合ではdocker / lxd が使えるんでそんなにメリットはないかも。

WindowsのArmかOpenWrtくらいしか動かしてメリットあるものはないと思うんだ。仮想マシンでwrt動かせるから、Raspi4をルーターとして放置しつつ他の用途にも使えそうで熱い感じはある。自分で、arm64用になにかプログラミングするならとてもいいと思うんだけどね。

今回は、Ubuntuサーバー版をつかって仮想マシン作ったんだけど、GUIを扱うときにqemuでそこそこそ軽快に動かせるから管理は楽になるかもしれない。

純粋なサーバーとしてRaspiの4K2画面出せるグラフィック系の機能を殆ど使わないので、だいぶ勿体ない贅沢な使い方だとは思う。

参考

http://www.rcps.jp/doku.php?id=linux:kvm

https://www.kkaneko.jp/tools/container/ubuntu_qemu.html

https://kb.novaordis.com/index.php/Virt-install#Optional_Installation_Method_Option

https://dustymabe.com/2020/01/30/virt-install-boot-from-specific-kernel/initrd-just-for-install/

http://manpages.ubuntu.com/manpages/eoan/man1/virt-install.1.html

https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/

https://openwrt.org/docs/guide-user/virtualization/qemu#openwrt_in_qemu_aarch64

https://kitsunemimi.pw/notes/posts/running-windows-10-for-arm64-in-a-qemu-virtual-machine.html