Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
I don't doubt at all that virtualization is useful in some
areas. What I doubt rather strongly is that it will ever have the
kind of impact that the people involved in virtualization want it
to have. It would appear that virtualization is the
"message-passing microkernel" of this decade, and that people have
a really hard time accepting that the reason operating systems
still basically look 100% the same today as they did almost forty
years ago, is that that is simply a very practical arrangement!
-- Linus Torvalds
In Linux we never ever assume a driver is working simply because
the hardware vendor tested it. A decade of real world experience
PROVES precisely the opposite -- getting code out into the world
early and often repeatedly turned up problems not seen in hardware
vendor's testing.
-- Jeff Garzik(Log in to post comments)
Virtualization Posted Aug 9, 2007 7:59 UTC (Thu) by nicolas@jungers (✭ supporter ✭, #7579) [Link] I don't question the 'very practical arrangement' assertion, but I really doubt that 'virtualization is the "message-passing microkernel" of this decade'.The main difference I see is the power of today's hardware. On the server side, if you don't crave for performance - which is the reality of most server deployment - pack 20 virtual servers on a (HA) cluster of 2 real server is very very convenient and way cheaper. On the desktop, if you're not encoding video or running huge model, it's also very practical to run one or several virtual boxes just to run some legacy application. So for my point of view, virtualization is a practical tool and not the result of design tinkering. I suspect that's the same for many peoples. Nicolas Jungers
Virtualization Posted Aug 9, 2007 10:27 UTC (Thu) by farnz (guest, #17727) [Link] Think about why you need 20 virtual servers, and not two virtual servers running on top of a HA virtualization system (or even a generic HA system that can migrate process groups between servers). I suspect you'll find that there's two causes:
There's other (lighter-weight) ways to handle buggy applications (e.g. namespaces, such that the application cannot see other apps running, and resource limits, to prevent the application taking over the server). As time goes on, I predict that we'll see the same process as has happened with microkernels; cool features will be implemented in virtualization systems, then the mainstream systems will work out how to implement the functionality people use in a more efficient way. For example, it's nice to be able to migrate a single application (inside its own virtual server) from one machine to another; someone will look at how we do that, and find a way to encapsulate the state of an application to migrate it around.
Virtualization Posted Aug 9, 2007 11:05 UTC (Thu) by nicolas@jungers (✭ supporter ✭, #7579) [Link] For the why, I'd at least add: some (better) guarantee of orthogonality, the comfort of containment in something easier to grasp (server vs namespace) and finally the ability to run 'any' OS.Granted, for most of my needs, real virtualization is overblown, and namespace separation would be enough while conserving resources. Now, because I've an enormous amount of unused resources, I prefer to just use the more comfortable solution that better covers my needs.
Virtualization Posted Aug 9, 2007 16:55 UTC (Thu) by vmole (guest, #111) [Link] 1. The psychological effect of having one application per server. Don't underestimate or ignore the power of this effect. The ability to ability to deploy a new application and guarantee that it won't disturb the existing ones is extremely important in a production system. And it's not just buggy apps. Library and subsystem version issues are a huge deal in a lot of environments. And when tracking down problems, having each app in a separate "machine" can make life a lot easier.
Virtualization Posted Aug 16, 2007 18:54 UTC (Thu) by robert_s (subscriber, #42402) [Link] You've got to stop and think about what you're trying to do.
The whole point of an operating system (at least one of them) is to safely multiplex between multiple processes.
If you're finding you're having to multiplex between different entire OSs to perform that task, your operating system isn't doing its job. You've got it set up entirely wrong.
I'm waiting for people to come up with hyper-hypervisors five years down the line when they find the need for their applications to intercommunicate has left them not trusting their hypervisors enough.
Stop building the turtles.
Re: Virtualization Posted Aug 16, 2007 19:22 UTC (Thu) by larryr (guest, #4030) [Link] Operating Systems are turtles; processes are turtles; MMUs are turtles. Partitioning the problem space and solution space are features of system design, not bugs. Larry
Virtualization Posted Aug 18, 2007 5:59 UTC (Sat) by NedLudd (guest, #37615) [Link] --------And when tracking down problems, having each app in a separate "machine" can make life a lot easier.
I agree completely.......it is also how things are done in a lot of shops
i really fell in love with virtualization when i worked for a company that wrote mail filters and i had to set up environments that mimicked customer setups.....pdc/exchange/app/client.....i could use base images, install software, test things out, and then revert it all....i could do a modest qa cycle in a short time....all without having to get up and turn boxes on and off or potentially hose my box.....
Quotes of the week Posted Aug 9, 2007 22:31 UTC (Thu) by bronson (subscriber, #4806) [Link] Virtualization vs. containers: virtualization is ahead and pulling away. Why? "Worse is better." (google that phrase if you haven't heard it)
Virtualization is huge and heavy. It carries along a ton of garbage (drivers, system logging, etc) that will never be used. Having 1 virtual machine per application is very wasteful of memory, CPU and disk space.
Containerization is nascent, poorly-defined, and still all too prone to DLL and resource sharing issues. But it's pretty darned efficient.
It's a shame that there's no middle ground.
Application streaming on windows is supposed to come near this on the Windows platform but, so far, it's suffering all the same problems of Unix containers, plus it costs a lot more money. I expect to see some big improvements in the next few years.
Personally, I wish I could bet on containers. I really hope a strong engineer steps up and ensures that containers become *really* useful. I should be able to launch an app on my computer, move it to my phone, and then to my set-top box at home, all without the app knowing or caring what's going on outside. Alas, there's very little motion on this front so I'm thinking we won't see anything like this until at least 2015.
Until strong containerization arrives, I'll be content with virtualization. So, even thoug virtualization is an overengineered disgusting hack, it will see FAR more traction this decade than microkernels ever did. Sorry Linus!
Quotes of the week Posted Aug 10, 2007 16:37 UTC (Fri) by nlucas (subscriber, #33793) [Link]
"It's a shame that there's no middle ground."
What about para-virtualization and hybrid-virtualization? They are not the same as full virtualization (in fact have more in common to containers than full virtualization).
Current efforts on the virtualization "scene" are for the para-virtualization and hybrid-virtualization fronts (VT-x is a para-virtualization hardware helper). Full virtualization exists for ages and hasn't changed much.
Quotes of the week Posted Aug 10, 2007 21:25 UTC (Fri) by bronson (subscriber, #4806) [Link] You're right that paravirt is a step in the right direction. It still carries a ton of crap along with it though. You still need a full kernel with all the drivers, logging infrastructure, cron, inetd, and so on... If the paravirt crews do a really good job at getting rid of this unimportant junk (where unimportant means "not directly related to the application I'm trying to run"), I'll definitely sit up and take notice.
At the moment, though, there's little appreciable performance difference between Xen and KVM (for my apps anyway). And KVM is sooooo much easier to set up and run. So, although it doesn't improve my life much today, I agree that paravirt could potentially become an excellent solution in a few years.
Operating systems almost forty years ago Posted Aug 11, 2007 17:28 UTC (Sat) by giraffedata (subscriber, #1954) [Link] the reason operating systems still basically look 100% the same today as they did almost forty years ago, is that that is simply a very practical arrangement! He means operating systems that are ancestors of Linux. If you consider all operating systems, or the ones that were most visible then, operating systems almost forty years ago looked quite different. One popular operating system almost forty years ago was VM/370, which looked a lot more like the current virtualization efforts than like classic Linux. The most popular operating system almost forty years ago was MVS, which is closer than VM/370 to what Linux is, but still only barely capable of doing interactive work and designed to be managed by a human operator. Considering that even Linux's ancestors where doing a rather different job -- running on physical machines that could not be made smaller and supporting multiple shell-level users -- it's hard to see how what was a practical arrangement then could have any bearing on what makes sense now.
Quotes of the week Posted Aug 16, 2007 6:37 UTC (Thu) by rafdz (guest, #41427) [Link] Hello.In a Micro kernel homepage(I think it was coyotos microkernel website) i have read that micorkernels were naturally supporting virtualization. It is even stated that micro kernel can provide a much faster virtualizaion than traiditional kernels. Micro kernels efficiency has seen much improvement during last decade: L4 is more efficient than mach and coyotos is more efficient than L4. There is also ongoing effort to formally validate those micro kernels. If and when this effort will be successful micro kernels may have a much larger success than today. Linux kernel code is so large that it is improssible to formally validate it.
|
|||||||||||||