Decouple diffdisk (misnomer) from basedisk

[AkihiroSuda]

Fix #1706.

Now basedisk is immediately renamed/converted to diffdisk (not a diff despite the name) by the VM driver,
except when basedisk is an ISO9660 image.

Decoupling diffdisk from basedisk will eliminate the overhead of differencing I/O and save some disk space.

I cannot remember why I designed the disk to be split into basedisk and diffdisk.
Maybe it was to allow limactl factory-reset to retain the initial state, although the command was apparently never implemented in that way.
Maybe it was to allow multiple instances to share the same basedisk, although it was never implemented in that way, either.

[afbjorklund]

I thought it was because of Copy-On-Write?

basedisk: QEMU QCOW2 Image (v3), 3758096384 bytes
diffdisk: QEMU QCOW2 Image (v3), has backing file (path /home/anders/.lima/default/basedisk), 107374182400 bytes

657M	basedisk
196K	diffdisk

It seemed like a natural improvement, to me.

https://github.com/afbjorklund/lima-the-hard-way#disk
Even if it is not actually needed, to keep the original...

[AkihiroSuda]

ping @lima-vm/maintainers This PR has been open for more than 3 months

[AkihiroSuda]

ping @lima-vm/maintainers

Let me merge this PR to simplify the disk management before working on macOS guest support:

• VM drivers for supporting macOS guests (vz, host-user) #3618 (comment)

[jandubois]

@AkihiroSuda I've started looking at the PR, and have collected some feedback, but am not done with it yet. I find the code still pretty convoluted, especially the repeated needs to determine if an image is an ISO or not.

I thought about how it could be simplified, but I think this only works if we are able to do a migration to a cleaner layout in 2.1. So we would still be compatible with older instances, but once they are started by 2.1 they will be migrated to the new names, and no longer work with older Lima versions (one-way migration only). This means the lima-version marker would be updated to 2.1.0 as part of the migration.

I wonder if this is acceptable. If it is, then I would like to try to create an alternate PR, so we can discuss what looks better.

But if we think we need to allow people to downgrade Lima again after upgrading to 2.1, then I won't bother and just finish the review here instead.

[AkihiroSuda]

So we would still be compatible with older instances, but once they are started by 2.1 they will be migrated to the new names, and no longer work with older Lima versions (one-way migration only).

The file name is not changed in this PR

[jandubois]

So we would still be compatible with older instances, but once they are started by 2.1 they will be migrated to the new names, and no longer work with older Lima versions (one-way migration only).

The file name is not changed in this PR

I know, this was about my idea to create an alternative implementation that I think will be cleaner.

But I have an idea now how it can change filenames for existing instances using symlinks or hardlinks, so the instance would still run with older Lima versions, but also be compatible with the new implementation with the simplified logic as well. I'll try to create a proof of concept later to show what I mean.

[jandubois]

@AkihiroSuda #4587 is how I would refactor the code so we always have a disk that contains the writable volume, plus an optional iso if we are booting from an ISO. The only code that needs to look at the original image is EnsureDisk which will create symlinks accordingly.

This is fully backwards compatible because the migration only creates symlinks to the old basedisk and diffdisk files to match the new names. Everything else only references disk and iso, which also makes the driver logic simpler.

Theoretically we could rename the image file to disk or iso, but I find using a symlink nicer because ls -l tells you exactly how the instance is set up.

Let me know what you think? I've left #4587 in draft because it may need another round of review and polish, but it seems to be working fine as-is.

[AkihiroSuda]

Thanks, let's merge #4587