I’m torn when it comes to virtual appliances. I love them because they make a lot of installations absolutely brainless. I hate them because the people that create them make assumptions that are ridiculous and unsupportable. Here’s the three ways I hate them the most:
1. There’s no good way to back them up.
For organizations that haven’t gone the “whole VM” backup route there are very limited choices for backing these things up. Sometimes the virtual appliance has some method to export the configurations and data, but often not. And when there is a method it’s usually a web interface that cannot be automated.
What I want: virtual appliances should be able to export their configuration and data on a automated, scheduled basis, to a Windows share and via SCP. Since nearly all virtual appliances are Linux-based this shouldn’t be a big deal, since Samba is readily available, and SCP is a staple of OpenSSH. Both options would be nice but if you have to pick one pick the Windows share, since even Linux folks can run Samba, and it’s probably easier to script on the appliance side (you can write directly to it, unlike SCP where you would have to have a temporary holding spot). Scheduling isn’t an issue, either, since Linux has cron & at.
2. They want to DHCP.
My data center doesn’t use DHCP. Many places don’t. A VM that assumes it will be able to DHCP is a giant pain. Some do it right and allow you to configure a static IP after the boot process has completed, via the command line or console. Some do it poorly and only permit you to change the IP from a web interface. How exactly do I get to the web interface if the VM doesn’t have an IP? I end up having to run a DHCP server on an internal dvSwitch portgroup just to configure the VM.
What I want: virtual appliances should always allow people to easily configure static networking addresses from the console, for both IPv4 and IPv6. And the IPv6 stack should not be enabled unless it’s specifically configured by a user, either for autoconfiguration or static configurations. It also needs to allow full control of the classic settings, like gateway, address, etc.
3. They are seething pits of evil, security-wise.
Let’s just face it, virtual appliances never get patched. They’re giant security holes, and I’ve had a few of them get hacked when they’ve been on a public-facing network, using vulnerabilities that were patched six years prior. You can’t firewall them to protect them, either, because the holes are in the applications (which you have to grant access to). Updates are never released in a timely fashion, and there’s usually no working way to update the virtual appliance. So, in my opinion, as of this writing, you cannot use any virtual appliances in any public-facing manner.
What I want: virtual appliances should be updated no less than quarterly so they contain the latest patches. People who create virtual appliances should use the latest patch levels, and scan their products prior to release with Nessus in order to check for vulnerabilities. It would be nice if you allowed end users to update the appliance, after allowing them to export the configurations & data (see complaint #1 above). Full host-based firewalls should be enabled on all virtual appliances, for IPv4 and IPv6, for ingress and egress traffic, and nothing should be permitted in or out unless it’s absolutely necessary. Last, an appliance should have no software installed on it that isn’t 100% necessary for the function of the appliance, or support. Not wasting my disk space is just polite, plus the less software you install the less of a security profile I have to worry about.
So, in short, if you’re a virtual appliance creator I wish you’d get it together! I’d love to see many products shipped as appliances, but I cannot run them until you fix some of these operational issues.
Comments on this entry are closed.
From @eableson – “Four: no support for non-QWERTY keyboards. kbd =~ 1.5Mb. Please?”
I’ll add a fourth for you… Vendors who distribute a “virtual appliance” as a OVF and an ISO with their windows application but you get to provide the Windows image to go with it.
Five: No documentation. I have yet to see a production Virtual Appliance that has a documented build, a list of users, a maintenance/update guide, or even a list of open/required ports. Strangely most testing Virtual Appliances I have worked with are very well documented.
As far as I am concerned they are black boxes full of “magic” and have no place on a production network.
@ Ben: I can agree with the comment about lack of documentation.
Why would you run a Virtual Appliance without checking it for patches and open ports on a public facing network? I don’t have faith in any VA that its patched and properly secured, even on an internal test network. I only use someone elses Virtual Appliance for testing.
If you want a properly configured VA, create it yourself. You control the build process that way, and include/exclude anything you want. I have to qualify my Appliances, so the process of building one is worth the time.
Another option is to create a base Virtual Appliance, qualify the Appliance, and use it for all production Appliances for future builds.
When I run a VA, I tend to back up the configuration files after building it, and then create a known good back up of the Appliance, so I can go back to it when/if I have to. I also routinely shut down the Appliance, create a new backup, and restart the Appliance on a regular interval, so that I have a known good working copy.
Disk space is cheaper than my time.
Here’s a few more:
1. Unlicensed content – I’ve found several appliances using RHEL and as they were free that means Red Hat isn’t getting paid but more importantly, if you’re a RHEL shop you’re now violating your licence agreement. (I’d suggest Debian Stable, or Ubuntu Server LTS as sane OS choices)
2. Filled with crap – Why do people install a default (desktop) OS install, the VM tools (if you’re lucky, several didn’t) their software and call it done. This creates compressed appliance images well into the gigabytes, when all that’s needed is <500Mb (Again, Debian Stable, or Ubuntu Server LTS, both have OK size but can be shrunk down further)
3. Secret root password – I've had a bunch where they keep the root password secret, out of interest I broke a few and it's usually trivial, or outright guessable
4. Running crap – this really only applies to appliances that fail my #2 above. The correct way to block bad traffic is not to run a host firewall, it's to not be running unneeded crap in the first place, use ps and netstat to cut out the crap (yet again a good OS choice helps here)
dhcp isn’t a bad thing, but yes, there should be an easy way to set the IP address if you don’t use dhcp.