[Bug 222916] [bhyve] Debian guest kernel panics with message "CPU#0 stuck for Xs!"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222916

Peter Grehan <grehan at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grehan at FreeBSD.org

--- Comment #2 from Peter Grehan <grehan at FreeBSD.org> ---
The "CPU stuck" messages generally occurr when a system is oversubscribed i.e.
the guest has been given more virtual resources than are physically available.

In this case, the guest has been assigned the same number of vCPUs as the host
(assuming Intel-ARK is correct here:
https://ark.intel.com/products/97478/Intel-Xeon-Processor-E3-1275-v6-8M-Cache-3_80-GHz)
so if there is a time when both the host and guest require all CPUs, there is
only 4 available to service the needs of 8 assumed available (4 host, 4 guest).

In addition, the guest has been assigned 32G of RAM, and ZFS is being used on
the host. The issue there is that the default ZFS setup on FreeBSD will allow
use of all RAM minus 1GB for ZFS ARC. This competes with use by bhyve
(swap-backed RAM), and can result in excessive swapping by the bhyve process.
This can also result in "CPU stuck" messages as vCPUs are halted while awaiting
guest physical memory to be paged in.

A recommendation would be to
   a) restrict ZFS ARC usage to less than that required by the host and bhyve
guests. In this case, perhaps 16-24G (if the mobo has 64G) ? This can be done
using the vfs.zfs.arc_max parameter in /boot/loader.conf
   b) Only use 2 vCPUs for the guest, or, enable hyperthreading.

-- 
You are receiving this mail because:
You are the assignee for the bug.