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.