This post is also available in: Italian

Reading Time: 4 minutes

When I explain the advantages of a virtual infrastructure, I usually add the virtual appliances (VA) as a good example of a plus that you can get. Similar to usual appliances, they can save your time in installation and configuration tasks… and in a virtual environment they can also same time in deployment (and sometime also money). There are several other pros described on What are the Benefits of Deploying Virtual Appliances?

But they may have also some possible disadvantages…

VA patching

One possible disadvantage of VA could be in security aspects: how do you handle the patching and the updates? VUM can handle VA patching, but does not apply to all VA. Due to the nature of an appliance you may not want to fix them manually, also if most of them are simple Linux distributions… but what could be happen if you upgrade some packages? The appliance will work fine again?

Maish has written an interesting post about this consideration (Should You Patch the vCenter Server Virtual Appliance?) and although it is focused on the VCSA, it could also been applied to other VA. In my opinion an appliance must be managed as an entire appliance and not as a guest OS: so upgrade and patches must be applied using specific appliance features (or, if supported, using VUM).

VA standard?

The absence of a common template for all the VA give, of course a lot of flexibility, but also a lot of different implementation, using different Linux distributions (also VMware sometimes use CentOS, sometime SuSE, and not always the same distribution number).

The absence of a standard templates means also that you may have bad example of VA, with several un-necessary servers activated of a lot of packages installed. In some cases also default configurations or bad configurations with possible security risks. In some case there are still a lot of really OLD distributions (like CentOS 5.1) that is again a mess in security aspects.

On some VA the VMware tools are not installed at all and this is a real bad example on how design a VA: you loose some useful feature, like the correct power management of the VM (guest shutdown and restart).

There could be a solution? Actually there are some good distributions that can be used as a good standard template for VA… but who can force everybody to use one of them? Maybe VMware, but why?

There is also a nice solutions from SuSE (the SuSE Studio enviroment) that may possible build appliances (physical or virtual) with a nice IDE… this could be the right directions… Maybe if VMware acquire this asset, then it can use internally for their virtual appliances, but also as an external service to permit a new generation of VA with a good standard core.

VA resource consumption

A VA is still a VM… if well designed will use less resources, if is bad designed (or simple requires several resource) it will consume host resources. Of course you can use resource pools (in VMware vSphere) to manage at least CPU and memory, and SIOC and NIOC to try to prioritize disk and network I/O. But still you have to consider it. Also disk space may have some (big) impact: is some cases thin provisioning could help, but in this way you can have other issues (when disks will grow)…

And remember also the VA consume also your vRAM entitlement!


Also the absence of a common standard make some VM optimization not applicable (or not efficiently) on VA: for example the TSP wil not work well on them.

So the idea of a management cluster for vCenter Server and other management VM and VA seems not so strange… But not all the VA could stay in the management, some must stay on each host (like, for example, some vShield components, or the AppSpeed probe)… So, again, you must consider it and design your cluster resources also for the VA.

VA sprawl

Using VA it’s so easy that you have, is few time, a big sprawl of them. Considering the absence of a standard and the resource consumption this may have several impacts on your environments.

The absence of a standard mean several type of Linux distributions (or also other guest OS), with different versions, with different patch level, also with different architecture (some VA are 32 bit, some 64 bit). This could make unuseful the TSP memory feature of VMware, or uneffective the deduplication on storage side.

VA security

The patching aspect could be a pain, as described previously. But another big pain (from a security point of view) is the number of default services enable on some VA. Sometimes this just means resource wasting, but sometimes security risks.

And there is another aspect to consider: is some VA there are quite old Linux distribution (still some CentOS 5.2, for example).