lima-vm
Consider using ASIF sparse disk images instead of RAW
Description
macOS 26 supports ASIF sparse disk images. Perhaps Lima should consider using this image type on macOS hosts which support it?
Related info:
- https://eclecticlight.co/2025/09/17/should-you-use-tahoes-new-asif-disk-images/
- https://developer.apple.com/documentation/virtualization/vzdiskimagestoragedeviceattachment/
Perhaps Lima should consider using this image type on macOS hosts which support it?
Why? According to the blog post you linked to it is only useful when you store the VM image on a remote filesystem, which is a niche use case at best right now[^1].
[^1]: Says the person who used to store VMware Fusion machines on a NAS before... 😄
We still need to figure out the best way to deal with raw vs qcow2 and caching. And we'll need additional support for tarballs of rootfs for things like Apple containers or WSL2 distros. So maybe supporting an additional format on macOS will slot in with this. The actual code specifically for supporting ASIF should be minor in comparison.
[^1]: Says the person who used to store VMware Fusion machines on a NAS before... 😄
I'm also guilty of storing vm images on network devices... 😅
I agree it's a niche use-case but I think that it would be best to align with the best native technologies that a platform provides. Going forward, it makes sense to assume that all new implementations should be using ASIF disk images.
Going forward, it makes sense to assume that all new implementations should be using ASIF disk images.
Maybe I misread the article, but it sounds that ASIF has less than half the performance of a RAW disk when the underlying filesystem is APFS, which is the case for all local macOS disks (and even worse for unencrypted disks). So using ASIF would give away half the performance for no benefit for the common use case.
@jandubois It has half the performance of a sparse bundle, not RAW. It is slightly slower than RAW though, that is true.
I suppose it's a matter of compromise. Supporting both RAW and ASIF and allowing the user to choose the underlying format according to their use case might be an option, although it adds some complexity.
I opened PR #4327, which makes diffdisk bootable even in ASIF format.
It also includes a shell script that converts diffdisk from raw to ASIF.
I'm not sure about the advantages/disadvantages, but the difference from raw is that the file size looks different when viewed in ls.
$ LANG= ls -la ~/.lima/asif-test/diffdisk*
-rw-r--r--@ 1 norio staff 3283177472 Nov 10 19:26 /Users/norio/.lima/asif-test/diffdisk
-rw-r--r--@ 1 norio staff 107374182400 Nov 10 19:10 /Users/norio/.lima/asif-test/diffdisk.raw
$ LANG= du ~/.lima/asif-test/diffdisk*
6042832 /Users/norio/.lima/asif-test/diffdisk
5974000 /Users/norio/.lima/asif-test/diffdisk.raw
the file size looks different when viewed in
ls.
That's because raw is using a sparse file. You need to use du to check actual disk usage:
❯ ls -lh diffdisk
-rw-r--r--@ 1 jan staff 100G Nov 10 10:21 diffdisk
❯ du -h diffdisk
3.1G diffdisk
That's why ASIF is better when storing the image on a volume that doesn't have native support for sparse files: it implements the sparse logic at the image layer. But when storing it on a filesystem like APFS, that has sparse file support, it has less than half the performance of using sparse files from the host filesystem itself.