Date: Tue, 13 Feb 2018 15:48:57 -0800 From: Peter Grehan <grehan@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, tech-lists <tech-lists@zyxst.net> Cc: freebsd-virtualization@freebsd.org Subject: Re: bhyve and contention Message-ID: <c3b167ae-30a2-f6f2-072c-db1c575d859a@freebsd.org> In-Reply-To: <201802131806.w1DI6xp7049909@pdx.rh.CN85.dnsmgr.net> References: <201802131806.w1DI6xp7049909@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 2. >> In the following context, the server is the same but this time all five >> guests have -c 4 per guest, so bhyve is asking 12 more cores than that >> existing in hardware. Does the guest fail to load, do either guest or >> server crash? > > The is core over commit, very common in the virtualization world, > bhyve does its best effort to give the guests cores as needed. To add to what Rod said - bhyve uses a thread for each vCPU. It's up to the FreeBSD scheduler to determine where/when these threads run. It is possible for a guest to fail, for example if a spinlock times out due to vCPUs not being able to run to release a lock. This is a general problem with virtualization and can occur even on VMWare ESXi with heavy oversubscription. That being said, there is certainly scope to provide more information to the FreeBSD scheduler so it can make better decisions when running VM guests. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c3b167ae-30a2-f6f2-072c-db1c575d859a>