Brian Bakstran, VP of Product Marketing at our parent company, CA, recently blogged about a study from Network Instruments which talks about how 59% of IT organizations “lack the experience to manage virtualized environments effectively.”

Combined with the idea that by 2012, 80% of all new servers will be virtual ones, and you start to get this sinking feeling that the entire IT industry knows where it’s going, but hasn’t really thought about what it needs to do once it gets there… sort of like sitting in the first four rows at Sea World, all excited to see Shamu, but forgetting to pack a poncho.

And so vendors like us and our parent company offer that visibility. (In the case of CA, for right now, we’re offering it in spades, with the NetQoS stuff [PDF] and the e-Health stuff and CA Virtualization Management.) 

The main concern that the lack of visibility presents to enterprise IT shops is the idea that mission critical applications that performed fine before virtualization may perform poorly when virtualized, and the IT shop will have no way of being proactive in finding performance problems, nor will they have the tools they need to quickly find the root cause of the problem. 

And visibility is necessary even before virtualization to compare performance to the non-virtualized baseline.  There are some applications that simply will always perform poorly in virtualization, and the sooner those applications are discovered, the better.  Knowing what does and does not work in virtualized environments gives you options – you can replace the app, run the app on a dedicated server, or even recode the app to work better in virtualized environments.  But without visibility, you have no options.

Between the reduction in energy consumption and the better utilization of existing servers, the benefits of virtualization are worth the risk, but there’s nothing that says that you can’t bring in everything you can to get visibility into your virtualized servers and mitigate the risk. 

Anandtech has an interesting article out about how it might be time to move forward on standardizing the x86 instruction set – both Intel and AMD have had proprietary instructions included in their CPUs. On the desktop, these proprietary instructions aren’t annoying – in the worst case scenario, a program would take advantage of a “shortcut” on one processor that wasn’t available on another – but what has changed for IT users is that increasingly, x86 chips are being emulated in virtualization, which increases hardware requirements and slows systems down – cutting the benefits which have traditionally driven virtualization.

“Much worse is that this unstandarized x86 extention mess has made it a lot harder for datacenters to make the step towards a really dynamic environment where you can load balance VMs and thus move applications from one server to another on the fly. It is impossible to move (vmotion, live migrate) a VM from Intel to AMD servers, from newer to (some) older ones, and you need to fiddle with CPU masks in some situations just to make it work (and read complex tech documents).”

One of the more interesting riddles about the IT industry and computer development in general is the idea of standardization.

Innovation often occurs due to non-standard protocols and unique innovations. Some open source projects are forked and become a jumbled mess of programmers working at cross-purposes; but others are forked and create new innovations that merge their way back into the main stream of program development, and become a new standard.

And even though sometimes it seems like every vendor has a new way of doing the same old thing, the competition between technologies gives motivation and ability for improvement.

On the other hand, it can also get in the way of doing stuff you really want to do! Windows has become a “de facto” standard for operating systems – and even among Linux, Ubuntu is leading as a clear desktop standard. The entire internet was built on TCP/IP – and it is indeed ONE internet, not a collection of “data services,” like AOL, CompuServe, and Prodigy; nor is it a large collection of BBSes.

Standardization leads to efficiency – but competition can lead to innovation. Multiple solutions spring up to a problem, and the best (or surviving) one becomes a standard which is then made more efficient, which opens up new solutions to new problems, and the cycle repeats.

Kinda like the Hegelian dialectical method, if you don’t think about it too hard.

Now, if all the computer technology in the world was developed by one company – standards first, innovation second – computer technology would stagnate. Yet, still, before “standards,” interoperability and integration provides a middle ground that allows for better technology to come onto the field without overly burdening the end-user with tons of configuration problems – which is why it’s such a high priority when choosing among enterprise networking vendors.

As Halloween approaches, I’ve got a bit of a horror story to keep you up at night. 

There’s an interesting quote that’s somewhat appropriate now.  Well – song lyrics anyway.  “Did you feel you were tricked / by the future you picked?” Which, I’m told, are part of a Peter Gabriel tune for a Pixar movie, but which I only came across when reading speculative fiction about quantum AI computers running 419 scams.

