Solved bhyve resource assignment

Hi,
I would like to know how bhyve does the resource assignment. If i assign, let's say, 2 of my 4 CPU-cores to a bhyve-guest and 4GiByte of my 8GiByte, are those resources then exclusively dedicated to the guest-vm, or is the host further allowed to schedule threads on the assigned CPUs, alternating with the guest, and putting stuff into those 4GiByte memory if the guest does not fill it up completely?

Thanks
 
No, nothing is exclusive. The guest sure will try to use up all the memory you give it, because thats what OS kernels do, but nothing about bhyve is designed this way.
 
CPU cores aren't dedicated, it's perfectly acceptable to "oversubscribe" them. For example running 3 2-core VMs on a host that has 4 cores will work just fine. The idea being that an OS rarely uses 100% CPU load on every core continuously so there's plenty of "spare" CPU cycles to give each VM a piece of the pie. You can "pin" a guest's vCPU to a specific host CPU but it's still going to be scheduled and the host (or other VMs) will use it regardless.

For memory things are bit a more complex but as far as I know bhyve(8) will try to use memory ballooning by default. You can "wire" the guest's memory though, so if you assign 4GB to a VM that 4GB of memory will be 'dedicated' to that VM and the whole block will be assigned.
 
For memory things are bit a more complex but as far as I know bhyve(8) will try to use memory ballooning by default. You can "wire" the guest's memory though, so if you assign 4GB to a VM that 4GB of memory will be 'dedicated' to that VM and the whole block will be assigned.

Just wondering where you found this information. On the manual page, as well as in the bhyve source code in FreeBSD-current, there is nothing related to virtio-balloon. In addition, it would be very strange in terms of performance and security, if this option is enabled by default, and there is no way to disable it
 
It's more or less inferred from an option in the bhyve(8) man page and the fact that virtio_balloon(4) exists.

Code:
     -S          Wire guest memory.

But to be honest I really don't know for sure. And I don't think memory ballooning is going to help much either as FreeBSD will try to use all available memory any way. So there's typically very little "free" memory on a FreeBSD machine (virtual or otherwise) if it's been running for a while.
 
Unfortunately, the -S option has nothing to do with virtio_balloon(4). virtio_ballon module exist in FreeBSD, However, it helps, when FreeBSD works as guest in a hypervisor with balloon support (XEN, ESX, KVM). However, the bhyve at the moment is not able to be as virtio-balloon backend.
 
To see that the bhyve guest never returns memory (regardless of the virtio-balloon inside guest) is very easy, for example run in guest:

tail -f /dev/zero

or malloc + free (in any accessible programming language). And watch from bhyve side on top(1) or

rctl -hu process:<pid>
 
Back
Top