Open marek90 opened 2 years ago
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!
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:
Apple_APFS_ISC
"iBoot System Container" boot partitionApple_APFS
container ("Macintosh HD" and various other volumes within)Apple_APFS_Recovery
at the [original] end of the block mediaI 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…?)
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:
qemu-img
using brew install qemu-img
and then this command worked perfectly:qemu-img resize -f raw <path-to-my>.img +30G
Run Recovery
. Boot into MacOS recovery mode.crsutil disable
diskutil eraseVolume APFS Blank [RECOVERY IDENTIFIER]
frees up about 5.4 GBWhat'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:
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
@barak-kalai , try repairing the internal disk before resizing the synthesized. Something like this:
diskutil repairdisk disk0
diskutil apfs resizeContainer disk4
Why would you need any external tools for resizing if on macOS the image can be resized natively?
$ hdiutil resize -size 40g -imageonly -verbose 233788C6-C25E-4CE1-BE15-716CD2C80AA1.img
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface 1, score -1000, CBundleBackingStore
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface 3, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CVectoredBackingStore
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CEncryptedEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CSegmentedUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 1, score -1000, CSegmentedUDIFRawEncoding
DIDiskImageInstantiatorProbe: interface 0, score -1000, CUDIFDiskImage
DIDiskImageInstantiatorProbe: interface 1, score 0, CSparseBundleDiskImage
DIDiskImageInstantiatorProbe: interface 2, score 0, CSparseDiskImage
DIDiskImageInstantiatorProbe: interface 3, score 100, CRawDiskImage
DIDiskImageInstantiatorProbe: interface 5, score -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface 6, score -100, CWrappedDiskImage
DIDiskImageNewWithBackingStore: CRawDiskImage
DIDiskImageNewWithBackingStore: instantiator returned 0
hdiutil: resize: completed successfully
So, basically, I did the following:
hdiutil resize -size 40g -imageonly -verbose <name_of_the_image_file.img>
crsutil disable
diskutil list
to get the list of the containers (the first block in the output) and located the Apple_APFS_Recovery
containerdiskutil apfs deleteContainer <id_of_the_recovery_container>
(note that there are two recoveries - one is the 5.4GB container and another is the recovery volume -- you need to ensure that you are removing the container and not the volume)diskutil apfs resizeContainer <id_of_the_synthetic_container> 0
(In my case it was disk3
, it is the only synthesised disk you should have at this point)csrutil enable
in the Terminal to re-enable the protection.Please note that the steps below help if you want to recover the 5.4 GB from the Apple_APFS_Recovery partition to make your images as optimized as possible, but further OS update will probably fail. If you want to preserve your ability to upgrade, see the next comment.
Thanks @galaxy4public. I think everything can be done directly from recovery (at least it worked well for me).
In that case the simplified steps are:
hdiutil resize -size 40g -imageonly -verbose <name_of_the_image_file.img>
diskutil list
to get the list of the containers (the first block in the output) and located the Apple_APFS_Recovery
containerdiskutil apfs deleteContainer <id_of_the_Apple_APFS_Recovery_container>
(note that there are two recoveries - one is the 5.4GB container and another is the recovery volume -- you need to ensure that you are removing the container and not the volume)diskutil apfs resizeContainer <id_of_the_Apple_APFS_container> 0
(it should be the container that was right above the Apple_APFS_Recovery
container you deleted at the previous step)If you want to be able to increase the size of your disk image while retaining the ability to upgrade your OS, the Apple_APFS_Recovery partition must be relocated to the end of the disk before expanding the main Apple_APFS container.
So far the only ready-made solution I have found is the Tart packer plugin from the Tart project by cirruslabs which allows for automated VM creation and has the option to automatically resize disk images (see the recovery_partition = "relocate"
option).
More information on the projects can be found below: https://github.com/cirruslabs/tart https://github.com/cirruslabs/packer-plugin-tart/tree/main
Since I wanted to continue using UTM and simply needed a standalone tool to relocate the partition, I created a small tool based on their code. Understand that it come with no guarantee, but the code is available here: https://gist.github.com/cdavidc/3509ceefba518f20d1c123b6435407d6
To build it, install go (with brew for instance) and execute the few commands listed in the comments at the beginning of the file.
Considering that, the full instructions are:
hdiutil resize -size <new_size_in_GB>g -imageonly -verbose <full_path_and_name_of_the_image_file>
./RelocatePartition <full_path_and_name_of_the_image_file>
diskutil list
to get the list of the containers (the first block in the output) and located the Apple_APFS
containerdiskutil apfs resizeContainer <id_of_the_Apple_APFS_container> 0
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?