From nobody Tue Apr 7 10:32:14 2026 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 4fqjFB0Fd2z6Xyrp for ; Tue, 07 Apr 2026 10:32:30 +0000 (UTC) (envelope-from SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4fqjF70Cgnz4FtM; Tue, 07 Apr 2026 10:32:26 +0000 (UTC) (envelope-from SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=cmvQHYv4; dkim=pass header.d=quip.cz header.s=private header.b=WfqtpoPA; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B0445D788C; Tue, 7 Apr 2026 12:32:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1775557937; bh=Gi0qaJ5CMZSDCIKOEPxhaS7I4Lu8u1dc2ibG6bc2bLQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=cmvQHYv4+coW0U9CTgpTvk0MKkEpnx3KUQYvCie2tmR5jomxahbmTSbdPDs8QKY47 x3wjUZMq/1QVFH30NhyfWVX//Q2iwioU5UmVAkFi0L8njOM5mrClaQIZ1DpApNHTYk EJZasDPtFxza/nnVcyQyvd6kXYdAuPngjkBAYvIE= Received: from [192.168.145.49] (ip-78-102-30-65.bb.vodafone.cz [78.102.30.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 93D9DD7887; Tue, 7 Apr 2026 12:32:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1775557936; bh=Gi0qaJ5CMZSDCIKOEPxhaS7I4Lu8u1dc2ibG6bc2bLQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=WfqtpoPA9Yu7P/VC90qKdTOZFPMcwcQmgD4XVThQ0FJDf1GByOCzTIAMJbp6kg0AP wqFguxqjF3ruKLmfcKkuV3+THajcfykcgl8FQR0NmMar+/lRw6y0/3eGruina++zFv G9wYNQ2TZGMbmDaUEH/sMnearclQoLIK/kvNKyjA= Message-ID: <4e4a795c-0dae-4e71-883a-0f3d45adb675@quip.cz> Date: Tue, 7 Apr 2026 12:32:14 +0200 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bhyve and controlled errors To: Sean Eric Fagan , "freebsd-virtualization@freebsd.org" Cc: "markj@freebsd.org" References: Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-virtualization@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=8nmG=CG=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[quip.cz]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4fqjF70Cgnz4FtM X-Spamd-Bar: -- On 26/03/2026 15:56, Sean Eric Fagan wrote: > I’d asked Mark about this and he suggested I bring it up on the list: > > Has anyone thought about implementing controls / tunables to bhyve to introduce errors? I am, most specifically right now, thinking about causing disk I/O errors, or having requests dropped by the "hardware," to test error handling. > > Last time I looked at the bhyve source code, it scared me, so if someone else has looked at this, I’m love to know. I understand it would be nice to have it directly as a part of bhyve, but if you need something right now, you can try "gnop". See man gnop(8): Its main purpose is testing other GEOM classes, as it allows forced provider removal and I/O error simulation with a given probability. Or maybe someone with skill can reuse its code for bhyve feature. Kind regards Miroslav Lachman