Virtualization? Give me a better OS instead!
Do we really need to go that deep into virtualization? I may sound dumb to try to reason against something that everybody is embracing, but that’s usually what I like to do about hypes 
OK, you’ll probably throw a lot of advantages of virtualization on me. And I agree that most of them are true. I was reading that some companies are being able to increase their hardware processors utilization from 10 to 60% through virtualization. There is also all that high availability stuff from VMotion and other new products that are being released everyday. OK, but…
Let’s go back some years and see how we end up where we are. Imagine that you had to put two new applications in production, A and B. To ensure proper segragation you decide to put both applications on their own servers, X and Y.
Of course, are they are both critical apps, you also build servers Z and V for high availability purposes.
In a few months, people start to complain the servers utilization is too low. They are consuming too much power, rack space, blah blah blah. Ok, then someone gets a nice rabbit from a hat called virtualization. Wow! Now you transform the hardware X and Y into VM servers (or whatever you wanna call it), build separate VMs for A and B and as you VM product has a nice feature of dynamically moving images from a box to another, you don’t need Z and V anymore. Wow! You’ve just saved 50% of servers related cost!
OK, could probably be worried about putting those application in the same “real” box. After all, you decided before that they should be running on different servers, and here they are on the same box! But you look into the problem and notice:
- One virtual server cannot interact with the other
- Problems caused by application A still can’t cause problems on application B server
- A security breach on virtual server A will not affect virtual server B
- Problems caused by application A still can’t cause problems on application B server
- A security breach on virtual server A will not affect virtual server B
Ok, everything is still good and you go to bed happy with the new solution.
No, people are greedy!
Seriously, now that we have all those servers on the same box, why can’t we have a little more control over their access to resources available? Like, if one server is not using all memory allocated to it, why can’t the other one use that when it needs? Same for processing power, storage? But in order to do that the Hypervisor would need a better view into what is happening into those black boxes…why not make them aware of the VM environment? Build APIs that allow communication between the guest OSes and the hypervisor? Nice! Now things are starting to get really advanced!
But where is that segregation that was mentioned before? Won’t all this interaction between the HV and the guest OSes reduce the isolation? Of course it will! Some attacks from guest OSes to the HV or to other guest OSes are now possible. Anyway, it’s the price for better management and better resource utilization. Isn’t it?
Yes, it is. We already knew it! Isn’t it the price to put two application on the same REAL box? Let’s see. We want hardware resources to be shared by the applications and something controlling it. One application shouldn’t be affected by the other or access non-authorized resources. And we want high availability too.
Well, please tell me if I’m wrong, but for me these things are just the requirements of a good Operating System with cluster capabilities!
Virtualization guys usually refer to mainframes as a virtualization success case. They are right about it. But on mainframes LPARs (their name for VMs) are usually used to isolate completely different environments, like development and production. It is very common to find several applications running on the same LPAR, being segregated only by the OS and Security Manager (that can be seen as part of the OS). Usually, LPARs are used because organizations can’t afford different hardware for things like, testing, certification and development, whilst on the “new virtualization” world VMs are used to optimize resource utilization. As far as I remember from my Operating System course classes from university, that was the Operating System role.
Are we creating this beast because we couldn’t produce a Operating System that does its job?
It would be nice if there was an OS that could stack apps nicely. Actually, there is – Linux – usually. The problem is more on the app side than anything else. Developers write as though they’re the only ones on the box because that’s been the norm for the last 20 or so years. So really we don’t need a better OS – we need better apps. Sounds easy enough, doesn’t it? The problem is you need to retrain thousands of app developers and re-write millions of applications. That’s no easy task.
Like you said at the end of your blog, the mainframe guys have had this figured out for 40+ years. That was the mainframe though and with 6.5 million+ Windows apps out there we needed an x86 solution. Enter VMware (and now Citrix and Red Hat and Microsoft, etc). Virtualization is becoming the new OS that you are talking about. It’s letting us split things up and manage them better. Like it or not this is the new way things are running and will continue to run. If you don’t think so then why didn’t the mainframe guys just improve their OS to handle the activities instead of running virtual for the past 40 years?
One last point. You state, “Some attacks from guest OSes to the HV or to other guest OSes are now possible.” Uh, not true. Sure there’s the Blue Pill and Red Pill but those have never been proven and actually very major security people and firms have disproven these attacks. Stop spreading FUD on this topic.
October 31, 2008 @ 7:36 am
Good feedback Mike, thank you. However, I want to point out the what is usually segregated into different VMs on mainframes is usually what people still recommend to put on different VM environments too. The general security advice for virtualization is to aggregate similar things but keep things that are too different (like production and development) on different hardware too. So, I think we are still far behind them.
One point that you didn’t mention in your comment (and it would be nice to hear about) is the redundancy brought by virtualization. If you put two apps on the same box you’ll have a single memory manager, scheduler, etc, consuming resources to manage the resource sharing between them. If you use VMs you’ll have that code running on the host OS and on each guest OS; isn’t it a waste of resources?
I also like to say that my post is more focused on a conceptual view of the problem. So, when I talk about the risk of attacks from the guest OSes, this is simply a logical conclusion from the fact that the guest Oses can communicate with the HV. In security every time you have two software components talking to each other there are chances that one can exploit vulnerabilities on the other. We still haven’t seen a case, but I bet we will, and chances increase every time we increase the guest OS environment awareness of its virtual condition and allow it to communicate with the HV. I’m not trying to spread FUD here.
In the real world we can’t just complain that Operating System sucks and buy more hardware. Virtualization is solving a real problem that exists now, you right about it. But there are lots of examples of mistakes that have been done in the past because people built things to deal with effects and not to solve the causes. Whe should be aware that maybe the way that we are using virtualization today is to deal with an effect, and not the cause.
October 31, 2008 @ 8:33 am
Good point on the production versus development side. I’m seeing more and more customer mix the two (I work for VMware). That’s usually not the first thing they do. It takes time for customers to get comfortable and then they start mixing. Probably the one thing I haven’t seen mixed too much is DMZ versus non-DMZ. There’s nothing technical that will prevent it – just a comfort thing that most people haven’t gotten over yet.
As for sharing resources or running it twice that’s really not the case. The vast majority of virtualization solutions out there do direct code execution. This is especially true in the bare-metal hypervisor approach. Yes, there’s a scheduler there but the code isn’t being executed twice and memory isn’t copied twice. Everything goes direct to physical. The hypervisor is just a traffic cop. In the hosted space where you have an underlying host OS you still don’t execute twice or have twice the memory. The VMM (the world the VM runs in) is just another process that the host OS schedules and lets run. Just like apps don’t consume twice the resources the VMs don’t either.
I’ll let you pass on the conceptual risk. Yes, there are pieces of code that connect the guest VM to the process that’s doing the scheduling but all of that’s isolated. I could say conceptually that my Prius could get to 200 MPH. The wheels I know will spin that fast. Whether it can actually get to that speed and stay in one piece is another story. Just because you could conceptually see something doesn’t mean it’s going to happen. Will we ever have a guest to host attack that’s real? Who knows. Only time will tell on that one. In the mean time all I can do is say from the VMware standpoint that the software has passed Common Criteria Evaluation twice (coming up on a 3rd cert soon) and is used by all of the 3 letter acronym US agencies. That speaks pretty highly of the software itself and the security of it. We’ll just have to watch the future.
I don’t think the way we use virtualization today will be the way we use it tomorrow. Most people are using virtualization today for server consolidation. Some are using it for DR. Some are using it for testing. All are using virtualization in a “forward” and “visible” way. That means they use virtualization on purpose. That will go away over the next 3 years. You won’t decide to use virtualization or not. You’ll simply create and run your app and it will just run in a VM because that’s how everything is deployed. You also probably won’t even realize this because you’ll be getting resources from an internal or external “cloud” (I hate that word but use it since people sort of understand the concept). Basically you create an app and deploy it into a container. That container just happens to be a VM instead of a physical host. Anyhow, I could type on for years about how virtualization is going to change. The point is you won’t even be thinking about it 3 years from now just like you don’t think about it when you’re putting an app on a mainframe.
October 31, 2008 @ 9:48 am