vkernel & GSoC, some questions
Igor Shmukler
shmukler at mail.ru
Mon Mar 17 03:19:09 UTC 2008
Matt,
You sure won't argue that UML isolation is inherently better than one that can be provided by a hypervisor. If the performance is the same, what are you gaining?
Hypervisor while slow, allows treating a complete OS with all applications as a black box. Why would I choose UML over a hypervisor?
I am not trying to say there cannot be a place for vkernel. [I don't even yet understand what is does or how.] However, as a hosting company, why would I choose UML over a hypervisor?
I can provide a number of reasons to pick a hypervisor:
1. use the same platform to host Unix, Windows and other guests
2. load balance all available hardware [based on some policy]
3. better implies that a hypervisor upgrade is less likely to damage guests
I am sure people hosting on hypervisors could write a longer list.
Containers [including jail] provide significantly lower overhead[, but more difficult to maintain]. At least it can be argued [probably both ways] that containers are cheaper.
Are there real world people hosting with UML today who could comment on this, perhaps supporting Matt's position?
igor
-----Original Message-----
From: Matthew Dillon <dillon at apollo.backplane.com>
To: Igor Shmukler <shmukler at mail.ru>
Date: Sun, 16 Mar 2008 17:12:00 -0700 (PDT)
Subject: Re: Re[2]: vkernel & GSoC, some questions
>
>
> :
> :Given the fact that there are not as many developers as needed, what would be a practical purpose of vkernel?
> :
> :UML is typically used to debug drivers and/or for hosting. Now that Linux about to have or already has container technology, hosting on UML makes little sense.
>
> The single largest benefit UML or a hardware emulated environment has
> over a jail is that it is virtually impossible to crash the real kernel
> no matter what you are doing within the virtualized environment. I
> don't know any ISP that is able to keep a user-accessible (shell prompt)
> machine up consistently outside of a UML environment. The only reason
> machines don't crash more is that they tend to run a subset of available
> applications in a subset of possible load and resource related
> circumstances.
>
> Neither jails no containers nor any other native-kernel technology will
> EVER solve that problem. For that matter, no native-kernel technology
> will ever come close to providing the same level of compartmentalization
> from a security standpoint, and particularly not if you intend to run
> general purposes applications in that environment.
>
> The reason UML is used, particularly for web hosting, is because
> web developers require numerous non-trivial backend tools to be installed
> each of which has the potential to hog resources, crash the machine,
> create security holes, or otherwise create hell for everyone else. The
> hell needs to be restricted and narrowed as much as possible so human
> resources can focus on the cause rather then on the collateral damage.
> For any compute-intensive business, collateral damage is the #1 IT issue,
> the cost of power is the #2 issue, and network resources are the #3
> issue. Things like cpu and machines... those are in the noise. They're
> basically free.
>
> With a virtual kernel like UML (or our vkernel), the worse that happens
> is that the vkernel itself crashes and reboots in 5 seconds (+ fsck time
> for that particular user). No other vkernel is effected, no other
> customer is effected, no other compartmentalized resource is effected.
>
> Jails are great, no question about it, and there are numerous applications
> which require the performance benefits that running in a jail verses
> an emulated environment provides, but we will never, EVER see jails
> replace UML. This is particularly true considering the resource being
> put into improving emulated environments. The overhead for running an
> emulated environment ten years from now is probably going to be a
> fraction of the overhead it is now, as hardware catches up to desire.
>
> -Matt
>
Авто@Mail.Ru: Новый Bugatti – самый дорогой авто Женевы
http://r.mail.ru/cln3686/auto.mail.ru
More information about the freebsd-hackers
mailing list