qemu: use 9p by default

[AkihiroSuda]

qemu: 9p: graduate from experimental

template://experimental/9p will be removed right before releasing Lima v1.0.

---

default.yaml: stop discouraging writable mounts (for 9p and virtiofs)

Setting writable: true is still discouraged for reverse-sshfs due to potential connectivity issues, but it should be fine for 9p (virtio-9p-pci) and virtiofs.

---

qemu: use 9p by default

Templates for the following distro are updated to continue using reverse-sshfs, as 9p is not available on them.

• AlmaLinux
• CentOS Stream
• Debian
• openSUSE
• Oracle Linux
• Rocky Linux

Warning

Existing instances of the distros above will need running the following command:

limactl edit --mount-type=reverse-sshfs <NAME>

Close #971

---

TODOs:

• [x] Fix issues on Alpine
• [x] Parse lima-version file

[AkihiroSuda]

avoiding the automatic change to existing instances,

Yes, I wanted to do this, but couldn't figure out how we could implement this

[jandubois]

avoiding the automatic change to existing instances,

Yes, I wanted to do this, but couldn't figure out how we could implement this

We can write a lima.version file in the instance directory during limactl create. We look for the file during limactl start. If the file is missing, we assume the version is 0.18.0.

That way we can apply default settings based on the version of Lima used to create the instance.

We never update lima.version; it represents the version used to create the instance, not the version used to run it.

[AkihiroSuda]

https://github.com/lima-vm/lima/actions/runs/9738847119/job/26873042581

Alpine is seeing can't cd to /home/runner/work/lima/lima: No such file or directory errors, but I can't repro this error locally

[AkihiroSuda]

+ mount -t 9p -o 'ro,relatime,cache=8f,access=client,msize=131072,trans=virtio' mount0 /home/runner
mount: mounting mount0 on /home/runner failed: Invalid argument
LIMA 2024-07-01T07:25:44+00:00| WARNING: Failed to execute /mnt/lima-cidata/boot/04-persistent-data-volume.sh

"8f" seems quite a weird string here

8f seems to be from https://github.com/torvalds/linux/blob/v6.6/fs/9p/v9fs.h#L61

[jandubois]

Should this PR merge into a release-1.0 integration branch instead of main? Otherwise it would no longer be possible to release the tentative 0.23 release if this PR got merged.

Alternatively this could be switched to Draft mode until 0.23 is released.

[AkihiroSuda]

Should this PR merge into a release-1.0 integration branch instead of main? Otherwise it would no longer be possible to release the tentative 0.23 release if this PR got merged.

Alternatively this could be switched to Draft mode until 0.23 is released.

Can we just rename v0.23 to v1.0?

[jandubois]

Can we just rename v0.23 to v1.0?

Yes, I think that is preferable. Working on 2 releases in parallel just increases the risk of introducing regressions.

I just thought you wanted to do a 0.23 release first, as it has a separate milestone on GitHub.

[AkihiroSuda]

Can we just rename v0.23 to v1.0?

Yes, I think that is preferable. Working on 2 releases in parallel just increases the risk of introducing regressions.

I just thought you wanted to do a 0.23 release first, as it has a separate milestone on GitHub.

Unified the milestones

[AkihiroSuda]

Will rebase after merging:

• https://github.com/lima-vm/lima/pull/1951