はじめに

Conteiner Native な時代になったとは言え、VM は不滅でしょう。
VM で動く OS は Provisoning Script で構築するのが標準的に行われています。
Provisioning Script の開発は、Cloud 上の Computing resources や、手元の Local VM ですることが多いのではないでしょうか。
Provisioning Script をメンテナンスし続けるためには、開発環境がとても重要になります。
ここでは、Provisioning Script の開発環境として Lima 使う方法について説明してみたいと思います。

Local VM で Provisioning Script を開発する

VM 環境の Provisioning Script の開発と言えば、Local VM を使った開発が便利です。
Vagrant なら Sahara plugin で rollback と apply を繰り返せる為、動作確認がとても楽です。
こういったナレッジは 2011 年頃から 10 年以上続けられてきたのかなと思います。

しかし、Virtual Box の Apple Silicon 対応が停滞したことにより、Mac において実質公平に手が届く Local VM を使うオプションが閉ざされているのが実情となりました。
これは、Virtual Box の Testbuilds に更新があれば状況が変わるかもしれません。
現状、Apple Silicon においては、QEMU を拡張した UTM にも期待したいですが UTM Provider 追加の進展がなく Vagrant 以外の選択肢を求める動機もあるように思います。

この課題を解決する選択肢として挙げられるのが、Lima への移行だと考えます。
Lima は、Vagrant の様に VM の定義を設定ファイルにて行うことができます。
また、利用する VM となる QEMU は Apple Silicon に対応しており、目的に合致しています。
QEMU なので VM の実行は Intel-on-ARM や ARM-on-Intel もサポートされています。
この他、Vagrant でしてきたことが表 1-1 で示す様に、概ね揃っています。
このことから、Lima への置き換えによる開発は十分できると言えます。

▼ 表 1-1 Vagrant と Lima の置き換え対応表

Vagrant でしてきたこと	Lima に置き換えると
Sahara plugin による Image rollback	Lima Snapshot 機能による Image rollback
Host OS のディレクトリマウント	sshfs を用いたディレクトリマウント
Provisioning Tool による構築	SSH と Local マウントを共にサポート
複数 VM を建てて内部通信で環境構築	VM を複数起動可能で通信も可能
Packer 等で独自イメージ作成	サポートは無いが、Script で実装は可能
Guest Agent の追加	cidata として cloud-init でサポート
Vagrant Cloud からイメージ取得	公式の標準イメージが取れるのみ
Community Plugin による開発支援	なし

Snapshot 取得と Rollback

任意の時点を復元ポイントとして保持し、任意のタイミングで戻すことができる機能。
Lima における Snapshot 機能は現時点では Experimental features 扱いとなっています。
こちらは QEMU のスナップショットモード機能に依存する形で実現している様です。

Snapshot 取得には limactl snapshot create <vm_name> --tag "<snapshot_name>" の形式で実行することで実現します。

❯ limactl snapshot create fedora --tag "fedora-$(date '+%Y%m%d%H%M%S')"
WARN[0000] `limactl snapshot` is experimental
INFO[0000] Sending HMP savevm command

取得した Snapshot の一覧は limactl snapshot list <vm_name> で一望できます。

❯ limactl snapshot list fedora
WARN[0000] `limactl snapshot` is experimental
INFO[0000] Sending HMP info command
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
--        fedora-20240221135928 1.72 GiB 2024-02-21 13:59:28 00:13:03.327

Rollback 方法は limactl snapshot apply <vm_name> --tag <snapshot_name> で適用します。これは複数の復元ポイントの中から任意の時点を選択できると解釈して良いです。

❯ limactl snapshot apply fedora --tag fedora-20240221135928
WARN[0000] `limactl snapshot` is experimental
INFO[0000] Sending HMP loadvm command

Snapshot 削除方法は limactl snapshot delete <vm_name> --tag <snapshot_name> で削除となります。

❯ limactl snapshot delete fedora --tag fedora-20240221135928
WARN[0000] `limactl snapshot` is experimental
INFO[0000] Sending HMP delvm command

Host Path の Mount

VM 上から Host 側のファイルやディレクトリをマウントする方法は QEMU の機能を使った Experimental な方法もいくつか提供されていますが、Lima は標準で CIDATA 内部の lima.env ファイルで LIMA_CIDATA_HOSTHOME_MOUNTPOINT に指定されたディレクトリをマウントする様に作られています。こちらは自動で作られるので設定不要です。
Host Path を Mount して読み書きができるので、Provisioning Script の実行に使えます。

