Background

Lima has a setting that enables forwarding filesystem change notifications on the host to inotify events in the guest. It is enabled in lima.yaml:

mountInotify: true

It works by the host agent watching for filesystem change events, sending them to the guest agent, which will then "touch" the file inside the guest to trigger the kernel to send an inotify event.

This means there are some limitations:

• it only works for writable mounts (otherwise the guest agent cannot modify the directory entries)
• only ATTRIB events are generated (seems sufficient for hot-reload tools)
• there is no notification of file deletes

Implemented in Lima by Support for inotify in mounted directories.

Feature request

We want to have a setting --experimental.virtual-machine.mount.inotify to enable this feature, and also a corresponding checkbox on the Volume Preference page.

There should be a BATS test that confirms this feature is working.

Concerns

Inotify support can generate a lot of traffic between host and guestagent. This is somewhat mitigated by using the GRPC port forwarder, which is now the default.

However, Rancher Desktop also mounts more directories than a regular Lima template, and it mounts all of them as writable.

For example it mounts the whole home directory, which on macOS includes the ~/Library tree, which may have frequent changes due to other locally running software.

Other macOS mounts are /var/folders and /private/var/folders (the former is just a symlink to the latter, but it depends on the mount setting how this is represented inside the guest). We may want to restrict the mount to just the $TMPVAR folder instead, to avoid getting notifications for all the other folders.

Maybe this is not an issue, but we need to confirm how much traffic will be generated by running e.g. IDEs and builds on the host while Rancher Desktop is running. We need to watch for delays in using the VM, usage of host CPU and memory, and also for running out of file handles or file system watcher slots.

Closing this issue should also close #1979.