If I create a VM and I give it say 2 CPU cores, and 16 Gigz of RAM and assign GPU, does this mean that these resources will be reserved specifically for this VM? Or can they still be used by other services and if there is not enough e.g. RAM or CPU capacity at the moment its a bummer for the VM?
I am trying to figure out, if I want to run Home Assistant in the VM. If the resources are shared, i would be ok with it. But if I essentially block the resources from being used by other services, like containers, I would rather not waste them.
Thank you
CPU is shared with host and the VM - the VM can try to schedule up to as many threads as you give it, so it could demand/schedule two threads at a time, and your host would have whatever remains.
For RAM, you can enable and adjust memory ballooning by setting a “Minimum memory” value in the VM configuration pane:
That will reserve the lower value, and use ballooning to shrink when needed. You’ll have to install the virtio drivers in Windows to enable this, but modern non-Windows should have the balloon driver included by default.
Okay, that is good news then.
Thanks a lotHoneyBadger! I love how concise yet informative your reply is 🩵
1 Like
Sorry to be dense. Focusing just on CPU. If I have four core/four thread processor, in my simpleminded way, I think if a create a VM with two cores, the VM hogs the two cores and the host has to make do with the other two. But is it the case that if the VM is mostly idle, does the host have access to the four threads, except where one or two are being used by the VM? And if the VM asks for a second thread that happens to be used by the host, it has to wait to get it?
I happen to have a 6/12 Xeon, with a mostly idle VM, and I thought if I assigned, say, 8 cores to the VM the host would be stuck with 2 cores/4 threads. But is it more flexible?
CPU is much more on-demand and has a lot more flexibility - but it’s still complicated. 
In your 4c/4t example, the host will always have “access” to all four threads - but if it has four processes that it wants to run at full blast, and the VM is also running its two virtual cores/threads at full blast, you’ll have 6 threads demanding 100% CPU time - the host CPU scheduler will kick in and start arbitrating which processes get to run on which core when and for how long.
Basically, you’re demanding 150% from a 100% system - something will have to give, and either your host or your VM will have to slow down.
In your 6c/12t Xeon example, if you assign 8 threads to a VM, it could have the potential to hog 8 threads out of your 12. We also get to add the complexities of “cores” vs “threads” in the scheduler. If your guest VM is SMT-aware (hyperthreading) and is set up in that manner (4c/8t) then kvm would likely try its best to align with that configuration on the physical CPU cores, leaving you with 2c/4t. But if your guest isn’t SMT-aware, it might hog all six physical cores first, leaving your host with just the second logical cores and a bit less performance - or vice-versa, giving your host preferential access to the physical cores and scheduling your VM on the logicals.
Look up the concept of CPU “overcommit” or “oversubscription” for more information on the subject as well. Generally speaking, overcommitting CPU is okay, and results in degraded performance - overcommitting RAM is usually not and can jeopardize system stability. The TrueNAS middleware tries to prevent you from doing this, but through abuse of the minimum RAM and balloon driver could probably be coerced into doing something like it - but in that scenario, I’d expect the kernel to take out a VM process first with the oom_killer rather than let a host process go down.