How to resize a Virtual Drive with HFS+

[socratis]

The FAQ/tutorial on How to resize a Virtual Drive unfortunately does not work with MacOS X guests, mainly because of step #2 which talks about using GParted to resize the new increased capacity partition. That's because GParted can only move or shrink an HFS+ partition, not enlarge it.

The most common tool for this job is OS X's own Disk Utility, but it fails as well with a "MediaKit reports partition (map) too small." The reasons and the technique to get around it are explained in an article titled (appropriately) "Increase disk and partition size in OS X", which is the basis of this how-to as well.

So, standard warnings apply:

• Does not work on fixed drives.
• Does not work with snapshots.
• This post is for a single partition, GUID hard drive.
• Follow Step 1 of How to resize a Virtual Drive.

Example of Step 1

$ VBoxManage showhdinfo Mac.vdi
Capacity:       20480 MBytes
$ VBoxManage modifyhd Mac.vdi --resize 40960
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ VBoxManage showhdinfo Mac.vdi
Capacity:       40960 MBytes

Now for Step 2. Before you begin, you can take a snapshot at this point, in case you mess up step 2, so that you can always revert back to a safe point.

Step 2

• Boot with any Mac OS X bootable DVD. Any version will do. That is you can resize a 10.9 guest if you boot with e.g. a 10.6 DVD.
• After you choose the installation language, open Utilities, Terminal. Type 'df' and watch the output. My hard disk is named 'VB-OSX'. You can see it is '/dev/disk0s2' and is mounted on '/Volumes/VB-OSX'.

  -bash-3.2# df
  Filesystem   512-blocks     Used Available Capacity  Mounted on
  /dev/disk2s3    2976968  2207968    739232    75%    /
  ...
  /dev/disk0s2   40263824 14454680  25809144    36%    /Volumes/VB-OSX
  ...

• Unmount the disk and display GPT info for it. Note that the 's2' part is missing in some of the commands. This is because some of the commands (gpt ...) operate on the disk, while others (umount ...) operate on the partition (or 'slice', hence the 's'):

  -bash-3.2# umount /dev/disk0s2
  -bash-3.2# gpt show /dev/disk0
       start      size  index  contents
           0         1         PMBR
           1         1         Pri GPT header
           2        32         Pri GPT table
          34         6
          40    409600      1  GPT part C12A7329-F81F-11D2-BA4B-00A0C93EC93B
      409640  40263824      2  GPT part 48465300-0000-11AA-AA11-00306543ECAC
    40673464   1269536      3  GPT part 426F6F74-0000-11AA-AA11-00306543ECAC
    41943000  41943080

• Note that I've highlighted three rows; the three GPT partitions. This is from a 10.7 system. In 10.6 and earlier you'd have only the first two GPT partitions. Each partitions has three parameters; 'start', 'size' and 'UUID' (the 32-digit hex number). We're going to need those later when we rebuild the GPT. First, we need to destroy it!

  -bash-3.2# umount /dev/disk0s2
  -bash-3.2# gpt destroy /dev/disk0

• Now we're going to create a GPT and add partitions to it. The partitions have to be added in the correct/existing order, size and type. It would be easier if at this point you open a new Terminal window (Cmd-N) so that in one you have the output of the 'gpt show' command and you can copy and paste between that and the new one that you're adding the partitions:

  -bash-3.2# gpt create -f /dev/disk0
  -bash-3.2# gpt add -b 40 -s 409600 -t C12A7329-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0
  /dev/disk0s1 added
  -bash-3.2# gpt add -b 409640 -s 40263824 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
  /dev/disk0s2 added
  -bash-3.2# umount /dev/disk0s2    <-- The HFS+ partition is mounted automatically
  -bash-3.2# gpt add -b 40673464 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
  /dev/disk0s3 added

• Quit Terminal, open Disk Utility, select your HD, go to the Partition tab and drag the lower-right corner to expand the HDto its new capacity. Now it works without any problems...

Done. If you took a snapshot before you started Step 2, you can now delete it safely.

PS. The 32-hex-digit UUIDs of the different partitions can be found on the GUID Partition Table article on Wikipedia. For a quick reference of the ones found in this post:

C12A7328-F81F-11D2-BA4B-00A0C93EC93B   EFI System partition
48465300-0000-11AA-AA11-00306543ECAC   HFS+ partition
426F6F74-0000-11AA-AA11-00306543ECAC   Apple Boot partition

