From owner-freebsd-virtualization@FreeBSD.ORG Wed Apr 1 16:41:39 2015 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 117D4442 for ; Wed, 1 Apr 2015 16:41:39 +0000 (UTC) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (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 EE786812 for ; Wed, 1 Apr 2015 16:41:38 +0000 (UTC) Received: from [IPv6:2001:559:8000:cb:6169:845e:d470:e9f6] (unknown [IPv6:2001:559:8000:cb:6169:845e:d470:e9f6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4BB6718149; Wed, 1 Apr 2015 16:41:31 +0000 (UTC) Message-ID: <551C1FB7.1050501@redbarn.org> Date: Wed, 01 Apr 2015 09:41:27 -0700 From: Paul Vixie User-Agent: Postbox 3.0.11 (Windows/20140602) MIME-Version: 1.0 To: Udo Rader Subject: Re: available hypervisors in FreeBSD References: <551BC8B3.2030900@bestsolution.at> In-Reply-To: <551BC8B3.2030900@bestsolution.at> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:41:39 -0000 Udo Rader wrote: > ... > > I understand, that bhyve is native to BSD and will probably be the most > effective. But given its relatively 'young age', is it production ready > for (non nested) x86/amd64 linux guests? there's no libvirt for bhyve yet, which turns some people off. (not me, i don't use libvirt in any case.) there's significant clock drift, even with kern.timecounter.hardware="TSC-low" in the guests: > ... > Jan 26 05:38:08 guests ntpd[619]: time reset +0.223304 s > Jan 26 06:06:22 guests ntpd[619]: time reset +0.196973 s > Jan 26 06:34:24 guests ntpd[619]: time reset +0.200070 s > Jan 26 07:08:28 guests ntpd[619]: time reset +0.210997 s > Jan 26 07:36:09 guests ntpd[619]: time reset +0.205481 s > Jan 26 08:10:04 guests ntpd[619]: time reset +0.205461 s > Jan 26 08:39:43 guests ntpd[619]: time reset +0.175491 s > Jan 26 09:10:29 guests ntpd[619]: time reset +0.189261 s > Jan 26 09:44:03 guests ntpd[619]: time reset +0.164616 s > Jan 26 10:20:25 guests ntpd[619]: time reset +0.176280 s > Jan 26 10:56:18 guests ntpd[619]: time reset +0.161555 s > Jan 26 11:39:53 guests ntpd[619]: time reset +0.166066 s > Jan 26 12:31:11 guests ntpd[619]: time reset +0.142994 s > ... (that's much worse with the default kern.timecounter.hardware value, but still rather absurd.) i use bhyve in production and seems altogether ready. -- Paul Vixie