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:

• Fix issues on Alpine
• Parse lima-version file

[jandubois]

The PR looks fine, but I have concerns about how this seems to break existing instances.

I've created a debian-12 instance with HEAD of master. I started and stopped the instance twice, and it worked fine.

I then switched to this PR branch and tried to start the instance. It hangs with Waiting for the essential requirement 1 of 3: "ssh".

I stopped the instance and modified the mount type with

$ limactl edit --mount-type reverse-sshfs debian-12

Trying to start the instance again, it still hangs with Waiting for the essential requirement 1 of 5: "ssh". The fact that it now list "1 of 5" instead of "1 of 3" shows that the mount type has been set correctly.

I stop once more, and switch back to the master branch. The instance still does not start again.

I realize that this issue exists independently of this PR, but it seems like changing the default can result in permanent damage to an instance. I haven't investigated what might be causing this.

This was on macOS Monterey 12.7.1 on Intel.

I have some other idea about avoiding the automatic change to existing instances, or at least adding a warning when waiting for requirements, but maybe the failure to switch the debian image at all should be resolved first.

[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.

[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