Report of my virtual network lab migrated from virtualbox to bhyve

[Aryeh Friedman]

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


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org