Add option to configure memory balloon device, min/max size

[timsutton]

There's an option to configure a memory balloon device for the VM, which as far as I understand should make it possible for the VM to better share memory back to the host operating system if it gets low.

UTM supports the basic "whether to add this device" to the VM (here), though I'm not clear on whether there is more to do in order for it to be functional than perhaps configuring min/max memory limits for the balloon device (Apple has some more info on that here).

I'm thinking this is primarily interesting in the case where one may wish to have the system maximum of 2 VMs on a single host like a memory-constrained 16GB M1 Mac Mini that may want to be able to run (e.g.) simulator tests, potentially a few in parallel and which means some high RAM requirements that would be transient.

I'm not sure if folks have tested this particular mechanism much but it seems like if we had the option to configure it for VMs, it might be possible to crowdsource the testing / benchmarking of how well it works or if it can help to eek out more performance from concurrent VMs.

[fkorotkov]

FYI I experimented with running two 4 core / 12GB VMs on a Mac Mini with 16GB and it all worked pretty well already when I ran some memory intense stress-ng tests:

Virtualizaion.Framework is already doing some smart things with the memorySize:

This physical memory doesn’t necessarily map to the physical memory of the host computer. Instead, it’s a contiguous block of virtual memory that the host system reserves, but doesn’t allocate immediately, for the guest system. The guest operating system treats this memory as its physical memory and allocates pages from it as needed.

My understanding of the ballon device was that it allows to resize the VM while it's running by modifying targetVirtualMachineMemorySize property of a balloon device of a running VM.

[edigaryev]

FYI I experimented with running two 4 core / 12GB VMs on a Mac Mini with 16GB and it all worked pretty well already when I ran some memory intense stress-ng tests:

It seems that by default the stress-ng calls mmap()/munmap() continuously, which just results in churn, but no continuous holding of the memory.

I've tried running the same experiment with the --vm-keep option and observed a huge swap usage on the host.

[fkorotkov]

I think it will be interesing to run couple of experiments:

1. @edigaryev's experiment but sequentially and not in parallel
   a. First VM will try to use bunch of memory and then the other will use bunch of memory and see if under the hood memory from the first VM will be claimed back.
   b. Run it once again with initialized balloon devices to see if it will make any difference.
2. Run a VM with 8GB of memory and make it start swapping. See if guest swapping is translated into host swapping or Virtualization.Framework is smart enough to see there is available memory and not do swapping.
3. Finally it's just interesting if a balloon device is working at all with macOS or it's a Linux only feature like Support mounting of shared folders #13. 😅

[fkorotkov]

Let's close the issue since it doesn't seems like very useful. Balloon device doesn't help with memory management automatically. It only allows to explicitly ask a VM to return some memory while it's running.

[timsutton]

Sorry for my lateness in replying, but this all makes sense to me. Thanks for considering it further!