Resize disk0.img with macOS VM

[marek90]

Is there a way how to resize an existing disk (the primary one) of an macOS VM? It defaults to 64GB and thanks to APFS it occupies only the real size of data within (via du -sh on the disk image) even though Finder reports 64GB (via Get Info on the disk image).

This all works well with APFS "magic" 🪄 but if I want to backup the VM to an external non-APFS it will occupy all of the 64GB.

So the workaround I tried is to install macOS Monterey with the minimal disk size (24GB), but now I have only 2GB of free space left. Is there a way how I can resize the disk of an existing VM? I understand I could always create a new disk and attach it to the VM, but what about resizing the (primary) disk of the VM? Is that at all possible with macOS?

[conath]

This isn't possible in UTM. I found this article that explains how to resize a disk image on Mac - could you please try and see if it works for your case? Make sure you have a backup of the file in case it gets damaged in your experimentation!

[natevw]

I experimented with this some today — I was hoping to grow a macOS (M1) guest big enough that I could install system updates within it, without having to set up everything inside again. I was able to make some progress but at this point didn't succeed.

Based on the tips in #2636 I started with qemu-img resize. Specifically what did work was:

qemu-img resize -f raw /Users/natevw/Library/Containers/com.utmapp.UTM/Data/Documents/My\ macOS\ VM.utm/Data/disk0.img +30G

The -f raw part seems to be key — without it the raw image file itself grows but the macOS guest does not see any change.

At this point the VM still boots just fine and I do have a larger "Virtual Block Media" device ("Show All Devices" in guest Disk Utility app) so it's off to a good start!

But unfortunately that's about as far as I can get, afaict, due to the partition arrangement:

It looks the original arrangement of the disk is:

1. A small Apple_APFS_ISC "iBoot System Container" boot partition
2. The main Apple_APFS container ("Macintosh HD" and various other volumes within)
3. A separate Apple_APFS_Recovery at the [original] end of the block media

I don't think I can resize the partition for the main APFS container, without first moving or removing the recovery partition. See https://apple.stackexchange.com/questions/364288/how-to-resize-grow-apfs-partition-that-is-at-the-end-of-the-drive which provided examples for some of the commands I tried.

Since my host is also Monterrey it looks like I won't be able to boot into recovery mode (see #3526) so I haven't tried anything from there. I suppose it might be possible to mount this whole disk0.img image as a secondary disk in another VM and try fix it up there, but I haven't pursued that route yet anyway.

---

UPDATE: I won't likely pursue this any further in the near future. By temporarily setting both the old and a clean-install new VM to "bridge" networking mode, I was able to use Migration Assistant to transfer over earlier work/settings from my original guest, into a new guest with a larger disk.

(I also tried using a second disk image as a Time Machine backup volume, also aiming to use Migration Assistant but only on the new VM. That attempt also failed — it seemed like the source/original guest was seeing the extra volume as "internal" and perhaps doing something different with encryption "keybag" than it would an external? Or… something? Basically I could get a second "disk1.img" to work fine as a Time Machine volume within the first VM. But then after shutting down the first and adding the same "disk1.img" to the second VM, it would see the block drive but refuse to mount or "first aid" the APFS container within, not ever prompting for password just going straight to cryptic errors like:

com.apple.DiskManagement.disenter error 49244

and:

error: container keybag (101286206+1): unlock records entry 0 contains invalid range 218373742+1 error: volume keybag (218373742+1): failed to get keybag: Device not configured Encryption key structures are invalid.

didn't fully troubleshoot but it just didn't want to use the drive. My wild guess is that internal APFS drives get encrypted directly to the host CPU or something, whereas external can be moved between machines, but who knows…?)

[NaanProphet]

Hi @natevw thanks for your post! I found it helpful trying to resize a Mac OS 14 image myself.

By temporarily setting both the old and a clean-install new VM to "bridge" networking mode, I was able to use Migration Assistant to transfer over earlier work/settings from my original guest, into a new guest with a larger disk.

It turns out some of the software I had licensed didn't work well with the migration assistant transfer. So what I did instead was resize the main partition.

I don't think I can resize the partition for the main APFS container, without first moving or removing the recovery partition.

Exactly, so I went ahead and deleted the recovery partition. Here's exactly what I did:

1. Install qemu-img using brew install qemu-img and then this command worked perfectly:
2. Resize the IMG like you qemu-img resize -f raw <path-to-my>.img +30G
3. Right click the VM and select Run Recovery. Boot into MacOS recovery mode.
4. Disable System Integrity Protection in Terminal with crsutil disable
5. Reboot normally
6. Open Terminal and delete the recovery partition via diskutil eraseVolume APFS Blank [RECOVERY IDENTIFIER] frees up about 5.4 GB
7. Use the Disk Utility GUI to resize the main data partition!

What's cool is I can still boot into Recovery mode using UTM, because the initial 500 MB partition is still there. I figure this is a VM, so do I really need the 5.4 GB Apple_APFS_Recovery partition? Probably not. Hope this helps!

Special thanks to:

• https://www.makeuseof.com/tag/delete-repair-mac-recovery-partition/
• https://eclecticlight.co/2021/12/16/boot-disk-layout-in-macos-monterey/

[barak-kalai]

I followed the steps above and I can extend the the UTM image using gemu-img I then disable in recovery mode I erased the recovery partition In disk utility it dosen'tl let me extend the partition trying to "convert" the free space to a partition fails "remove free"((null)) and grow container disk4 "xxx" (disk0s2) the new size must be different than the existing size(-69743) trying to add a partition it only allows me to add 2g out of 85.9g