For many years, most types of disk image were inefficient in their use of storage space, as they occupied their full size on disk. Until recently, when you created a 5 GB read-write UDIF disk image, one of the most popular, it invariably took up 5 GB in storage, even when empty. This also applied to the raw disk images used by Virtual Machines: give a VM 100 GB, and that’s just what it took on disk. With the introduction of sparse files in APFS, this has changed, and many disk images now only take the space they need. I’m not sure exactly when this change occurred, as Apple still doesn’t appear to have documented it, but it seems to have changed with macOS Monterey.

This is easiest to see with a plain read-write disk image, created using DropDMG or Disk Utility.

Disk image

Here’s one I made earlier, a whole 350 GB in size. When it’s created, it’s automatically attached and mounted at full size. For the sake of example, I then copied a large IPSW to it, so it wasn’t entirely empty.

Unmount it and Get Info on the disk image and you’ll see it does still take up a full 350 GB on disk. Mount it again, though, and APFS works its magic. You can see this in LogUI, or the custom log extract provided by Mints.

When unmounted again it has shrunk down to take little more than the size of the IPSW file in it, at just over 17 GB. That’s less than 5% of its nominal size, without using any compression.

It’s worth looking through entries in the log made by APFS for the mount process. First, APFS checks whether the data store for the disk image is already sparse:
01.470 container_backingstore_is_sparse:1652: Image url file:///Volumes/LaCie2tb/350gbudif.dmg Image path /Volumes/LaCie2tb/350gbudif.dmg
01.470 container_backingstore_is_sparse:1659: Image /Volumes/LaCie2tb/350gbudif.dmg is a flat file, do not consider as sparse

It then sets it to sparse, ready for sparsification:
01.475 handle_apfs_set_backingstore:6207: disk9s1 Set backing store as sparse
01.475 handle_apfs_set_backingstore:6240: disk9 Backing storage is a raw file

Space Manager performs an initial scan for free blocks without any Trimming:
01.479 spaceman_scan_free_blocks:4136: disk9 scan took 0.004272 s (no trims)
01.479 spaceman_fxc_print_stats:477: disk9 dev 0 smfree 81258479/85398014 table 4/452 blocks 81258479 32766:20314619:79974226 100.00% range 35869:85362145 99.95% scans 1

Space Manager then scans and Trims free storage blocks, taking just over 0.7 second to complete:
02.196 spaceman_scan_free_blocks:4106: disk9 scan took 0.717433 s, trims took 0.715705 s
02.196 spaceman_scan_free_blocks:4110: disk9 81258479 blocks free in 25 extents, avg 3250339.16
02.196 spaceman_scan_free_blocks:4119: disk9 81258479 blocks trimmed in 25 extents (28628 us/trim, 34 trims/s)
02.196 spaceman_scan_free_blocks:4122: disk9 trim distribution 1:0 2+:0 4+:0 16+:0 64+:0 256+:25

VM

What happens with an Apple silicon VM is a bit more complicated, and harder to observe. This time the virtualisation app should create the disk image inside the VM bundle as a sparse file to begin with, then copy into that what’s needed for the VM, so skipping the first mount stage and Trimming during the second mount.

The result is the same, though, with a 350 GB VM taking just 22 GB on disk. Inspect that disk image using my free utility Precize, and you’ll see that economy confirmed, and the Sparse File flag set.

Conclusions

For plain read-write disk images and those inside VMs to be sparse files:

• they must contain a suitable raw disk image, such as UDIF read-write;
• the host file system must be APFS, as HFS+ doesn’t support sparse files;
• for normal disk images, they must be stored on an SSD that supports Trimming;
• there must be sufficient free space in the disk image;
• the guest file system can be APFS, either plain or encrypted, or HFS+J;
• for normal disk images, they must have been mounted at least once since first being created.

Have you been able to update an existing lightweight macOS Virtual Machine on Apple silicon to Sequoia 15.4? So far, I’ve had three failures ending in kernel panics, and no successes. Maybe I’m holding it wrong?

Good news …

I’ve had no problems updating VMs from Sonoma 14.7.4 to 14.7.5, or Ventura 13.7.4 to 13.7.5. Those updates went quickly and without a glitch, but Sequoia has been another matter.

… bad news

I’ve now tried to update from Sequoia 15.x to 15.4 with three different VMs:

• freshly installed 15.2
• freshly installed 15.3.2
• lightly used 15.3.2.

None of them had iCloud enabled, but they were each fairly standard in other respects, and all running in Full Security mode, in my virtualisers Vimy and Viable.

Each has failed early, just a minute or two after the update started to install. That was terminated, and the VM briskly rebooted back into its existing version of Sequoia. Shortly after logging back in, they displayed the panic alert.

One VM was so sick at that stage it couldn’t go any further, so had to be humanely destroyed. However, I managed to capture panic logs for the other two. In both cases, the panicked task was com.apple.Mobile, with com.apple.iokit.AppleVirtIOStorage(1.0) at the top of the kernel extensions in the backtrace. The panic occurred on different cores, and its cause was given as “Kernel data abort”.

And a more innocent bug

In the course of looking at this, I happened to notice that creation dates of files in Shared Folders were all incorrect, giving a standard date of Monday, 1 January 2001 at 00:00. All other creation dates in VM folders, the SSV, and even in iCloud Drive folders, were as expected, but none of those in Shared Folders.

However, when any of those mis-dated files or apps were copied into the VM’s local storage, the expected date of creation returned like magic.

I have checked this in VMs running 15.2, 15.3.2, 15.4, 14.7.5 and 13.7.5, and it’s identical in every one. I suspect this may have been going on for some time. Am I holding this one wrong too?

Over to you

• Have you been able to update a Sequoia VM to 15.4?
• Are file creation dates wrong in your VM’s Shared Folders?

Postscript

Thank you all for your responses. I’ve now confirmed that failure to update to 15.4 appears confined to M4 models, and doesn’t afflict my MBP M3 Pro at all. However, the shared folder creation date bug seems just the same there.