From owner-freebsd-virtualization@FreeBSD.ORG Sat Feb 8 21:57:46 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92B82AA2 for ; Sat, 8 Feb 2014 21:57:46 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5945A12A8 for ; Sat, 8 Feb 2014 21:57:46 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so4595685pab.18 for ; Sat, 08 Feb 2014 13:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oMR+ga09H/NysvlrtnmJy0ZoA1xUD+6DcwL5XozCi5Q=; b=W51m+ES3gRZK5r2Pjqie8GqsMoAcq3BzV6qn7LfhaAE1vD7EGJHEfrKIDQvIRYazU0 7CW/ZKFv/OIjcRwfXXODPkIzxWv4Twpimi+0Um3wE4otZfQoD3lirzNR6F68g63xTgSi TnHBzxaPMIWwSfyW38v9rRhjUAJpp4S7/rjRZOGqX3AyKTb9t62ZRxnnuQvKiqux/G/9 tlidQ9Cxcn9mmiV6nzEeuGyCio69fq1uVSESVowPcjpsLVxnPXXI78tPmzz/hDWyBpKJ Ij5hQbOhwnAKXmm3uwt/j8kfVf/laF1euirJEXBwVaw0bWX2Pxst+q+QltIeYoUezkYP vVKg== MIME-Version: 1.0 X-Received: by 10.66.226.46 with SMTP id rp14mr16255053pac.133.1391896665998; Sat, 08 Feb 2014 13:57:45 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sat, 8 Feb 2014 13:57:45 -0800 (PST) In-Reply-To: References: <52F5363D.8040102@freebsd.org> Date: Sat, 8 Feb 2014 16:57:45 -0500 Message-ID: Subject: Re: Report of my virtual network lab migrated from virtualbox to bhyve From: Aryeh Friedman To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD virtualization X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.17 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: Sat, 08 Feb 2014 21:57:46 -0000 On Sat, Feb 8, 2014 at 4:07 PM, Adam Vande More wrote: > > On Sat, Feb 8, 2014 at 2:57 PM, Aryeh Friedman wrote: > >> >> >> >> On Sat, Feb 8, 2014 at 3:54 PM, Adam Vande More wrote: >> >>> >>> On Sat, Feb 8, 2014 at 2:14 PM, Aryeh Friedman >> > wrote: >>> >>>> >>>> It sounds almost identical to the qcow2 security issue being discussed >>>> on qemu-devel@qemu.org recently. This might be a *HUGE* win for >>>> bhyve then in considering that it's default format is raw (should ahci-hdd >>>> be the default?). devel/qemu (not sure about -dev) uses qcow2 as a >>>> default and when playing with it on other OS's I found that it seemed to >>>> default to that also. It is my understand that most of the open source >>>> cloud platforms use qcow2 as their default also (I remember this from an >>>> attempt to install openstack grizzly last summer... I have not checked >>>> havana though... can any of the freebsd-openstack confirm this?). >>>> >>> >>> I don't consider it a huge win because the possibility of using an >>> insecure device precludes it. Someone high on the tree bhyve needs to >>> confirm or deny this otherwise it is unsafe to recommend bhyve >>> or petitecloud. No offense intended, I really hope it succeeds and will >>> likely use it if it does. I cannot use anything which leaves the host >>> open. I am also unclear on how bhyve bypasses GEOM which *should* prevent >>> any of the symptoms discussed. >>> >> >> The point was that raw has no issue and this is the default for both >> bhyve and petitecloud (to avoid certain list politics I didn't mention it >> by name before). Sparse is the issue and thus qemu, openstack and >> cloudstack (as well as likely vbox) are a problem. >> > > Yes but bhyve *supports* other backing devices than raw correct? Then > this really bad. > > I don't want a politics game either, just saying you won't get adoption > until security is clear. I have no problem with you mentioning > petitecloud. Indeed I think you should but others may disagree. In your > opinion are ZVOL's a good option? > Starting tomorrow (now that I got the evil empire OS out of the way) I am going to be adding both networking and storage... in that order but I plan to handle some "low hanging" things in storage before getting deep into networking like allowing any block device to be used (it is up to the host admin how they want to attach it all petitecloud will need is a /dev/ entry or a backing file [some remote storage solutions do present this way not just disk image files])... we do not preannounce features normally but since this is security related we felt it was important to answer with specific plans (no specific due date though since that is our primary reason for not preannouncing is avoiding missing promised dates)... long term see the draft of a white paper I posted a week or so here -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org