In Part 1, a quick overview covered some of the basics about running a vSAN Witness Appliance in vCloud Air.

The process isn’t extremely difficult, but there are some considerations to keep in mind.

This post will focus on getting the vSAN Witness Appliance into vCloud Air for deployment.

The vSAN Witness Appliance OVA

This appliance is provided in the Open Virtualization Appliance (OVA) format from VMware. This OVA is a handy-dandy file that includes the vSAN Witness Appliance, as well as some logic to allow an administrator to deploy the appliance in with different characteristics. It also provides the ability to enter the default password for the appliance, enhancing the ability to provide a password which meets an organization’s security requirements.

There are different versions of the Witness Appliance for different builds of vSAN, but are mostly similar. This article will discuss using the vSAN 6.5 Witness Appliance.

The OVA format of the appliance allows for a single file download of the Witness Appliance. While this works very well with vSphere, the vCloud Air interface does not allow OVA appliances to be imported into vCloud Air. Because of this, the vSAN Witness Appliance must be converted to an OVF format. The VMware OVF Tool can be used to convert an OVA to an OVF fairly simply.

For starters, download the vSAN Witness Appliance for your version of vSAN, then download the OVF tool and install it.

The syntax for converting an OVA to OVF in Linux/OS X is:

The vSAN Witness Appliance has now been converted to the OVF format. This consists of multiple vmdk (virtual disk) files, an .ovf file, a .mf (manifest), and a .cert file (to ensure the .ovf maintains an integrity check).

The vSAN Witness Appliance OVF

Importing the OVF and OVA are the same when using vSphere, but remember that vCloud Air doesn’t support importing an OVA. It is also important that some changes need to take place in the .ovf file, which contains the appliance’s settings, before it is a good fit in vCloud Air.

Using a preferred text editor, some changes will need to be made to the .ovf file. The .ovf includes more disks that it actually needs, to meet the needs of the different profiles that an admin could deploy. The appliance has a few sizes, including Tiny, Normal/Medium, and Large. The Tiny size is the only one that does not include any 350GB vmdks. The Medium includes one, and the Large includes three.

Appliance Size Considerations

The appliance size is important to consider, especially since our appliance will be consuming space in vCloud Air. Knowing that I would only be using a minimal vSAN Appliance size for my 2 Node Direct Connected cluster, I could dispense with some of the larger disks.

The first time I attempted to upload the OVF, I ran out of space. Not that I couldn’t buy more space in vCloud Air, but that they don’t really give us that much capacity in Tech Marketing vCloud Air accounts.  Oops.


The space the appliance requires, regardless of which profile it defaults to, will be the entire space the OVF could consume. So the boot vmdk (12GB), the cache disk vmdk (10GB), the tiny data vmdk (15GB), the normal data vmdk (350GB), and the 2 additional large data vmdks (350GB & 350GB) are uploaded. As can be seen in the graphic, I tried to fit 1.5TB worth of an appliance into the last 100GB I have allotted. This is because each profile in the OVF is imported. The tiny profile consumes 27GB, the medium profile consumes 372GB, and the large consumes 1,072GB.

Default Appliance Size

The Witness Appliance profile that the OVF defaults to, is the normal or medium size. This will consume at least 372GB. To get around this requirement, I did a little surgery on the .ovf file using a text editor. Configuration labels can be set to a default with ovf:default=”true”. Notice that the “normal” profile is the default.

Setting the normal as default to false, and tiny as default to true, ensures that the tiny profile will be the one deployed from vCloud Air.


Choose which ever size is best for your environment as the default.

Remember that all of the vmdks are uploaded, regardless of whether they are in the default profile or not.

Removing some disks

To keep the capacity size smaller, because tiny is suitable for my needs, and I’m almost at quota, I removed the three 350GB disk entries in the References and DiskSection section of the .ovf file.

Before: With disk-1, disk-3, disk-4 & each capacity entry of 350

After: With disk-1, disk-3, disk-4 & each capacity entry of 350 removed


*Note, this may not be the proper way, but it worked fine for me. Remember, this was only necessary for me, as I didn’t have the required capacity in my vCloud Air instance.

Uploading the Witness Appliance OVF to vCloud Air

The next step is the actual process of uploading the Witness Appliance OVF to vCloud Air into a catalog that may be deployed from. The upload process can be performed using either the vCloud Air upload UI. The OVF tool is also an option.

The OVF Tool makes things pretty easy once the syntax is correct. The syntax is as follows:

A couple switches have to be used to handle the upload process. This is because our OVF has a EULA that has to be accepted, as well as the fact that the manifest file (.mf) will not match up with the original after the modifications to profile and disk have been made.

Uploading from a windows environment to the SABU Tech Marketing vCloud Air instance was very easy as a result.

*Update & quick note: Do not use the –allowExtraConfig parameter. This will not allow the witnessSwitch to be created.

Logging into vCloud Air, and looking at our catalog, the appliance can be seen.


Those are the basics of how to get a vSAN Witness Appliance into the vCloud Air environment. In Part 3, we’ll go over some of the networking requirements needed between vCloud Air and a site that is running either a 2 Node vSAN cluster or a vSAN Stretched Cluster.