|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Publicity] Seems the VM vs container debate is heating up
Yes, there are: miniOS is similar to OSv but less complete and only supports PV guests. The miniOS approach allows one POSIX application to run within one PV guest virtual machine with minimal operating system overhead. At the same time PV (and the newer PVH) guests are low overhead compared to HVM guests as they don't provide any emulated interfaces. Overall miniOS (or OSv) on a PV guest is a great fit for micro-virtualization. On Tue, 8 Apr 2014, Sarah Conway wrote: > I like Stefano's point aboutÂXen building bridges here -- seems like a new > twist on the VM vs. container debate. The > fact thatÂXen is evolving with the times and it's not a binary choice might > play reasonably well.  > Are there are any major technical differences between the miniOS approach and > containers? > Thanks, > > > On Tue, Apr 8, 2014 at 1:13 PM, Lars Kurth <lars.kurth@xxxxxxx> wrote: > I think it's a great post > Lars > > On 08/04/2014 14:54, Russ Pavlicek wrote: > I've got the following blog post queued for open.citrix.com later > today (it was my turn and this topic seemed timely). > > I am leaving for the airport in a couple hours, so if anyone has > concerns, please let me know in the next hour or so if you can. > Otherwise, I may have to edit after it is autopublished later > tonight. > > It isn't a Xen Project piece per se, but I wanted to highlight the > MirageOS/OSv/etc. solution to highly dense VM app farms. > > --- > > Are Containers the Right Answer to the Wrong Question? > > Next-Gen, High Density App Servers Don't Require Scrapping Your > Hypervisor > > Recently, I sat in a conference session extolling the seemingly > endless virtues of Linux Containers. ÂI heard claims that > hypervisors > were old hat: ancient bloated engines which rely on inefficient > replication of a large operating system stack in order to serve up > applications. ÂThe speaker painted a picture of a future where > hundreds of applications are virtualized on each piece of > hardware. > "What is really needed," glowed the speaker, "is a lightweight, > efficient means of serving up application: containers." > > Containers are cool, but not a panacea > > Containers share the same kernel as the host, so they are not > burdened > with the extra memory and CPU cycles it costs to replicate a full > operating system stack in a hypervisor scenario. ÂCompared to > hypervisor-generated virtual machines, containers can be fast and > lean. ÂBut they are also limited. > > Since Linux containers share the same kernel as the host, it is > impossible to run Windows. ÂOr FreeBSD. Or NetBSD.  Or another > version of the Linux kernel. ÂOr another Linux distribution which > requires a different kernel. ÂAll of those scenarios are best > handled > by a real hypervisor. ÂAnd the security aspect of hypervisors is > huge, > worthy of a separate blog entry of its own. ÂStill, if you need an > environment within your organization where many workloads can > leverage > a single kernel environment, containers can be a viable solution. > > However, some of the most vocal container advocates insist that > these > problems relating to containers are really application problems in > disguise. ÂIssues about kernel support and security are the > results of > improper application design, they claim. ÂWhen we raise the bar on > applications so that they are based solely on access to > application > servers, then the objections to containers will melt away -- and > so > will hypervisors, for the most part. ÂOr that's what some of these > advocates claim, at least. > > The death of the hypervisor is greatly exaggerated > > But is there another scenario which could answer the call for > highly > responsive and lightweight virtual instances which does not use > the > container solution? ÂMaybe one that can actually leverage the > flexibility and security which is part and parcel with most > hypervisors? > > Yes, in fact, there is. ÂAnd the key is in the very > application-centric future which some container advocates believe > will > cause the hypervisor to become obsolete. > > Behold the birth of the Cloud Operating System > > Instead of deriding hypervisors for the "bloat" of replicating a > full > operating system, we can replicate ultra-light application-centric > operating systems which are meant to live in a VM. ÂA number of > these > lean, mean virtual operating systems have arisen recently, > including > the Xen Project team's MirageOS and Cloudius Systems' OSv. ÂThese > lightweight operating systems, sometimes called "cloud operating > systems", lack the expensive drivers needed to talk to hardware -- > because they aren't meant to run on hardware. ÂAnd they lack > multiprocess capabilities because they are not intended to be > general > timesharing systems, but dedicated application server systems.  > As a > result, they are very small, very lightweight, and can start up > amazingly quickly in a VM environment. ÂThey enable the vision of > light and fast application servers, while preserving the superior > security and flexibility of true hypervisors. > > Don't throw the hypervisor baby out with the dirty application > bath water > > So if you are intrigued by the vision of masses of small, > efficient > application VMs packed into a minimum of number of servers, but > cringing at the notion of totally retooling your virtualization > infrastructure and rethinking your entire security mindset, don't > fret. ÂThat vision is achievable while maintaining the > flexibility and > security that mature hypervisors deliver. ÂFocus on a streamlined > application stack, and the vision of dense, efficient application > VMs > is achievable -- regardless of whether you are using hypervisors, > containers, or both. > > > On Tue, Apr 8, 2014 at 9:42 AM, Stefano Stabellini > <stefano.stabellini@xxxxxxxxxxxxx> wrote: > Also this tells us that whatever tecnology we choose to > have upstream > QEMU stubdoms, we should make sure it is easy to use for > other POSIX > applications too, so that we can advertise it as a generic > solution for > Xen micro-VMs and position it as a secure alternative to > containers. > > On Tue, 8 Apr 2014, Stefano Stabellini wrote: > Given that most people only use one VM for one task, > the rise of > "micro-VMs" makes sense, whether they are based on > OSv (miniOS or rump > kernels) on traditional hypervisors or on Docker, > ZeroVM or other types > of containers. > > However what these articles don't take into account > is that Xen can > already handle both kind of workloads extremely well: > Xen can handle > fat > old-style VMs, with HVM guests, and new style > lightweight micro-VMs, > with miniOS (or rump kernels or OSv) inside a PV > guest. > > If I manage to carve the time to do it I might be > able to write a blog > post about it. > > On Tue, 8 Apr 2014, Lars Kurth wrote: > See: > > * > > http://blogs.bromium.com/2014/04/07/vms-the-new-infrastructure-anachronism/ > * On the other hand there is this article: > > http://www.zdnet.com/hypervisors-are-the-pillars-of-the-cloud-not-the-achilles-heel-7000027931/ > (both by Simon Crosby) > > Generally for the security discussion, which is > related, > the following > articles may be relevant: > * > > http://www.zdnet.com/hypervisors-the-clouds-potential-security-achilles-heel-7000027846/ > * > > http://www.economist.com/blogs/babbage/2014/03/computer-security > The following two may also be useful (and > contain quite a > few useful links) > despite also being partly a product pitch: > * > > http://blogs.bromium.com/2013/03/27/micro-virtualization-for-the-security-architect/ > * > http://blogs.bromium.com/2013/04/24/micro-virtualization-for-the-security-architect-2-of-2-isolation-%E2%89%A0-protect > ion/ > > Lars > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > > > -- > Sarah Conway > PR Manager > The Linux Foundation > sconway@xxxxxxxxxxxxxxxxxxx > (978) 578-5300 ÂCell > Skype: Âsarah.k.conway > > _______________________________________________ Publicity mailing list Publicity@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |