lima-vm
additionalDisks: support for optional and customizable mount point
Description
Currently, the additional disks are always mounted at /mnt/lima-<disk-name> and expected to be one of the support fileystem formats e.g. ext2-4, xfs
The current behaviour when the filesystem type specified is unsupported is that the disk is simply ignored by Lima during startup.
I would like to propose that we provide explicit option to disable mounting the disk, and an extra option to customize the mount point, which should give us a configuration option similar to the following.
additionalDisks:
- name: string
format: bool
mount: bool # if the disk should be auto-mounted by Lima
mountPoint: string # custom mountPoint for the disk
fsType: string
PS: Colima relies on the current behaviour to prevent Lima from mounting a disk.
I think a custom mountPoint makes sense. Assuming it would be a *string, then nil would be the default mount point, and the empty string could mean to not mount it. But I'm not really averse to having a separate mount boolean.
I think though that format, fsType, and fsArgs should not be properties of the additionalDisks elements. They should have been specified in limactl disk create, and the host agent would automatically retrieve them from there.
It makes no sense that an instance can specify them because it is not possible that one instance mounts a disk as ext4 and another one later as btrfs. These are properties of the disk itself, and not of how a specific instance uses them.
I think we should fix this, but there is no time before Lima 2.0 to deal with it. We can probably do it in a backwards compatible way anyways.
I think a custom mountPoint makes sense. Assuming it would be a *string, then nil would be the default mount point, and the empty string could mean to not mount it. But I'm not really averse to having a separate mount boolean.
I am fine with either, I am mainly opting for clarity.
It makes no sense that an instance can specify them because it is not possible that one instance mounts a disk as ext4 and another one later as btrfs. These are properties of the disk itself, and not of how a specific instance uses them.
I think you are assuming that the instances cannot (or maybe should not) manipulate the disks, and they can. I can understand for the root disk, but additional disks should not be constrained to that IMO.
I think we should fix this, but there is no time before Lima 2.0 to deal with it. We can probably do it in a backwards compatible way anyways.
I am fine with delaying a proper solution, I am more concerned about backward compatibility so nothing breaks.
I am pointing at the following capabilities.
- Ability for Lima to handle the formatting and mounting - currently being done
- Ability for Lima to mount at a custom mount point.
- Ability for Lima to only attach the disk and ignore both the formatting and mounting.
I am open to contributing the code whenever we conclude on the way forward.
Thanks :)
I think a custom mountPoint makes sense. Assuming it would be a *string, then nil would be the default mount point, and the empty string could mean to not mount it. But I'm not really averse to having a separate mount boolean.
I am fine with either, I am mainly opting for clarity.
I think clarity somewhat favours having a separate mount option.
It makes no sense that an instance can specify them because it is not possible that one instance mounts a disk as ext4 and another one later as btrfs. These are properties of the disk itself, and not of how a specific instance uses them.
I think you are assuming that the instances cannot (or maybe should not) manipulate the disks, and they can. I can understand for the root disk, but additional disks should not be constrained to that IMO.
No, I'm not. I just wanted to point out that you cannot specify the same disk using different filesystems in different instances.
The format and fsType attributes are meant to specify how the disk should be formatted when it is being created. Now we don't have a way to format a disk with a random Linux filesystem on macOS, so we postpone the formatting until we have it attached to a running instance, and then we format but only if it is not already formatted.
Afterwards fsType and fsArgs specify how the disk should be mounted, but at least fsType can never be changed after the disk has been formatted. We don't support reformatting the disk because you would lose all the content.
I think this strongly shows that these are properties of the disk, and not of the instance.
If you want to manage the disk yourself, then set format: false and fsType and fsAttr will be ignored.
I think we should fix this, but there is no time before Lima 2.0 to deal with it. We can probably do it in a backwards compatible way anyways.
I am fine with delaying a proper solution, I am more concerned about backward compatibility so nothing breaks.
Yes, I'm in full agreement.
My (unreflected) idea so far is: add the format, fsType, and fsArgs properties to limactl disk create and store them with the other metadata. They can be left empty.
When you start an instance with an additional disk, these properties will be filled in from the disk metadata. If the lima.yaml specifies these settings, then the corresponding disk metadata must be either empty, or have the identical value.
I think this is completely backwards compatible, and you can migrate at your own pace where you only specify the disk name, mountPoint, and mount option in lima.yaml and get the remainder from the disk metadata.
I am pointing at the following capabilities.
- Ability for Lima to handle the formatting and mounting - currently being done
This would continue to work as before. It would be nice if limactl disk create could format the disk, but I don't know if this is reasonably possible. Also any instance that is supposed to mount a disk of a specific format should be able to format it using the same format, so this is not really important anyways.
- Ability for Lima to mount at a custom mount point.
This would be added by the new mountPoint property.
- Ability for Lima to only attach the disk and ignore both the formatting and mounting.
I would expect this to be implied by format: false, but you may also need to leave fsType empty. We probably want to keep this working however it is working right now.
I am open to contributing the code whenever we conclude on the way forward.
Thank you! But let's wait until everyone had their chance to provide their opinion.