By now, the benefits of virtualizing applications are clear, but the goal of 100% virtualization remains elusive.
One reason is that some independent software vendors (ISVs) don't support their server-based applications -- databases, telecom apps, healthcare programs, etc. -- on virtual servers. Known as ISV stall, this problem causes headaches for IT staffers and reduces the server consolidation, management and business continuity benefits that come from virtualizing applications. And as virtual machines (VMs) become more common, the problem of ISV stall just gets worse.
"Everything's VM, VM, VM," said Adam Ferrero, the executive director of network services at Temple University in Philadelphia. "All the vendors that aren't moving along in this area are going to be pressured more and more. Otherwise they're going to lose out on business."
The challenges of virtualizing applications
When ISV stall prevents application virtualization, it presents some unappealing options, said Rick Vanover, an IT infrastructure manager. If an organization needs to use an application immediately, one option is to buy a new server to run the software -- but that costs a lot of money. Another option is for an application to run on old hardware, but this route can create performance problems. There are ways to successfully approach the problem of ISV stall, but it's an uphill battle.
Naturally, when organizations confront trouble virtualizing applications, they turn to the relevant ISVs for support. That can be a frustrating experience, especially with legacy applications in vertical industries, IT professionals said.
Sometimes an ISV's sales staff, support staff and support documentation provide three different answers on whether an application works in a virtual environment, Vanover said.
"You don't even know who to ask sometimes," he said.
What's so wrong about virtualizing applications?
When the Arlington Free Clinic moved to a new facility, the organization purchased and virtualized a new server and set it up as a host for its legacy pharmacy software. The organization ran into problems trying to update the software and went to the ISV.
"Finally they came back to us and said, 'We can't do this because you have a virtual server, and we need you to not have a virtual server,'" Miller said. "And we were like, 'Yeah, that's not going to happen.'"
The situation remains unresolved; the clinic is working with the ISV to update the software on a physical server and then migrate it back to the virtual server, Miller said.
ISV stall often happens in the healthcare industry, said Robert McShinsky, a senior systems engineer at Dartmouth-Hitchcock Medical Center in Lebanon, N.H.
"In the medical field, some of the larger companies are the ones putting up the biggest resistance," McShinsky said.
Some healthcare IT vendors bundle their software with more hardware than is needed and sell it at a huge markup, which makes it difficult -- if not impossible -- to virtualize applications, he said. Other ISVs just say they don't support virtual applications because they haven't tried virtualizing them, and some cite Food and Drug Administration regulations, which regulate the hardware platforms for patient-facing applications, he said.
"They don't seem right, but that's the way it is," he added.
Relationships among vendors can also determine whether certain virtual applications are supported. At Temple, products from Crossbeam Systems Inc., Check Point Software Technologies and IBM power the company's firewall. Support is never an issue because the companies work well together, Ferrero said.
"They don't do the finger-pointing thing," he said.
But on the server side of the university, ISV stall reared its head. Admins tried to install VMware Tools in virtual appliances with some applications, and one of the ISVs wouldn't support it.
"If the partnership isn't good, you're stuck," Ferrero said.
Oracle Corp. is a prime offender. The database and enterprise applications giant has tried to make inroads in virtualization with its own Oracle VM technology and has restrictive licensing and support policies for running its applications on VMware, the server virtualization market leader.
How to get support for virtual applications
Despite the headaches of ISV stall, there are ways to work with vendors that won't support virtual applications.
The most common -- though not ideal -- solution is that an ISV agrees to fix problems with its application in a virtual environment if the customer can replicate these problems on a physical server. This process can be time-consuming and annoying, especially when an IT administrator knows the problem doesn't originate from a virtual server.
In such cases, Vanover offers to allocate more memory, CPU and other resources to the virtual server to show that it is not the root of the problem. This "red-carpet treatment" can get ISVs to open their eyes, he said.
And sometimes Dartmouth-Hitchcock works with an ISV to put its unsupported application in a virtual environment. If it works -- or if Dartmouth Hitchcock and the vendor can eventually get it to work -- the hospital will offer to be a case study for the vendor.
"We still run into many vendors that are not very experienced with virtualization," McShinsky said.