From nobody Fri Dec 3 05:51:54 2021 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7155218ABF80 for ; Fri, 3 Dec 2021 05:51:57 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J525T2Dv0z3wBm for ; Fri, 3 Dec 2021 05:51:57 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: by mail-pg1-x531.google.com with SMTP id q16so1990263pgq.10 for ; Thu, 02 Dec 2021 21:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callfortesting-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=r8+HB0Y50dAMnSCLaoM/2zzJHwxH4Ii56Zqn1QXhyTo=; b=22kH//hcWw8Hlp3YKaAyLUHomLZGfp8Oqn9eYG6gFB4YMP0RL7eId8wXrMz0GxixJS jhsDHzsPdQw+lkdfav0INiFF4CEVeTSp6FKwrqFJVYCNBLSMPOo0MttRU0ri/lvsTd5l XgVFHl7o1HBtMD5dzIJqMbtIMlU6TO1hpzZMiuRf7vgdh7plMKVchN+HVz9Q2OA9z0ZR 9Ci3nnl5x7BUc2VsGoLL+8JSfWAmnp4vbLECvBQlTbUpywHw8d/zHhZAiv+uopVQ3iTZ pILwljCMMv8KFONiuyDG09umNpp3Hf8X72l6O0Itqk5GwOWSGcC+Jpt6L6a+CISFA4JX sXPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=r8+HB0Y50dAMnSCLaoM/2zzJHwxH4Ii56Zqn1QXhyTo=; b=Q+2Uzid2jIno24MW42v6AZujLNuYlP4754JnXE1j4IJYEDkIaM8OG1acaanMeysnT8 ENfphbFmGnQPFK1F/PQdhPHyjiQzakqmmtHt9dZRbIjBsj6QaMTUtPXdWL0M6JFsmHwx sjqUXpuFIHWeKwvoht6pERlNNhuhm0wgpu/fsheaBTchGIwdGokx8sVCXNEYK2iaXmU0 9RP/0r446yH+JcSSXxkFLTVvMuaBJxooQGLoudh0BiGDbyN1mPemJ2S7V0+u/Z1bfZB8 tFtsZNKdPOdBWVaA/wx+KsXZCaR13EI+xUUSFQQDbDq0rBoDJGuV2TpgAmTDkrsGsEtU jLxQ== X-Gm-Message-State: AOAM533S5QbhRE4XkoZqomEGiJtOXD1jtHc+1gNaQxLl1YB9GtXkmh3N sitO76LmFCi+KjYXMicG/twVug== X-Google-Smtp-Source: ABdhPJxUdSuwnHO5dluikyKw4ebrR1MYP4rlHvTkYQsTQxzPwWMSNijCpAM6BqoutHUl/euo9LcOKg== X-Received: by 2002:a62:cdc1:0:b0:4aa:6a80:8bbf with SMTP id o184-20020a62cdc1000000b004aa6a808bbfmr6001842pfg.4.1638510716152; Thu, 02 Dec 2021 21:51:56 -0800 (PST) Received: from [10.0.0.210] (c-73-157-223-19.hsd1.or.comcast.net. [73.157.223.19]) by smtp.gmail.com with ESMTPSA id ip6sm4290893pjb.42.2021.12.02.21.51.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 21:51:55 -0800 (PST) Message-ID: Date: Thu, 2 Dec 2021 21:51:54 -0800 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: bhyve vCPU limit Content-Language: en-US To: bsdlists@jld3.net, "Rodney W. Grimes" Cc: Oleg Ginzburg , Miroslav Lachman <000.fbsd@quip.cz>, rgrimes@FreeBSD.org, jbo@insane.engineer, freebsd-virtualization@FreeBSD.org References: <202112021603.1B2G3B9U049478@gndrsh.dnsmgr.net> From: Michael Dexter In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J525T2Dv0z3wBm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/2/21 8:59 AM, John Doherty via freebsd-virtualization wrote: > On my system, I'm sure that all I did was edit vmm.h, make buildworld, > and make installworld. There have been concerns voiced that a higher vCPU count would increase the resources consumed by all VMs, even if they only have one vCPU. If there is a correct solution to be implemented, please voice it and I assure you there are many people who are ready to compensate the work. This topic came up on this morning's bhyve Production Users call. The low vCPU limit is keeping some applications on "the previous hypervisor" with organizations that have otherwise moved entirely to bhyve. The 16 vCPU limitation is directly impacting production users and I welcome them to chime in with their use cases. I personally desire a higher count for contained buildworlds and the use case from today was a financial application that must be comforted with a high quantity of vCPUs. The discussion broadened into strategies for guaranteeing that VMs are pinned to physical cores, and the desire for fine-grained distribution of physical and virtual cores to the host and VMs, most of which can already be controlled with a mix of cpuset and vCPU pinning. Please commit to increasing the vCPU value sooner rather than later. Regarding the Production Users call, it is open to everyone and the minutes are public. Information about joining is linked from bhyve.org and the title of the IRC channel. Warmest regards, Michael