The thing about the future is that by the time it gets here, it’s already the present. Wait, I’m sounding like Criswell there… what I mean to say is that only a couple years ago, the big story in technology was how IT departments were becoming centralized due to advances in virtualization technology that cut down on hardware requirements and power consumption.  Now the next level is cloud computing; an idea, fundamentally, that you can centralize data centers even further by centralizing them with the data centers for other companies via a third-party provider. 

Taken to an extreme, it’s easy to think of a day when even these cloud computing centers become even further consolidated – perhaps one on each inhabited continent.  “A world market for maybe five computers” indeed…

Except, it’s not quite that easy.  The transition from in-house architecture to cloud computing resources is just about as difficult as the transition from real servers to consolidated virtual ones, and the big problem is ensuring network performance – that data gets where it needs to go quickly.  

Much as the server consolidation/virtualization problem was helped with better virtualization technologies and advances in WAN optimization, the current rush in IT tool development is in the cloud computing area (not that we still don’t have a-ways to go with virtualization and consolidation).  And some of these cloud-computing tools are starting to appear – for example, self-managing environments…

One of the newest approaches is the concept of the "dynamic infrastructure." Rather than a simple collection of humming boxes or cards designed to push data this way or that, the dynamic infrastructure brings together virtual networking, automation and resource management with tools like application management, security and policy management to create a self-managing environment that can react to changes in workloads and other needs with minimal human interference.

Lori MacVittie, technical marketing management for application services at F5 Networks is one of the prime movers of the concept, which she says will be the inevitable result of the transition to the cloud. 

"When the entire data center is founded on a dynamic infrastructure, the infrastructure can react itself to changing network and application conditions and needs," she says. "When the entire ecosystem is sharing status and information about performance, every component can adjust itself dynamically to what’s needed now to improve performance or maintain availability. And it happens automatically, based on the specific needs of the business and IT."

Virtualization has underscored the need for performance management; back when everything was run on actual servers, you could almost always fix a problem by finding out where the bottleneck lied and increasing the amount of stuff.  Not always, but almost always.  But with virtualization, you’re essentially managing an interconnected ecosystem of stuff and… well, stuff that’s not stuff.  “Unstuff,” to borrow a bit of NewSpeak. 

And this management is so complex that it has increased the demand for network engineers, yes, but it’s also increased the demand for software to come along and replace the more tedious tasks of network engineers, automating the processes where possible.

But what if there is no upper limit?  What if self-managed cloud computing software is exactly that – with computers calculating exactly what needs to be done to preserve performance and then automatically fix it? 

And that network monitoring software…. WAS ME THE WHOLE TIME!!!!!

AAAAAAAAAHHHHH!!!! 

In this video (part two of two), Jim Metzler looks back at some prediction he made at the beginning of the year, and how they're shaping up to reality in this retrospective interview with Jordan Weiss.

In this video (part one of two), Jim Metzler looks back at some prediction he made at the beginning of the year, and how they're shaping up to reality in this retrospective interview with Jordan Weiss.

Virtualization is a good news/bad news technology. The good news is that you can consolidate your servers onto one piece of hardware, but the bad news is that you lose visibility into the overall network. Jim Metzler, of Ashton, Metzler & Associates, and Ben Erwin of NetQoS discuss how to preserve visibility into application delivery in this short Whiteboard Series Video

By Patrick Ancipink

As an individual representing a vendor that has traditionally viewed IT through the network lens, attending VMworld last week I sometimes felt a bit like a Trekkie at a sports bar. Not entirely unwelcome, but not exactly the crowd I usually run with, either.

While virtualization initiatives seem to be securely in the hands of the server and data center teams in most IT organizations, we are certainly seeing an uptick in the involvement and burden of the network team.

A year ago, a common virtualization discussion between server admin and a network engineer might have sounded like this:

Server admin: “We’re provisioning a new rack of blades and VMs so I need some cables and IP addresses.”

