Report of my virtual network lab migrated from virtualbox to bhyve

[Aryeh Friedman]

On Sat, Feb 8, 2014 at 4:07 PM, Adam Vande More <amvandemore at gmail.com>wrote:

>
> On Sat, Feb 8, 2014 at 2:57 PM, Aryeh Friedman <aryeh.friedman at gmail.com>wrote:
>
>>
>>
>>
>> On Sat, Feb 8, 2014 at 3:54 PM, Adam Vande More <amvandemore at gmail.com>wrote:
>>
>>>
>>> On Sat, Feb 8, 2014 at 2:14 PM, Aryeh Friedman <aryeh.friedman at gmail.com
>>> > wrote:
>>>
>>>>
>>>> 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?).
>>>>
>>>
>>> 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