I’ve been using vSphere 6.5 for a few weeks and noticed a couple of oddness surrounding OVFs and OVAs. For those who maybe unfamiliar OVF/OVA is packaging format that allows you to easily import and export VMs – and is a recognise format beyond VMware’s boundaries that’s adopted almost universal industry acceptance. An OVA is just a gzip file which contains the OVF file itself (which is merely text descriptor) together with the VMDK’s that make up the VM.
Generally, I’ve found importing OVAs/OVFs is pretty easy and relative reliable – even though you often tussle initially with web-browser security settings and uploading/downloading of files. Sadly, I’ve found the export process can be a bit 50:50 and the resulting OVF generated unusable…
Firstly, we appear to have lost the ability to export to an OVA from the vSphere Web-Client altogether – that’s a disappointment to me because I quite like the simplicity of the simple OVA bundle. It’s not clear to me if this deliberate or an oversight by the vSphere Web-Client development team OR if this hints at some policy of moving away from OVA as companion to OVF.
Secondly, the resulting OVF file that’s exported (there was the appropriate files) gave me an unpleasant error message š
So I decided to give up on the OVF Import/Export functionality of the vSphere Web-Client as broken, and look for an alternative.
If your not comfortable with the ovftool CLI tool there GUI alternatives. For instance the all-new ESXi Web Client (does it have a proper name I should be using?) does have an “export” option on per-VM basis (obviously no support for vApps which are a vCenter construct and requires a DRS cluster to be enabled)
Sadly, when I went to import this exported OVF as test I received the same the similar error messages.
Sigh. Life is really too short for this sort of problems. In the end decided to forget altogether about GUI methods and head of to the CLI for at least exporting VMs into the OVF/OVA format. With the added bonus that unlike the vSphere Web-Client I get the option to use OVA again… The only “troublesome” thing about the command-line OVFtools is it somewhat esoteric syntax. I’ve come across a couple times in my work with VMware. Occasionally, toolsets get developed that seem not only be non-standard – they don’t bear much relationship to tools within VMware.
You can download the latest OVFTOOLs from here:Ā https://my.vmware.com/web/vmware/details?productId=614&downloadGroup=OVFTOOL420Ā and they come in Win32/Win64/Linux/MacOS formats – that’s handy from a scripting point of view because it means what ever the OS the end-user is using the tools are pretty much standard.
The odd thing about OVFTool is how it expresses the username, password, and vCenter/ESX host paths – and the other “odd” thing is getting your head around the naming convention for enumerating objects in the vCenter inventory.
Here’s a sample:
ovftool.exe “vi://administrator@vsphere.local:VMware1!@vcnyc.corp.local:443/New York/vm/Infrastructure/uda30″ “C:\Users\Michelle Laverick\Downloads\uda30.ova”
So thats username:password@vcenterfqdn. This winds up feeling a bit odd considering that PSC (aka SSO) uses a UPN style naming convention for usernames (username@domainname.com) together with the @ sign as an escape character separating the authentication credentials from the name of the server/service your connecting. What’s so bad with good old -server -username -password ?
The next thing to do is to locate your VM or vApp in the inventory – the most import than to remember is there are “hidden” system objects that must be expressed – anyone who has used PowerCLI a bit will know these hidden system objects don’t appear in the UI, but often act as the “root” contain for other objects. So my VM uda30 is located in this path /New York/vm/Infrastructure/uda30 which equates to this location in the UI.
