Date: Sat, 8 Feb 2014 15:24:44 -0500 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Adam Vande More <amvandemore@gmail.com> Cc: FreeBSD virtualization <freebsd-virtualization@freebsd.org> Subject: Re: Report of my virtual network lab migrated from virtualbox to bhyve Message-ID: <CAGBxaXmujsxOyHFD3Rt2JpbQnanXXUD1D6LU=QK3JtrjCuSqqA@mail.gmail.com> In-Reply-To: <CAGBxaX=QuyMxC95RQDJ=6L4GMeh_Szyfj8yT-wtNeABWD2seQg@mail.gmail.com> References: <CA%2Bq%2BTcqw7uHLV3=DeZF4=i0hbmECkPP-d5-4ReSQqKCV-JaJ=Q@mail.gmail.com> <52F5363D.8040102@freebsd.org> <CA%2Bq%2BTcrZZb5o51F4pvLtxKM%2BNvO6SdVEQk_UMLLYSF8JfK6gpg@mail.gmail.com> <CA%2BtpaK2QCoxRocF7=zY3j9VETM7SJqFSVwpFGC0DuPSgFKJwZA@mail.gmail.com> <CAGBxaXmgzLncYi-5YPamqXD2nYvHi_eMUGQQe3hDmPEdyxd5%2Bw@mail.gmail.com> <CA%2BtpaK1VEw%2BRMfqLBukaXXADXtW82gC73TzXtiVGhSc9DrN=Qw@mail.gmail.com> <CAGBxaXk=NxY%2BENmCaW_GmHJCxYDR1-W-41W__xooTjz=ic1UEg@mail.gmail.com> <CA%2BtpaK3WvyZ2_Y5XunLV57hhwqpDFoRqQSZAxF=SKS4wib0t0A@mail.gmail.com> <CAGBxaXmFhZtJECH5-d_nY=e2ek=1ANFTsLTv6EHAFXEA34Cskw@mail.gmail.com> <CAGBxaX=QuyMxC95RQDJ=6L4GMeh_Szyfj8yT-wtNeABWD2seQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 8, 2014 at 3:19 PM, Aryeh Friedman <aryeh.friedman@gmail.com>wrote: > > > > On Sat, Feb 8, 2014 at 3:14 PM, Aryeh Friedman <aryeh.friedman@gmail.com>wrote: > >> >> >> >> On Sat, Feb 8, 2014 at 3:01 PM, Adam Vande More <amvandemore@gmail.com>wrote: >> >>> >>> On Sat, Feb 8, 2014 at 6:51 AM, Aryeh Friedman <aryeh.friedman@gmail.com >>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXmujsxOyHFD3Rt2JpbQnanXXUD1D6LU=QK3JtrjCuSqqA>