# bhyve - how to set real-time priority for running VMs?



## Selin (Aug 17, 2020)

Hi
I'm trying to use the bhyve as a platform for virtual machines and have hit the following issue:
- if some heavy process of the host grabs CPU resources (e.g. rebuilding some port) - virtual machines start slowing down. I mean not only slow response of guest systems but real slowdown of them - even clock on guests running slower at these moments.
I tried to set a real-time priority for bhyve processes with rtprio tool. It seems to be a solution.
But every time I reboot a guest system - it is started as a new bhyve process with default priority.

Is there any solution or workaround - how to set a realtime priority for bhyve guest systems by default?


----------



## Selin (Aug 19, 2020)

Maybe my issue can be solved by pinning virtual CPU to physical CPU using bhyve option:
*-p* _vcpu:hostcpu_
?
Could someone explain this option in detail, please?


----------



## Bobi B. (Aug 19, 2020)

Not exactly what you're asking for, but why not use nice(1) when running CPU-bound tasks on the host?

PS: I believe it is somewhat a good practice to use VM hosts as such and to avoid running much else on them.


----------



## Phishfry (Aug 19, 2020)

Selin said:


> Could someone explain this option in detail, please?





			[PATCH] Flexible vcpu pinning configuration
		



			vmrun.sh - how to pin vcpu to realcpu?


----------



## Selin (Aug 22, 2020)

Bobi B. said:


> ... why not use nice(1) when running CPU-bound tasks on the host?


Thanks!
That might be an option. Will test this.



Bobi B. said:


> PS: I believe it is somewhat a good practice to use VM hosts as such and to avoid running much else on them.


Yes. You are absolutely right.
But sometimes updating installed ports, for example, leads to heavy load on the host.
On the other hand, I prefer to not increase VMs downtime during updating the host. So I'm looking for a solution to how I can do that in a proper way...


----------



## Selin (Aug 22, 2020)

Phishfry said:


> [PATCH] Flexible vcpu pinning configuration
> 
> 
> 
> ...


Thanks. But these are rather about how to use that option, but not about how it works... Or I didn't catch that from these links.

In general - I'm trying to understand - does CPU pinning mean that particular physical CPU will belong to a VM exclusively?
Or it just means that pinned virtual CPU will always be running only on particular physical CPU, but other host processes will be able to use that CPU as well?


----------



## Bobi B. (Aug 22, 2020)

I believe it is a way to restrict the CPUs kernel schedules a process or group to run on. That would not stop kernel to run other processes on same CPU; that will stop kernel from running this particular process/group on CPUs other than pinned ones. If you wish to "give" a CPU to a VM exclusively you'll have to prohibit other processes from running on this CPU.

Try pinning a port build to specific CPUs that are "VM-free" and to limit number of make(1) parallel jobs (`make -j 2 ...`).


----------



## Phishfry (Aug 22, 2020)

More reading for you:


			https://bhyvecon.org/bhyveconOttawa2019-Rodney.pdf
		


This whole thread contains good info:


			Overcommitting CPUs with BHyve?
		


Are you using a single socket motherboard or multiple CPU motherboard?
NUMA domain awareness comes into play if multiple CPU's are used.


----------



## Selin (Aug 26, 2020)

Thanks for the recommendation and more info about CPU usage with bhyve.

I'm using a single socket motherboard with 8 cores CPU (Intel Xeon W-2145)


----------



## rootbert (Aug 26, 2020)

rtprio(1) comes to mind


----------



## Selin (Aug 26, 2020)

rootbert said:


> rtprio(1) comes to mind


Might be...
But every time I restart VM (i mean restart from VM side, not from the host side) - the appropriate bhyve process is restarted as well... and gets the default priority.
Maybe will think about some workaround with cron-script - to set real-time priority for each bhyve process every 1 minute, for example... But I don't like such an approach.
Reducing priorities of ad-hoc heavy load host tasks seems to be more correct for my case.


----------

