Date: Sat, 8 Feb 2014 16:57:45 -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: <CAGBxaXkN-66Vudnmwok7q2iK4zE0QzXZJaeKcf8pQSRJ0-TcaQ@mail.gmail.com> In-Reply-To: <CA%2BtpaK28UTbfSLycR4svYf_YFpX%2Bqaocs6CnverveXMShRPAhA@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> <CA%2BtpaK09B8HAKLdp2EQRgDfON1%2B-r_Nw6WMJ0ncF1yyW-h-6ig@mail.gmail.com> <CAGBxaXk-hSd5E4QEQfLGfuq3hGKHOY-fpnvbatROOG0qWW0pvA@mail.gmail.com> <CA%2BtpaK28UTbfSLycR4svYf_YFpX%2Bqaocs6CnverveXMShRPAhA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 8, 2014 at 4:07 PM, Adam Vande More <amvandemore@gmail.com>wrote: > > On Sat, Feb 8, 2014 at 2:57 PM, Aryeh Friedman <aryeh.friedman@gmail.com>wrote: > >> >> >> >> On Sat, Feb 8, 2014 at 3:54 PM, Adam Vande More <amvandemore@gmail.com>wrote: >> >>> >>> On Sat, Feb 8, 2014 at 2:14 PM, Aryeh Friedman <aryeh.friedman@gmail.com >>> > wrote: >>> >>>> >>>> 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?). >>>> >>> >>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXkN-66Vudnmwok7q2iK4zE0QzXZJaeKcf8pQSRJ0-TcaQ>