Part 6 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

How many of you out there are doing a server virtualization project?

More specifically, how many of you are doing a server virtualization project that you know of? Because often in companies, the server group will start consolidating servers in virtual servers – and neglect to tell the networking group. Worse still, when a problem develops, the network, not virtualization, gets the blame first.

There’s also desktop virtualization. If you haven't heard of that, that's the idea that, well, a user doesn't really need a machine. What they really need is an image and that image can be pulled down across the network to any piece of hardware that they might be operating on at that given period of time.

Because we all know there's this ubiquitous and highly performing network everywhere in the world for this user to access this image, right? And even though that may be a Windows image that has hundreds of megabytes of data, we're just going to zip that right down onto their local hardware of whatever type it is. Doesn't even matter what type because we virtualized it and we're going to run our desktop locally.

While most of the readers of this blog clearly caught the sarcasm in the previous paragraph, to a CIO, that’s a very attractive pitch. I can promise you there's a lot of venture money being put right now behind companies doing desktop virtualization because nobody wants to miss the next VMware from a returns prospective. So, it's coming. Whether it's a good idea or not, in what environments it works well, that's a whole different question.

Some applications are going to perform fine under virtualization. However, there's a whole other class of applications that don't work well in virtualized environments. Virtualization is not like having another server ‑ it's like having part of another server. And that part, depending on the application, may be good or bad.

So, with virtualization, it's going to be very important that you have the ability to compare performance in the virtual environment with the non‑virtual environment. You want to get in there and get a baseline before they do any virtualization so when they come back to you and say “oh, things have gone to Hell in a hand basket”. It must be the network' you can say, 'no, guys, look, nothing changed with the network ‑ here's the response time on the server you were getting before you virtualized, here's the response time you're getting now on the server. That's your problem. Virtualization caused your problem.

You'll be able to understand better what applications work well under virtualization, because tracking server response time before and after virtualization is the ultimate test. If I virtualized an application and server response time with the load stayed the same, that's a good application for virtualization. If I virtualized an application and server response time goes up by a factor of ten with the same load, I didn't get anything for my money, right? That's not a good application to virtualize. I promise you a lot of server folks are not thinking of this and you're going to be the brunt of dealing with the problem when it occurs.

Then, of course, there's servers running out of resources because now it no longer makes sense to look at the server as a single hardware running a single OS.

So, in that case response time's going to drive the ability. In this case server response time is going to be really critical in you helping prove that this is not your problem. And then from there, device statistics are going to be important as you virtualize servers.