From owner-freebsd-virtualization@FreeBSD.ORG Sat Feb 8 20:24:45 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89A3A1A4 for ; Sat, 8 Feb 2014 20:24:45 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53C961BE0 for ; Sat, 8 Feb 2014 20:24:45 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id rd3so4588997pab.30 for ; Sat, 08 Feb 2014 12:24:45 -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=LSR/PujOdkOWAYdygmQV/IBuKYF84b06DeapZHkQfz0=; b=Sgb8rZcldcUnOAJrquDZ0vQaFVKWIOOR/+BoT0nD0xsB3fMVVTBaVdWkzx7S1K1HUg Yuu3AZqX7dLVYAP4NL7TLtt/FlTFHC/OGf1e6EukWaCHz/kETLe822nQSiXCIBfyooVM PyxX/Li9h+QmXcsQuso3Wl2tAZbqrqBvYxw0Nst4yxaXnKDwMQa/FLYIDWDtiH/HT+Rh BLnyNsizxLrC9MilFlkm1o2rslsj4DnCoEQEe/4cJyCAa7RosR+a0Xk25jixcJ7QeYuQ kggPZgt/hhSIHsolwIbxl28dqp1K9nbHM3bk78dwn9N2Ipiqk5e07/RzsInClLc/O8c4 hmaw== MIME-Version: 1.0 X-Received: by 10.68.240.36 with SMTP id vx4mr28075024pbc.140.1391891084975; Sat, 08 Feb 2014 12:24:44 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sat, 8 Feb 2014 12:24:44 -0800 (PST) In-Reply-To: References: <52F5363D.8040102@freebsd.org> Date: Sat, 8 Feb 2014 15:24:44 -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 20:24:45 -0000 On Sat, Feb 8, 2014 at 3:19 PM, Aryeh Friedman wrote: > > > > On Sat, Feb 8, 2014 at 3:14 PM, Aryeh Friedman wrote: > >> >> >> >> On Sat, Feb 8, 2014 at 3:01 PM, Adam Vande More wrote: >> >>> >>> On Sat, Feb 8, 2014 at 6:51 AM, Aryeh Friedman >> > wrote: >>>> >>>> bhyve blindly read/writes into the middle of the file without >>>> consulting the filesystem and thus bypassing any things like sparse fill >>>> in.... namely all you gain is a few seconds of startup time (matter of fact >>>> I think truncate might use sparse allocation [i.e. attempting to read into >>>> the middle with guest OS control will result in potentially seeing host >>>> data]) >>>> >>> >>> If this is true then there is a *critical* security issue. >>> >>> Using sparse files isn't to gain performance, it's to conserve disk >>> space. Using md devices backed by sparse images would accomplish this. If >>> the sparsify app works on FreeBSD, then there should be no problem using >>> those type of volumes. >>> >>> >> 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?). >> > > Forgot to mention that the host OS's disk scheduling also gives a brief > window of opportunity during the time after the inode is made and the old > contents wiped due to the size of the file > > My short memory must be going the main point I meant to make in the second reply is as far I know *ALL* hypervisors have the same blind read/write (remember they see what ever is acting as the disk as (from the VM's POV) a real disk and in order to maintain that illusion blind writes/reads are necessary) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org