[loukingjr]

Are you sure about using a snapshot as a fallback will work? In other words, even if you successfully resize the disk and it's partitions, if you restore the snaphot it will "unresize" the partition back to it's original configuration? I would think making a backup of the .vdi might be safer.

[mpack]

Moved to "OS X Guests" forum.

p.s. The FAQ says in step 2 that you have to use a partition manager. GParted is only offered as a popular example. Obviously there may be many filesystems which GParted doesn't support, but that doesn't mean that the FAQ is incorrect.

And yes, if you resize a snapshot and then revert to the base VDI, then the disk size should be whatever the base is. Or if you delete the snapshot then the new state should be preserved and the new disk size will remain. However, all such snapshot manipulations are risky: it's major surgery on your only copy of the data, unless you have proper backups.

[socratis]

Yes, I tried it multiple times, with several VMs. I wouldn't dare give advice like this (borderline dangerous) without testing it extensively. You see, the differences in the snapshot are miniscule (just the GPT changes), so the chances of something going wrong are minimal. And yes, if you restore the snapshot, you in effect un-resize your partition.

Backup is a great advice as well, albeit a little slower (depends on the contents of your VM) and with more space requirements.

[socratis]

that doesn't mean that the FAQ is incorrect

I never said that the FAQ was incorrect, I simply said that the solution(s) offered do not work for HFS+ partitions. Since I couldn't find any other partition managers that work with HFS+ partitions, I described a potential solution that works.

[mpack]

and with more space requirements.

Depends on your definitions. Snapshots, however small, always take up space on the VM drive. A backup can go to secondary storage.

[socratis]

Snapshots, however small, always take up space on the VM drive.

FWIW, for this specific operation, we're talking about 6.5 MB of extra space for the snapshot.

[socratis]

See next post.
OK, I've found an apparent problem in the partitioning scheme, specifically with the EFI partition. DiskUtil complains about "partition slices" when you're trying to verify/repair the whole disk (not the partition). Investigating for the correct solution. Although it doesn't seem to effect existing data or the disk's capacity, it's definitely something not going 100% as planned. I've added a big red warning at the beginning until this is resolved.

[socratis]

OK, problem fixed, original post updated. In the original post I only recreated/allocated the data partition, not all of the partitions (EFI, AppleBoot). The instructions now properly reflect that the partition recreation should be in the correct order, size and type. It was NOT affecting any data or operations. Not at the slightest, since the EFI and AppleBoot (aka Recovery) partitions are not used in the context of a VM. But, since the disk verification was throwing an error, I thought that we should be doing things correctly. Sorry for the mix-up...

[socratis]

And yes, if you resize a snapshot and then revert to the base VDI, then the disk size should be whatever the base is. Or if you delete the snapshot then the new state should be preserved and the new disk size will remain.

I just noticed this. Yes, that could work in theory, but it wasn't in practice. You'll see that I talk about taking a snapshot after the first step, i.e. you resize the actual snapshot-less VM. I found the hard way that if you take a snapshot, increase the VDI size and try Step 2, VirtualBox simply ... disappears when you try to 'gpt <anything>'.

That's why the backup is an excellent idea as well, before you start any of this monkey business...

[mpack]

I just noticed this. Yes, that could work in theory, but it wasn't in practice.

I guess it matters what direction it does the merge. There should be no problem if you resize the entire snapshot chain - just the disk sizes, there's no need to run the partitioning steps except on the last file - then delete the snapshots you don't want.

[smeuletz]

Made the steps in this tutorial, and I got to the place in Disk Utility where you can enlarge the partition. It worked, BUT after rebooting, I got error "No bootable medium found". Did this two times. One time I had a snapshot and I reverted when this occurred. Second time I didn't have a snapshot and I lost the machine and had to reinstall again (allowed 100 gb disk space this time).

First time Virtual box 4.3, second time Virtual Box 5.0.4.
Mac OS guest: Yosemite 10.10.1
Linux host: Ubuntu 14.04

So, my recommendation is: make a backup, this tutorial will work but there are chances to leave you with a machine that does no longer boot.

[loukingjr]

First time Virtual box 4.3, second time Virtual Box 5.0.4.
Mac OS guest: Yosemite 10.10.1
Linux host: Ubuntu 14.04

Important notice regarding Mac OS X as Guest