Network engineer: “Well how are you going to configure the VLANs for that?”

Server admin: “Don’t worry about it.  This is a big cost saving initiative. I’ll just configure the vswitch myself.”

While this type of thing still happens, our customers tell us that the network teams are increasingly being brought into the dialogue as enterprises move beyond virtualizing the low hanging fruit—e.g., file and print services, anti-virus detection, Exchange, Web platforms, etc.  Aggressive virtualization initiatives with goals that sound like “70% virtualized by the end of the year” require more middle-tier  “business” apps and complex components to become virtualized and the best practices and visibility expected in the physical world have to translate to the virtual realm.

This was evident at the VMworld vendor exhibition where “monitoring” and “visibility” messaging was present at vendor booths large and small. NetQoS even had a chance to present in the Cisco booth where a mixed audience of server and network pros all found value in understanding what data collection and analytics from application response time, Netflow and device statistics could do to get a handle on the hybrid infrastructure most of us are dealing with.

There was a lot of innovative and compelling virtualization management technology there at the show, but approaches that support only virtualized environments or only a subset of applications are not going to be adequate. This story has played out in numerous technology waves dating back to the client/server era (and probably even before).  You need to get visibility and control in the new realm but that doesn’t mean the old one goes away completely.

While higher levels of server virtualization are bringing the importance of the network perspective to the forefront, desktop virtualization will make network performance even more critical. We chatted with a bunch of vendors like Wanova that are trying to make the location of the virtualized desktop irrelevant, permitting more desktops to become virtualized even amidst mobility and roaming end users.

But keeping remote users secure and up-to-date is not the same as assuring performance of mission critical apps in real time. You need to understand the performance of the various virtualization scenarios—server and desktop, dedicated resource pools, Vmotion—and the best way to do that is to understand what acceptable performance is in the physical realm and know where latency exists. With that knowledge, you can track the performance and behavioral changes when you virtualize the infrastructure and endpoints.

Interop in full swing in Vegas; and already both my work e-mail and my personal e-mail are filled with press releases, press-releases disguised as e-mail, and in one odd case, ninja disguised as press-release. 

If you’re asking how a ninja can get into my e-mail, you don’t know much about ninjas.  Ninjas can get anywhere.

Still, I figure I might as well check in to see what’s going on at Interop.  For example, Jim Metzler just put out a post on his blog on his Interop first impressions:

I stepped out of the hotel I saw something that I have never seen before in Vegas – there was absolutely no line for a taxi. Every other time I have come to Vegas there has been a long line, often lasting a half hour or more. My fear was that the Interop show would be as empty as the taxi line. It is not. It appears to be down some from last year, but there still is a lot of energy here...

…Then we got to the Q&A and the gap between what is being promoted by vendors and analysts and what is being practiced by IT organizations became painfully clear. For example, vendors and analysts have been talking for years about what IT organizations need to do to meet their internal SLAs. When asked, hardly any of the participants stated that they offer internal SLAs. That did not surprise me. Even more interesting is that vendors and analysts have also been talking for years about the need for visibility into applications. When asked, relatively few of the participants stated that they had that kind of view even though most of them had some kind of APM tool. That did surprise me.

Meanwhile, Network Instruments polled the Interop attendees on virtualization deployment, and released the results via a press release on their website – pessimistic reading if you’re keeping track of virtualization in the enterprise.  Some findings:

• 27 percent identified a lack of visibility and tools as the largest troubleshooting challenge in virtual environments.  Other troubleshooting concerns include a lack of training on virtual infrastructure (26 percent) followed by an inability to secure infrastructure (21 percent).


• 55 percent report experiencing more problems than pluses with virtualization, while 45 percent thought the technology’s benefits outweighed any problems.


• 47 percent report roll-out costs were too high.

That’s not great news for virtualization deployments, and goes to show you that visibility is extremely important in virtual environments in order to keep costs down and make sure you’re going to receive benefits before large deployments.

