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 <[EMAIL PROTECTED]> To: Igor Shmukler <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED]: Новый Bugatti – самый дорогой авто Женевы http://r.mail.ru/cln3686/auto.mail.ru _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
