lima-vm / lima

Linux virtual machines, with a focus on running containers
https://lima-vm.io/
Apache License 2.0
15k stars 585 forks source link

Past mounts are persisted through stop/start cycles #2370

Open moenodedev opened 3 months ago

moenodedev commented 3 months ago

Description

Instructions:

  1. Stop the lima instance
  2. Change your home mount point

    mounts:
    - location: "~"
    -    mountPoint: "/home/development"
    +    mountPoint: "/home/trojan1"
     writable: true
    1. Start the lima instance
    2. Repeat with /home/trojan2, /home/trojan3, /home/trojan4

    After doing this 4 times:

    • /home/trojan1 is empty (not mounted) and owned by root
    • /home/trojan2 is empty (not mounted) and owned by root
    • /home/trojan3 is mounted and owned by $USER
    • /home/trojan4 is mounted and owned by $USER
    $ ls -lA /home 
    total 5
    drwxr-sr-x  2 alpine      alpine      1024 Jan 28 14:51 alpine
    drwxr-xr-x  3 root        root        1024 May 25 13:16 development
    drwxr-xr-x  3 development development 1024 May 25 12:49 development.linux
    drwxr-xr-x  2 root        root        1024 May 25 13:04 trojan1
    drwxr-xr-x  2 root        root        1024 May 25 13:13 trojan2
    drwx------ 11 development development  320 May 25 13:22 trojan3
    drwx------ 11 development development  320 May 25 13:22 trojan4
$ mount | grep ^mount
mount0 on /home/trojan3 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/trojan4 type virtiofs (rw,relatime)

Discussion: #2359

Configuration:

disk: "15GiB"

mountType: "virtiofs"
mounts:
  - location: "~"
    mountPoint: "/home/development"
    writable: true
  - location: "/tmp/lima"
    writable: true

vmType: "vz"
os: "Linux"
arch: "aarch64"

audio:
  device: "vz"
video:
  display: "none"
networks:
  - vzNAT: true

images:
  - location: "https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-aarch64-uefi-cloudinit-r0.qcow2"
    digest: "sha512:d5e69cff0ecb0fd3850bd78f56f66131115934df27b2373c35a85a74b9def52822134dd43f90b4fabe239fdd4452026cb45f1c8f0b36a43af69335a26f0959b5"
    arch: "aarch64"
containerd:
  system: false
  user: false
moenodedev commented 3 months ago

If I change the mount point back to the original (a mountPoint that was already used) the previous mountPoint is still mounted:

 mounts:
   - location: "~"
-    mountPoint: "/home/trojan4"
+    mountPoint: "/home/development"
     writable: true
$ mount | grep ^mount
mount0 on /home/trojan4 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/development type virtiofs (rw,relatime)

The original does get the correct permissions and contents:

$ ls -ld /home/development
drwx------ 11 development development 352 May 25 13:33 /home/development
moenodedev commented 3 months ago

Another stop/start makes the instance forget the previous mount:

$ mount | grep ^mount
mount0 on /home/development type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
afbjorklund commented 3 months ago

Is it important to remove the empty directories ? We could add some rmdir code, matching the mkdir.

https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/25-guestagent-base.sh#L11

https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/05-lima-disks.sh#L31

EDIT: Not sure what VZ is doing, only know QEMU

afbjorklund commented 3 months ago

Supposedly one could add some systemd script to clean up the mount points, and something similar for openrc

https://www.freedesktop.org/software/systemd/man/latest/systemd-poweroff.service.html

/usr/lib/systemd/system-shutdown/lima.shutdown

/etc/local.d/lima.stop

EDIT: Nope, these scripts are run when all filesystems are unmounted (or read-only), so too late to clean up there

jandubois commented 3 months ago

Is it important to remove the empty directories ? We could add some rmdir code, matching the mkdir.

We could, as long as we only remove empty directories (and ignore errors when they are not empty).

We cannot force-remove the mount point because it may exist with content the user wants to keep, and it was only temporarily shadowed by a mount.

afbjorklund commented 3 months ago

I think rmdir should be OK (leave files and fail), but the timing is tricky...

I was trying with a "lazy" (fuser)unmount, but any processes using it needs to be stopped first