In yesterday’s post, we talked about the problem with input/output delay on virtualized desktops, though to be fair, we only really talked about one type of virtualized desktop solution. That is, we talked about the challenges associated with server-side desktop virtualization, where the OS runs on the server and the end-user essentially sits at the end of a dumb terminal.

There is another method, called client-side desktop virtualization where the entire OS is downloaded over the network onto the hard drive (or RAM disc) of the client computer, where input and output are localized to the client computer, which means that you don’t get any added latency to the input and output.

However, this type of setup has its own problems. First, downloading an entire OS at once is likely to create bursts of traffic and spikes of high Internet activity. Specifically, what do you think is going to happen when everybody turns on the computer and logs in at 8:30? Or logs out at 5?

This method might be more applicable for work-from-home telecommuters, who can access the “work computer” from home during work hours, and log-off to use the “family computer” at night. There you run into a last-mile problem – will broadband be sufficient to download the OS each morning, and – more importantly, considering most personal broadband is asynchronous – be able to upload the OS each evening?

Now, none of these criticisms of virtualization – either form – should in any way constitute a criticism of the technology. We hope that someday, we’ll be able to realize the full benefits of virtualized desktops without network performance degradation. But do consider the impact of virtualized desktops on your network when considering whether they’re feasible.

Network World’s Jim Duffy’s latest article, “WAN critical to virtualization’s payoff” has me in knots. 

It’s well known that by virtualizing servers, you can consolidate them more easily in a single data center; but in order to maintain performance, you need high performing, low-latency WAN connections.  We’ve written about this before, and it’s only more relevant with VMWare announcing on Feb. 3^rd that they are providing an Open Source Virtual Desktop client.

But Duffy’s article seems to be focusing on the idea of virtualizing the desktop on backend servers, rather than virtualizing backend servers.  The rest of the article denotes all the challenges of doing so.

Now, there are benefits to virtualizing desktops – key among them the idea that software problems can simply be solved by replacing a user’s virtual desktop with a separate virtual desktop – instead of dispatching someone from IT down to the user’s physical location.  This is a laudable goal.

However, virtual desktops are prone to poor performance over the WAN, because, like video or VoIP, it’s an interactive, latency-sensitive service.  Specifically, let’s look at mouse input.

When you operate the mouse on your computer – feel free to do so right now, (unless you’re reading this on an iPhone, in which case, carry on being smug) -  it may seem like an instantaneous reaction.  You move and the mouse moves with you.  This is not true.  It is an illusion. The output, however, comes so quickly after the input that the human body can’t tell the difference.  This is because the input has to go from the mouse to the computer’s IO port (usually USB), get processed by the CPU, and painted on the screen by the GPU out to the monitor. 

However, in a virtualized desktop, the input goes through the user’s IO port, gets processed by the CPU, and then pumped out to the Ethernet connection to the WAN, is processed by the CPU on the server, is output back over the WAN, which is then processed by the CPU of the user and painted onto the screen via the GPU. 

Point is, you’re adding an entire round trip across the WAN to the process.  So even if there’s no congestion, if the round-trip latency due to distance between the user and the data center is 100ms, you’re adding a tenth-of-a-second delay.  That will probably be noticeable.  And there are other sources of delay on the WAN.

This does not even take into consideration the data involved in pushing video data out to the remote desktop.  Long story short, virtualized desktops are probably a good idea on the low-latency connections that you’d find on the LAN, but trying to operate them over the WAN probably won’t work that well.  Is the benefit of virtualizing the desktop (or of consolidating virtual desktops) so great that you’re willing to suffer through poor end-user experience?

Which means that the premise of the entire article frustrates me.  Yes, it’s obvious that you need to have low-latency performance with your WAN to provide for virtualization – and good performance is a good thing; but at some point you are going to hit the law of diminishing returns.  If you’ve been monitoring your network performance and have the capacity to try to serve remote users virtual desktops in under 150ms, feel free to give it a try, but ultimately, will virtualizing the desktop over the WAN provide the best benefits as a whole? 

What may bear more fruit is to have applications virtualized and sent over the WAN onto existing, local desktops, much like XWindows apps back-in-the-day.