WMWare has paused this virtual machine because the disk on which the virtual machine is stored has plenty of space available

[lharding]

...or at least, that's what's *happening*. The error message claims that the host volume in question is almost full and asks for a specific amount of space to be freed, but it's asking for ~/50MB on a disk that has 12GB of free space. What's going on here? Is it actually asking for *contiguous* free space (in which case it should say so)?

[dariusd]

VMware Fusion does not require contiguous space... any free space will do.

Do you have multiple disks/SSDs in your Mac?  How much free space do they each have at the time the error message appears?  How many VMs are you attempting to run at once?  Which version of Fusion are you using?

Cheers,

--

Darius

[lharding]

I have only the one internal SSD - this is a 2015 MacBook Pro Retina. The amount of free space doesn't really change, it's hovering around 12GB. The amount of space VMWare requests is completely random, anywhere between a few MB and tens of GB. I'm just running the one VM. I'm running VMWare 8.5.6.

[lharding]

Oh, and, the total size of the VM bundle on the host machine varies but typically exceeds the configured size of the virtual disk by 5-20 GB. That seems significant.

[RDPetruska]

Have you taken any snapshots (or have auto-protect enabled)?

[wila]

Also note that if you run your VM with lots of RAM (Gigabytes) that as soon as you start the VM it will need those same Gigabytes as backing for the RAM you assigned to the VM.

If you are certain that you don't need that backing then you can turn that off. I have no idea if the mechanism that counts how much  free space you need on your disk takes that into account though.

--
Wil

[Mikero]

The size of the VM bundle will fluctuate due to VRAM saving it's state to disk (i.e. 4GB of RAM assigned to the VM means a potential 4GB '.vmem' file in the bundle when suspended).

Also, multiple snapshots (including those taken by AutoProtect) will consume space. Technically each snapshot can grow to the size of the space allocated for the virtual disk.

[Mikero]

Can you collect a log bundle right after you get this error message, and post it here so we can take a look?

[lharding]

Thank you! It's probably this - I didn't realize VMWare was trying to maintain a swapfile as well as the vmdk. 12GB happens to be both the amount of space I have free on my drive, and the amount of RAM I have allocated to this VM. Where *do* I turn this off, and what are the consequences?

And in a related question, is there some *official* reference to all the things that can go in a .vmx?

[TestMcTest]

Had the same issue and while I understand the idea is to free up space on the host's hard drive, if you want to get into the VM to free up space on there, it's impossible.  I found that you can add the following to your .vmx file to prevent it from prompting you about this:

mainMem.freeSpaceCheck = "FALSE"

Hope that helps.

[Mikero]

I found that you can add the following to your .vmx file to prevent it from prompting you

THIS IS NOT SOMETHING PEOPLE WHO VALUE THIER MACS SHOULD BE DOING!

Basically, we NEED to check if there is space available, and you WANT us to do that,  otherwise we'll just keep writing until the Mac literally runs out of available space for itself to use. A VM doesn't have awareness of the host disk space, so it will just keep growing (which is by design).

A Mac without free space can't sleep properly, manage it's swap files, and more bad things.

Deleting files inside Windows will also not free up space the Host until you go onto Fusion and do a 'disk cleanup' (or when cleanup auto-runs which is new in F10).

So my friends, do NOT change the 'freespacecheck' flag to 'false' to suppress the warning. It could potentially do "really bad things" to your Mac.

tl;dr: This flag is dangerous, clean up files on the Host so that there's enough free space.

[ColoradoMarmot]

Just two additional notes - OSX itself wants about 10% free on the disk to function properly.

In High Sierra, Apple changed how time machine works, and it's playing havoc with mostly full disks.  Instead of backing directly up to an external time machine drive, it first creates local snapshots, then backs those up.  The result is that time machine can consume a significant chunk of disk space when it runs.  It's always a good idea to exclude virtual machines from time machine (since it's unreliable), but especially important in HS, and critical if the disk is tight on space.

tmutil listlocalsnapshops [mount point - usually /] will show you the snapshots on the local drive.  Even with my TM backup plugged in, I have 5 from today.

This is causing enough problems, particularly on extended travel, that I'm playing around with using Carbon Copy Cloner to replace time machine completely (without using it's snapshot feature either).

[danallenhtn]

In the end, appears likely cause was host directory permissions change cutting off access to the vm.  The permissions change was applied while the VM was running, leading to the error message.  The error message was confusing, not really pointing to the problem.

The steps below are what I went through trying to find where the disk shortage was.  No disk shortage found.  After shutting down the VM, attempts to restart generated completely different error, it just internal error and would not start.  Resetting the host directory permission resolved that problem  and the VM is back in normal operation.

My notes as it happened:

I don't see how it makes any sense, since there are plenty of all resources available, except for the sys administrator's knowledge, which is almost zero.  I am the system administrator.

VM=> Debian 7

Host-> macOS High Sierra

Here is the error message coming up.  I got by it by clicking Continue a few times, after checking resource status to the extent I know how and explained below.

I clicked Continue a couple times to get what appeared to be the VM running normally.  After a few minutes, same error came up. 

Here is what I mean by saying there are plenty of resources available:

Logged into the VM as root via SSH.  Ran df to check disk space from inside the guest.   Looks like plenty of space to me

Then ran df -i to check inode availability, since this system can run out of inodes before running out of disk space

Next checking disk availability on host.  Finding where the VM is stored in the file system

Looks like 1.85 TB available

TAking a look at RAM, since it came up in this thread as a possible culprit

I have never been able to find in the macOS activity Monitor where the memory is allocated in the process list.  However, I have noticed that shutting the VM down will cause 16GB, the amount of RAM allocated to the VM, to be added to the memory used figure in activity monitor

This says only 8.1GB was released when the VM was shutdown.  That is a wrongo dealo, because the VM

is allocated 16GB and its operations use it all.

Restarting the VM, should be no problemo.

So, the VM is restarted and the issue is I expect the problem to recur since I did not change anything.

Well, that was a lie  i changed the permissions on the Volume holding the VM from 775 (rwxrwxr x) to 770 (rwxrwx   ) just before this problem occurred.  When starting the VM after the RAM checking described above, I got an error from the VM saying it could not start due to internal error.  I put the permissions back and we'll see what happens.