仮想環境のイメージ格納場所の移動

ここのところ、仕事上だけでなく自宅でも仮想環境を使うことが増えてきた。
仮想環境が増えてくるとそのイメージを保持するストレージも肥大化してくる。 ほとんどの仮想環境でデフォルトのイメージ格納先は /var 配下のディレクトリとなっているが、 OS のインストール当初にはこういうことを想定しておらず、仮想環境を使うにつれ /var が割り当てられているストレージの空き容量が圧迫される事態に陥りがちだ。
そんな時に仮想イメージ格納先を空きのあるストレージに移動する方法をまとめておく。

なお、以下はホスト環境として Debian (bullseye) や Ubuntu (22.04 LTS) を想定している。
空き容量のあるストレージが /srv 配下にマウントされていることを想定しているが、自身の環境に合わせて別のディレクトリ (/home 配下等) に読み替えて欲しい。

libvirt

VM イメージは通常 default ストレージプール (/var/lib/libvirt/images) に作成される。この格納先を変更する。

1. まずは全ての仮想マシンを停止

2. default ストレージプールを編集

$ sudo virsh pool-edit default
<pool type='dir'>
  <name>default</name>
  <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid>
  <capacity unit='bytes'>nnnnnnnnnnn</capacity>
  <allocation unit='bytes'>mmmmmmmmmmm6</allocation>
  <available unit='bytes'>aaaaaaaaaaa</available>
  <source>
  </source>
  <target>
    <path>/srv/libvirt/images</path>
    <permissions>
      <mode>0711</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

3. libvirted サービスを停止

$ sudo systemctl stop libvirtd.service

※ Warning が出るが気にしない

4. 移行先ディレクトリを作成

$ sudo mkdir -p /srv/libvirt/images

5. libvirted サービスを開始

$ sudo systemctl start libvirtd.service

6. 各 VM イメージファイルを移行先ディレクトリに移動

$ sudo mv /var/lib/libvirt/images/vm1.qcow2 /srv/libvirt/images

7. 各 VM ディスクイメージのパスを変更

$ sudo virsh edit vm1
...
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/srv/libvirt/images/vm1.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </disk>
...

8. libvirted サービスを再起動

$ sudo systemctl restart libvirtd.service

多くの仮想マシンを作成した後での移動は面倒なので、やるなら早めにやっておいたほうがいい。

Docker

Docker コンテナイメージはデフォルトで /var/lib/docker 配下に格納される。

残念ながら現状のコンテナイメージやボリュームを保持したまま移動する方法はわかっていない。 コンテナイメージ や データボリューム のバックアップ・リストア等によりデータを退避して移動する必要がある。

1. 移行先ディレクトリを作成

$ sudo mkdir -p /srv/docker

2. Docker の設定ファイルを作成

$ sudo cat >/etc/docker/daemon.json <<EOF
{
  "data-root": "/srv/docker"
}
EOF

※ 既に /etc/docker/daemon.json が存在する場合にはエディタで編集して data-root を設定する

3. docker サービスを再起動

$ sudo systemctl restart docker.service

新しい格納先にサブディレクトリが新規作成され、以降はこちらが使用される。

LXD (+ snap)

一番厄介なパターン。

LXD 導入時に lxd init コマンドでデフォルトのストレージプールを指定するが、ここで btrfs を選択することが多いと思う。 しかしながらこれに罠があり LXD の btrfs イメージファイルは /var/snap/lxd/common/lxd/disks 配下にしか置けない という残念な制約がある。 別のストレージプールを作成しても btrfs イメージファイルを使う限りはこのディレクトリ配下の容量が圧迫されるという問題は避けられない。

…ということで、しかたがなく /var/snap ディレクトリ自体を空きのあるところに移し bind マウントすることに…

1. LXD を停止

$ sudo snap stop lxd

2. snapd を停止

$ sudo systemctl stop snapd.service

3. 移行先ディレクトリを作成

$ sudo mkdir -p /srv/snap

4. snap 管理化のファイルを移行先ディレクトリに移動

$ sudo mv /var/snap/* /srv/snap

5. 移行先ディレクトリを移動元ディレクトリに bind マウントするよう /etc/fstab に追記

$ sudo vi /etc/fstab
...
/srv/snap       /var/snap   none        bind    0 0

7. bind マウント

$ sudo mount /var/snap

8. snapd を起動

$ sudo systemctl stat snapd.service

LXD のために snap もろとも移動するのはどうかとも思うが、 snap も肥大化を招く可能性のある仕組みのためこれでよしとする。

なお、移動しても btrfs のイメージサイズは以前のままなので、そのストレージプールの容量は以前と変わらない。 リサイズするには LXC のストレージサイズ変更（拡張・縮小）する 等のサイトを参照されたい。

大規模なシステム配下の業務サーバならば最初からデフォルトストレージプールとして ceph を選択するのがベストだが (そういうシステムでは普通 LXD ではなく Kubernetes 選択するはず)、どちらかというと LXD は小規模向けのコンテナシステムという認識であり btrfs は自然な選択なので、これは将来的にはなんとかして欲しいところ。