Virtualization is a symptom of failure
|
| Author | Content |
|---|---|
| Grishnakh Oct 06, 2011 9:17 PM EDT |
Virtualization really shouldn't exist; it's a symptom of a failure of operating systems to do their job properly, or the failure of applications to be available on different operating systems. Ideally, VMs should not exist. The whole point of having a multi-user time-sharing operating system was so that multiple users could share the same machine resources, and also so that users could perform multiple tasks simultaneously, and all these different tasks (whether owned by the same user or different users) would be very limited in how they could affect each other. So if you have a server that's underutilized, for instance, you should be able to just move more processes to it, until it's fully utilized. The usage of VMs in servers seems to be due to failures of OSes to be sufficiently robust and reliable and secure, so admins use VM to partition them, so that if one instance fails or is hacked or whatever, it doesn't affect others. If they have multiple customers, they can have them share the same machine by giving them each a separate VM. But this obviously defeats the entire purpose of the OS, which is to partition the machine so that multiple users can share its resources, so the fact that anyone bothers with virtualization shows that OSes aren't doing their job well enough in this regard. To make a transportation analogy (as is always popular), It's a bit like building 100 parallel passenger rail lines, so that every passenger can have an entire train to him/herself, when the entire point of the train was for multiple people to share it to increase efficiency. Using VMs on single-user machines is frequently done so you can run multiple OSes at once, but again this is a failure. You should be able to run your application on any sufficiently-popular OS, or better yet, OSes should be standardized so that apps can run on any of them (this was the goal of POSIX). The fact that you need OS A to run app X, OS B to run app Y, etc. shows that things just aren't working the way they should. |
| gus3 Oct 06, 2011 9:33 PM EDT |
Wasn't that part of the purpose of Plan 9, to distribute tasks to nodes that could handle them? |
| mbaehrlxer Oct 07, 2011 12:30 AM EDT |
Grishnakh: you make some very good points. but now the question is, if the currently available operating systems are a failure, how do we fix them? as you say the purpose of an OS was to isolate applications from each other. now the current approach to isolation fails because it does not isolate applications enough. for complete isolation, an application needs to be completely unaware of the existance of other users or applications. VMs are a new approach to isolation. this new approach has problems too.namely that it requires you to create complete copies of the OS code and that it is not flexible enough in allocating and sharing resources. but OSs previously solve the problem of flexibly allocating and sharing resources. throwing out VMs is ignoring half of the problem set. what we really need is a combination of the two approaches. complete isolation AND flexibly allocating and sharing resources. this is even more pressing now since we are dealing with malware and other untrusted applications that running multiple OS instances in parallel is not enough. even for a single user we really need to isolate every application from the other and only allow them to communicate over controlled interfaces. how can we get there? i don't know, but i think we will get there. the users needs will push us to it. as it stands the problem is approached from two angles: from the OS by increasing the isolation of applications in efforts like OLPC Sugar and Android (and probably others that i am not aware of, i think microkernel research also fits here), and from the VM by increasing the flexibility in allocating and sharing resources. (growing diskspace on demand for example, allocating memory at runtime) eventually they will meet somewhere in the middle. greetings, eMBee. |
| krisum Oct 07, 2011 3:56 AM EDT |
> So if you have a server that's underutilized, for instance, you should be able to just move more processes to it, until it's fully utilized. It is quite likely that different persons need to host apps targeted for different OSes for instance. VMs also make it easy to run multiple web/app server instances on the same node that are isolated from one another having own IP, which is difficult to achieve using normal OSes alone. Many VM implementations also allow to move a VM from one machine to another on the fly to balance load, for example, which is not possible with normal OSes. To provide all that functionality and more as in modern VM implementations, one would require a significant redesign of the OSes and likely end up with what VMs provide ... |
| dinotrac Oct 07, 2011 7:06 AM EDT |
Yawn. Dibble dablle rubble ribble rant rant rant. Yeah, OK. There should be one operating system for every purpose and it will magically be optimized for every use. There will never be a need for different versions because it's already perfect. It will use no memory or cpu, so there will be no reason to worry about tailoring for resource use. It will do realtime and non-realtime work automatically and perfectly, so yet another concern gone. And it will train everybody to want the exact same thing! Wait -- that last one's already here. It's called OSX. Macs notwithstand, it's just too bad the rest of us are too stupid to achieve that, @grishnakh. Worse -- some of us are so bone-crushingly dense that we don't even want that. Humanity. A cesspool of utter and irredeemable stupidiy. I don't know how you stand it. |
| Grishnakh Oct 07, 2011 4:31 PM EDT |
mbaehrlxer wrote:now the current approach to isolation fails because it does not isolate applications enough. for complete isolation, an application needs to be completely unaware of the existance of other users or applications. Why is that necessary? As long as the processes can't interfere with each other, that should be sufficient. Don't forget, for many modern tasks, a certain amount of IPC (inter-process communication) is necessary, using things like D-bus. Otherwise, programs can't communicate with the window manager, for instance. mbaehrlxer wrote:this is even more pressing now since we are dealing with malware Malware comes from two places: it's another symptom of failure in OS design and also application design, when security vulnerabilities are exploited (like overflow exploits). Secondly, it's a failure of users (when users run trojan horses, for instance). VMs don't solve either problem, though they can help mitigate the damage. Look at how long it was possible for MS Windows users to get infected just by looking at emails or bad web pages; that's a classic case of poor design. krisum wrote:It is quite likely that different persons need to host apps targeted for different OSes for instance. That in my book is a failure of some kind. You should be able to run your app on any sufficiently-popular OS, instead of being stuck in various "walled gardens". What would be ideal is if there were several OSes, all standards-based and completely compatible with each other, so you can run your apps on any of them. This would probably require them to be non-commercial, as having an OS that's produced and sold (at a profit) by a for-profit corporation is completely at odds with the idea of having common standards; as we saw with MS over and over, they'd happily make changes to their OS or other infrastructure software to intentionally make it incompatible with other systems, in order to get you to buy their OS. At the least, a commercial OS maker should be barred from producing any applications at all. Having apps compete with each other in the commercial marketplace is one thing, but having those apps only run on certain OSes, and worse having the OS maker make their own versions of certain apps which compete with other peoples' apps targeted for that OS, is simply a bad situation and a conflict of interest. It isn't any better on the Mac side either. krisum wrote:VMs also make it easy to run multiple web/app server instances on the same node that are isolated from one another having own IP, which is difficult to achieve using normal OSes alone. I believe that's pretty easy to do using VLANs. You just need to have VLAN-capable routers and switches, but that's a given in any datacenter. krisum wrote:Many VM implementations also allow to move a VM from one machine to another on the fly to balance load, for example, which is not possible with normal OSes. This seems like an exceedingly useful feature that really should be in OSes. In fact, I wonder if some big-iron OSes haven't already had this feature for some time. It frequently seems like we're reinventing computing concepts that have been around since the 60s and 70s. dinotrac wrote:There should be one operating system for every purpose and it will magically be optimized for every use. Computers should be smart enough to make themselves nearly optimal for every use. Why do you think the Linux folks spend so much time tweaking the scheduler? dinotrac wrote:It will use no memory or cpu, so there will be no reason to worry about tailoring for resource use. If you're using a VM, then obviously you're not on a resource-constrained embedded system or the like. VM+OS always equals more overhead than OS alone. dinotrac wrote:It will do realtime and non-realtime work automatically and perfectly, so yet another concern gone. There's no technical reason an OS can't do realtime and non-realtime work together. Linux already does this to a large extent. However, if you throw a VM on there, suddenly your RTOS isn't going to be realtime, since it's no longer running directly on the hardware. So what exactly is your point here? If you're saying that general-purpose OSes are inferior to minimalist RTOSes on embedded hardware, that's true for now, but it's irrelevant because we're talking about VMs here, and no one would ever run a VM on a small embedded system and then a couple of RTOSes on top. I'm questioning the need for VMs, on systems where people would actually run VMs for some reason. |
| dinotrac Oct 07, 2011 11:03 PM EDT |
>There's no technical reason an OS can't do realtime and non-realtime work together. There is, actually, if you understand the difference between realtime and non-realtime. On one level, I suppose you're right -- one could conceive of an OS capable of doing both, but... a realtime OS has a characteristic that many of us don't tend to want with our non-realtime work: a hard-end. A realtime OS responds to long-running tasks by killing them. That's part of the definition of a real-time OS: guaranteed completion time, whether all of the work has been accomplished or not. Very handy for something like telephone switching where there is a limited window for returning a result, but maybe not so hot for other work where you'd rather have your task take a little longer than have to start it over. |
| mbaehrlxer Oct 07, 2011 11:30 PM EDT |
Grishnakh wrote:Quoting:now the current approach to isolation fails because it does not isolate applications enough. for complete isolation, an application needs to be completely unaware of the existance of other users or applications.Why is that necessary? As long as the processes can't interfere with each other, that should be sufficient. that's exactly the issue. processes can interfere with each other. they can block resources, they can eat memory, they can hog the cpu, they can read each others data on disk. we are so worried about a website reading our browsers history, but then we download some neat application and that can read the full history, the browsers cache, the email and all my private files. Grishnakh wrote:for many modern tasks, a certain amount of IPC (inter-process communication) is necessaryIPC can easily be done over a network socket. there is no need to give up IPC just to get better process isolation. Grishnakh wrote:it's a failure of users (when users run trojan horses, for instance)to blame users is easy, but not fair in my opinion. users are overwhelmed with todays complexity of running a computer. on a linux distribution i can sufficiently trust the distributors to not feed me with trojans and the like, but on anything else i too am overwhelmed. on windows, or even on other commercial unix systems i have to download software from untrusted 3rd party sites, and every time i do that i am wondering if i can trust this one or not. linux distributions have trained me that such a screening process is helpful and necessary, but windows users lack this kind of training. they are completely oblivious to it. so how can i blame them for downloading a trojan? Grishnakh wrote:VMs don't solve either problem, though they can help mitigate the damage.you are right, process isolation is protection and damage control. just like putting law offenders in prison. the real solution would be to educate the law offenders and help them to stop offending. but until that can be achieved noone is suggesting that prisons should be closed and they should be left to run free. same goes for misbehaving software. until we can completely eradicate bad software we need some kind of software prison. note that i very much wish that we can build a society where less people are sent to prison. greetings, eMBee. |
| krisum Oct 08, 2011 6:50 AM EDT |
> I believe that's pretty easy to do using VLANs. You misunderstand isolation as being limited to this. > That in my book is a failure of some kind. You should be able to run your app on any sufficiently-popular OS, So you mean that all OSes should also have similar behaviour, performance and other characteristics too? Then why not just force a single OS down on everyone. > This would probably require them to be non-commercial, as having an OS that's produced and sold (at a profit) by a for-profit corporation is completely at odds with the idea of having common standards; as we saw with MS over and over You are confused and bringing in completely unrelated stuff. Think Linux and FreeBSD first for instance. > In fact, I wonder if some big-iron OSes haven't already had this feature for some time. Precisely, using hardware layer support for virtualization (e.g. IBM zseries). > It frequently seems like we're reinventing computing concepts that have been around since the 60s and 70s. To a large extent, but now on commodity hardware. What you don't seem to understand is that all these requirements, some of which I mentioned, are what lead to virtualization as they have in the past on mainframes. An OS that intends to support these requirements will end up doing virtualization of some form or the other [http://en.wikipedia.org/wiki/VM_(operating_system)]. |
| Grishnakh Oct 08, 2011 6:13 PM EDT |
mbaehrlxer wrote:that's exactly the issue. processes can interfere with each other. they can block resources, they can eat memory, they can hog the cpu, they can read each others data on disk If your OS allows processes to hog the CPU, your OS isn't working right. Any decent OS by now has fixed this. This sounds like something out of the days of cooperative multitasking. Now of course, a process can peg the CPU when it's assigned timeslices, but as long as the scheduler gives time to other processes, this shouldn't be a problem. I believe the Linux scheduler identifies processes that hog the CPU and gives them lower priority, so that other processes don't experience too much latency (as frequently, CPU-hog processes are background work processes that don't need to be done that quickly; for instance, suppose you run a SETI@home instance. It'll hog the CPU, but you don't want it to have priority over everything else). Same goes for memory; any decent OS will kill processes that hog too much memory. This is part of the job of the OS, to make sure processes share the resources and no one process takes over everything. And no, processes should not be able to interfere with each other, unless there's some kind of IPC mechanism in place, which could potentially have a bug or vulnerability. There should be no way at all for processes owned by different users to interfere with each other. However, you're right about them having access to each others' data on disk (only for processes owned by the same user, normally), and this can cause problems. Quoting:to blame users is easy, but not fair in my opinion. users are overwhelmed with todays complexity of running a computer. Unfortunately, I don't think it's possible to have a computer where a user has the freedom to execute any arbitrary program, whether it's one he wrote himself or one downloaded from the internet, but then be safe from that program trashing his data or joining a botnet. From what I read, that's still how many worms/trojans infect Windows computers these days, since they've finally cut off the ActiveX vector: they send emails to ignorant users, telling them to save the attached file to their disk and run it so they can see some cute puppies or whatever, and the users do exactly that. How can you possibly protect against that? Simple: you can't, unless you make the device totally locked down, so that only cryptographically-signed executables can be run on the system. If you do that, you now basically have an appliance, not a general-purpose computer. Quoting:You are confused and bringing in completely unrelated stuff. Think Linux and FreeBSD first for instance. I don't think I'm confused at all. Linux and *BSD are POSIX OSes, so they share the same API, and can run the same software (it may need a recompile of course, since the same OS running on different CPU architectures can't run the same programs). So if a closed-source application developer makes a version of, say, AutoCAD for Linux, it's really not hard for him to recompile it to run on FreeBSD. It should be like this for any OS. The lack of a standard API is what's preventing this, and it's impossible to have standardization as long as for-profit corporations control the dominant OSes. |
| Grishnakh Oct 08, 2011 6:16 PM EDT |
Quoting:same goes for misbehaving software. until we can completely eradicate bad software we need some kind of software prison. It seems like OSes should have some more "prison-like" features built in to them to achieve this goal, rather than putting each OS in its own separate prison. |
| mbaehrlxer Oct 08, 2011 11:40 PM EDT |
Grishnakh wrote:It seems like OSes should have some more "prison-like" features built in to them to achieve this goal, rather than putting each OS in its own separate prison.of course they should have, but they don't. i am not disagreeing with you here. as i said in my first post, putting each OS in its own separate prison is a stopgap measure to solve the problem here and now instead of waiting until we manage to develop an OS that has more "prison-like" features. Grishnakh wrote:If your OS allows processes to hog the CPU, your OS isn't working right. Any decent OS by now has fixed this.doesn't look like it to me. if i run any process at 99% cpu, the machine becomes slow. what you say is right in theory, but that has been true for decades, it's how unix/linux is designed. but it still seems to fails in some cases. see ken colivas work on this subject. as far as i know his alternative scheduler has not yet been accepted into the kernel. Grishnakh wrote:any decent OS will kill processes that hog too much memory.no they won't. the OS will only kill the process if it requests memory that is not actually available. as long as there is free memory it will allow the process to happily eat it up and then kill the other process that needs a bit more memory so that it can do its job. if there is swap it will happily swap processes around, and if they are fighting for attention and both need more memory together than the machine has it may end up in a swap orgy with the user being left behind. even without swap if i run to many programs that all need memory on my laptop with 2GB ram and no swap, the machine gets slow, often unusable. therefore the problem has not yet been solved for me. greetings, eMBee. |
| dinotrac Oct 09, 2011 5:22 AM EDT |
@embee - It's not just that you are right, it's that the behavior @grishnakh describes is wrong for a general-purpose OS. It presumes that you always want certain behaviors to take place, but the assumption is wrong. A real-time OS knows to kill processes after a certain amount of time has elapsed and to execute the appropriate "I failed" logic. It knows that because guaranteed completion time is part of the definition. AND, even then, it doesn't rear up out of the blue and say "Begone dastardly process. Your sloth doth offend me!" It responds to criteria that have been set for it based on application requirements. A general-purpose OS might make the compromise of killing processes when it is out of memory on the basis that all processes will die of the system goes down, so nothing is lost, but...short of that, it's hard to know what should be done. What, for example, if one process is hogging up resources and causing problems for remaining processes while bringing the system to the bring of uselessness? Do you kill that process? Do you kill that process even if it is the most important thing being run on the box and, given a choice, you would rather kill everything else running? It's in the nature of a general purpose OS that it is asked to run all kinds of work, and that work is defined by more than its resource requirements. |
| hkwint Oct 09, 2011 9:06 AM EDT |
Quoting:and it's impossible to have standardization as long as for-profit corporations control the dominant OSes. Of course not! That's the whole idea of DIN and all sheep who followed DIN (think ANSI, CE, ISO, IEEE and what do we have these days). The whole standardization-industry was created to make for-profit corporations create compatible parts. And it worked! Moreover, it worked really well. Margins of part makers approached zero as a side-effect, so of course that's the way software makers don't want that scheme. Or do you think nuts and bolts should be made by non-profits too? That's just not realistic in any way! Why do you think nuts are only 10 cents a piece or so? Right, because there's for-profit companies competing, and as a result whole society benefits. Nuts are made by the cheapest for-profit companies and the expensive inefficient companies go bankrupt. Look at USB, CD, GSM etc: All made by for-profit corporations. Same for the "standard charger for phones"; OK, it took the EC to push all phone makers to use the same chargers, but it was implemented by for-profit companies! Hmm, well, all except for Apple of course. EC could find them for environmental pollution and wasting time of users I think. Eventually however, things will fix themselves. What's the tendency these days? HTML5 + Javascript + CSS3. Exactly what you're asking for: Standardized stuff which works on different OS'es on different browsers on different architectures on different formfactors, be it desktop, tablet, table computer or mobile. Sure, I think you could see the JS-engine as some kind of "virtualization" and symptom of failed OS-design, but nonetheless it works pretty well. In some way it has pre-emptied Apple's proprietary App-Store, as some publishers didn't want to be milked by Apple and made their own HTML-app. gus3: Not sure if you have ever looked into Inferno, but sadly it never became that popular. Designed to do neat tricks like combining ' hybrid resources' (which doesn't necessarily have to be in the same computer) into one "file". And taking the "everything is a file"-approach to new levels. Guess some of the ideas were implemented by VM's like Java-VM after all (in Inferno it's called Dis VM and the programming language is Limbo). On the other hand: How long did it take for MULTICS ideas to become popular and become mainstream? Over 20 years I guess, and only after some people decided "doing it right" would take to long, and in a hurry they created a low quality rip-off of MULTICS. Nowadays known as UNICS ("If it doesn't work or crashes, reboot" and "to heck with error checking, without it we can code three times faster" was the main-philosophy of UNICS in the early days). Contrary to popular belief, I think the IT sector is pretty conservative, still using decade old paradigms, and wary of "new technologies", even if the new ones are more promising. Guess IT after all is closer to the conservative aviation-branch than to the quicker moving automotive sector. |
| chalbersma Oct 10, 2011 12:38 PM EDT |
You guys need to look at FreeBSD Jails. |
| Grishnakh Oct 10, 2011 5:39 PM EDT |
mbaehlxer wrote:doesn't look like it to me. if i run any process at 99% cpu, the machine becomes slow. what you say is right in theory, but that has been true for decades, it's how unix/linux is designed. but it still seems to fails in some cases. I actually don't see this on Linux machines any more. Instead, if some process is pegging the CPU, I only see it in my system monitor (such as gkrellm), and if I look at top. Other processes have equal priority, so they're not resource-starved, but the CPU is wasting its spare time on the offending process, when it could be sleeping instead. However, if a process is doing a lot of disk activity, or if memory's been exhausted and the system has resorted to using swap (and is thus "thrashing"), then yes, I'll definitely see the machine slow down. But if you use "ionice" on processes using a lot of disk I/O, this will completely eliminate any slowness from that; the same can be done for CPU-hogging processes (for instance, SETI@home and other computationally-intensive tasks). It does seem like this stuff should be more automatic however. Quoting:even without swap if i run to many programs that all need memory on my laptop with 2GB ram and no swap, the machine gets slow, often unusable. therefore the problem has not yet been solved for me. Honestly, I'm not sure how you'd fix this problem (i.e., you're running too many processes for the amount of system memory you have, and none of them are hogs), except maybe a userspace monitor that monitors memory usage and warns the user if the program they're attempting to run is going to change their machine state from smooth-running to thrashing the swap space. On a multi-user system, you could have some sort of soft quota (like they do with disk space), so that if memory pressure is low, the user can use a lot of memory, but if memory pressure is high (lots of users are logged in), then each user's quota is more strictly enforced and their memory gets swapped out. Of course, these days it doesn't seem like anyone uses multi-user systems much any more; they use systems that can be multi-user, but there's never more than one user (sometimes two) logged in at once; if it's a desktop system, those users are actual people, if it's a server, those users are apache processes or similar. hkwint wrote:On the other hand: How long did it take for MULTICS ideas to become popular and become mainstream? Over 20 years I guess, and only after some people decided "doing it right" would take to long, and in a hurry they created a low quality rip-off of MULTICS. I'd like to see more MULTICS ideas move into Linux or other similar OSes. Machines now are so powerful the overhead wouldn't be a big deal, and the extra protection and robustness would be welcome. Quoting:The whole standardization-industry was created to make for-profit corporations create compatible parts. And it worked! Moreover, it worked really well. Margins of part makers approached zero as a side-effect, so of course that's the way software makers don't want that scheme. Software isn't like nuts and bolts in almost any way. With nuts and bolts, the criteria for evaluation are few and simple (dimensions, tensile strength, yield strength, etc.), so it's easy to compare. A software application can comprise millions of lines of code; there's no easy way to compare two similar applications in many cases. Regardless, this is beside the point, my point was about OSes, not applications, and the problems of having OS makers also make popular applications; it's anti-competitive. For a similar situation, look at cars: if you buy a Ford Taurus, for example, you can't just swap in parts from other cars. If your starter breaks, you have to buy a Ford-brand starter that's made specially for that year and model. The only commonality is that Ford will frequently use the same component on multiple models and years, but that's not a given, and it's rare that they'll share a component with other carmakers (though you do see it when makers share ownership and co-develop cars, like with Ford/Mazda, or if they share a supplier). People don't complain too much about this though because cars are pretty reliable and the aftermarket frequently makes identical parts or remanufactured parts for popular car models. But what if one company owned 95% of the roads, and made its own cars which worked well on those roads, and made it really hard for other carmakers' cars to work on those roads? That's basically the situation we have now. How's your vaunted standardization industry working out there? It's not, not at all, and it hasn't for my entire lifetime. Quoting:What's the tendency these days? HTML5 + Javascript + CSS3. Exactly what you're asking for: Standardized stuff which works on different OS'es on different browsers Wake me when high-performance games, high-end engineering applications, low-latency music applications, etc. work inside a browser. Putting stuff inside a browser works OK for some low-performance stuff, but that's it. If it requires serious performance, or even just 2 or 3-button mouse operation, it fails (I've never seen a web application that uses two buttons; the right button is reserved for the browser). |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!