Virtualization Daily

SearchOpenSource.com is running an article titled “Virtual appliances emerge as OS distribution mechanism” that’s talking about RedHat and Sun pushing virtual appliance as the distribution mechanism for their OS.

In a twist, last month, Red Hat Inc. and VMware Inc. partnered to distribute a RHEL5/VMware Server bundle as a virtual appliance through the VMware Virtual Appliance Marketplace. Sun Microsystems Inc. is also distributing OpenSolaris as a virtual appliance.

VMware, Red Hat and other vendors would have you think the future of operating system distribution lies within a virtual appliance, but reality isn’t as cut and dried as they’d have you believe.

They seem to be wanting to make this controversial which is a little odd. All this really is, is just another option for getting the OS. I suspect neither Sun or RedHat are even considering the idea of using virtual appliances as the sole distribution mechanism for their OSes.

The article also goes on to make a bunch of suspect claims from Peter Christy about the security of virtual appliances.

“The problem with virtual appliances is they really do not address functionality upgrades or system vulnerability,” like a crippling buffer overflow, Christy said. “It’s a frightening world we live in, and when that kind of problem is discovered, it creates a real urgency to get a patch from the vendor.”

This is absolute nonsense, a well crafted and supported virtual appliance will absolutely deal with security issues and updates like this. That’s actually one of the big benefits of getting an application as an appliance, the OS can be minimized so many of the risky bits can simply be stripped out by the appliance vendor and their security efforts can be 100% focused on the things they really need. If you deploy an application on a raw install of RedHat or Solaris, unless you do a lot of work, you’re guaranteed to have a large amount of extra surface area to deal with. More surface area simply means more potential attack vectors and a less secure application.

Scott Crenshaw from RedHat is a little more clueful.

“When [IT managers] have a problem, the traditional model requires them to isolate a problem, characterize it and then get help from their support provider,” Crenshaw said. “By having a guest OS integrated with the application, it is much easier to test and prevent those security vulnerabilities to begin with.”

And then more non-sense.

But there is a small price end users do have to pay for the convenience of an appliance — the size of the package, said Hyperic’s Soltero. For example, Hyperic bundles are usually about 80 MB to 100 MB in size. Creating an appliance complete with an underlying OS would increase the size of the bundle by a factor of four to five, (i.e., 320 MB to 500 MB).

“For a downloadable product, an appliance is a pretty big bundle,” said Soltero. “It’s a horse race between how long it can take to download the appliance, and how long it takes to just download the bits.”

It’s true that an appliance will be larger than shipping the raw app, but the size bloat relative to the gains in productivity and convenience is a no brainer as far as I’m concerned. Downloading software is a background process, installing, configuring and managing that software on an ongoing basis requires attention from the user, lot’s of attention. Virtual appliances trade a little painless download time, for a reduction in pain while deploying and managing the software. That sound like a good thing to me.