default で設定される sshfs 以外を使うケースは、他のマウントオプションも用意されてるので、そちらも試してみると良いと思います。

Provisioning Script の開発

前述した様に Host Path の読み書きが出来るので、VM 内で Provisioning を実行できます。
また、Snapshot を利用して Rollback すれば、繰り返し変更の動作を確認可能です。
具体例として、Ansible Playbook の Local 実行用の開発環境として便利です。

Image ファイルの共有

Lima には公式の templates が存在していますが、コミュニティのイメージを利用する仕組みは存在しないため、都度 Provisioning が必須となリます。
最近ではセキュリティの観点から、誰かが作ってくれた非公式なイメージを使うモチベーションが昔ほど少なくなってきてるのかなと思います。
それでも公開や共有したいケースであれば、個人でイメージをホストして共有することもできます。

https:// スキームを付けた場合は Web 経由でイメージを取得する動きになリます。
スキームなしなら、直接そのパスにアクセスして VM を起動する様になります。

vmType: "qemu"
arch: "x86_64"
cpus: 2
memory: "8Gib"
images:
  - location: "https://example.com/original-image.qcow2"
    arch: "x86_64"
    digest: "sha256:xxx..."
  - location: "/home/example/lima-vm/original-image.qcow2"
    arch: "x86_64"
    digest: "sha256:xxx..."
mounts:
  - location: "~"
  - location: "/tmp/lima"
    writable: true
containerd:
  system: false
  user: false
firmware:
  legacyBIOS: true
cpuType:
  x86_64: "Haswell-v4"

Lima で Template に無い OS を使う

qcow2 形式のイメージを用意できれば、iso から作成することも可能であり、QEMU と cloud-init が使えれば、テンプレートに無い OS の利用も可能となります。
具体例として AWS が公式で公開中の Amazon Linux 2 を Lima 用にビルドしてみます。

こちらは、現時点で AWS のサポート期限が予告されていますが、現行でまだ利用しているケースもあるかなと思いますので、対象としてみました。

Lima 用にパッケージ追加や cloud-init の設定が必要なためスクリプトを作成しました。

これをクローンして build.sh を実行すると、QEMU が起動してビルドされます。
手順に従い amzn2.yaml を指定すると Amazon Linux 2 が起動します。

limactl shell amzn2 でログインして、カーネル情報と motd の情報をチェックすると Amazon Linux 2 であることが確認できます。

❯ limactl shell amzn2
[tigerroll@lima-amzn2 amzn2-lima]$ uname -a
Linux lima-amzn2 4.14.336-256.559.amzn2.x86_64 #1 SMP Tue Feb 13 09:50:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
[tigerroll@lima-amzn2 amzn2-lima]$ cat /etc/motd
   ,     #_
   ~\_  ####_        Amazon Linux 2
  ~~  \_#####\
  ~~     \###|       AL2 End of Life is 2025-06-30.
  ~~       \#/ ___
   ~~       V~' '->
    ~~~         /    A newer version of Amazon Linux is available!
      ~~._.   _/
         _/ _/       Amazon Linux 2023, GA and supported until 2028-03-15.
       _/m/'           https://aws.amazon.com/linux/amazon-linux-2023/

[tigerroll@lima-amzn2 amzn2-lima]$

ディレクトリのマウント状況も確認してみました。
Lima で Host Path をマウントできてることが確認できます。

[tigerroll@lima-amzn2 amzn2-lima]$ df
Filesystem       1K-blocks     Used Available Use% Mounted on
devtmpfs           4060036        0   4060036   0% /dev
tmpfs              4077392        0   4077392   0% /dev/shm
tmpfs              4077392      544   4076848   1% /run
tmpfs              4077392        0   4077392   0% /sys/fs/cgroup
/dev/vda1        104842736  1805048 103037688   2% /
/dev/sr0             38228    38228         0 100% /mnt/lima-cidata
tmpfs               815480        0    815480   0% /run/user/1000
:/home/tigerroll 498443264 82431564 414262452  17% /home/tigerroll
:/tmp/lima         8111920     1828   8110092   1% /tmp/lima
[tigerroll@lima-amzn2 amzn2-lima]$

所感

Apple Silicon ユーザにも手の届く VM 環境を提供できる素晴らしい結果でした。
ここまで出来ると、もう Lima で十分やれるなと思うばかりです。
Lima は Mac だけでなく Linux や WLS2 もサポートしてるので、のりかえを検討しても良いかもしれません。