Report of my virtual network lab migrated from virtualbox to bhyve

[Aryeh Friedman]

On Sat, Feb 8, 2014 at 3:19 PM, Aryeh Friedman <aryeh.friedman at gmail.com>wrote:

>
>
>
> On Sat, Feb 8, 2014 at 3:14 PM, Aryeh Friedman <aryeh.friedman at gmail.com>wrote:
>
>>
>>
>>
>> On Sat, Feb 8, 2014 at 3:01 PM, Adam Vande More <amvandemore at gmail.com>wrote:
>>
>>>
>>> On Sat, Feb 8, 2014 at 6:51 AM, Aryeh Friedman <aryeh.friedman at 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 at 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