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. (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. 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. UPDATE: I won't likely pursue this any further in the near future.
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. 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. See which provided examples for some of the commands I tried. I don't think I can resize the partition for the main APFS container, without first moving or removing the recovery partition.
A small Apple_APFS_ISC "iBoot System Container" boot partition.It looks the original arrangement of the disk is: 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.Īt 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!īut unfortunately that's about as far as I can get, afaict, due to the partition arrangement:
Qemu-img resize -f raw /Users/natevw/Library/Containers//Data/Documents/My\ macOS\ VM.utm/Data/disk0.img +30G
0 kommentar(er)
