Import & Export OVF Files: Move VMs Between Hosts

In my current day job, I’m often asked about using PowerCLI to perform a number of tasks in a vCenter cluster. In this post, I’ll share how I learned how to an import OVF file in VMware.

This is a story about a recent request for assistance from a colleague who needed to export a custom monitoring appliance template to a new vCenter cluster that was being built. My colleague was under a time constraint and did not have the necessary access to the template.

If you don’t already, be sure to download the PowerCLI module via Install-Module -Name PowerCLI

Connecting to vCenter

Never wanting to miss a chance to use PowerShell or PowerCLI, I jumped in head first to help. I gathered the necessary information from my colleague, and began connecting to the cluster:

PS6> Connect-VIServer -Server vcenter.mydomain.local -Credential (Get-Credential)

This takes just a moment to complete. Once you’ve connected, you need to know what verbs to use. You can do this using the Get-Command -Module PowerCLI cmdlet.

There are two cmdlets that stand out:

• Export-VApp
• Import-VApp

Both of these cmdlets appear to be exactly what you need. But first, since this is a learning experience for me and maybe you, I’ll educate myself a little more on the proper use for each.

Exporting VMs to an OVF File

The Export-VApp cmdlet will export the powered off VM as an OVF to the current directory you session is in by default if you do not specify a path.

I already have a path in mind so I’m going to be using the C:\Exported-OVF directory but yours may vary. Knowing this, you can then run Export-VApp against the VM template specifying the destination folder.

PS6> Export-VApp -VM 'My_VM_Template' -Destination 'C:\Exported-OVF\'

But there’s an issue. You cannot export a running VM to an OVF. No worries, this is a quick fix. Modify your code a little more and be sure to first shut down the VM using the Shutdown-VMGuest cmdlet.

PS6> Shutdown-VMGuest -VM 'My_VM_Template'

With the template appliance now offline, resume running the Export-VApp cmdlet attempted earlier. This process will take a few minutes, and wasn’t a very large appliance to begin with.

When complete, you should have an appliance ready to be deployed into another vCenter environment. Or do you?

Importing OVF Files

You should now have a file sitting on your local file system. It’s fine to import it. To do so, you’ll need to query the datastore to import it into along with the VM host. You can then use both objects to pass to the Import-Vapp cmdlet to import it.

PS6> $myDatastore = Get-Datastore -Name "MyDatastore1"
PS6> $vmHost = Get-VMHost -Name "MyHost"
PS6> $vmHost | Import-vApp -Source 'C:\Exported-OVF\My_VM_Template\My_VM_Template.ovf' -Datastore $myDatastore -Force

But wait! This doesn’t work. In my instance, this failed because I didn’t notice that I was actually connecting to another vCenter cluster.

Something happened when I began to import the previously exported VM appliance. A sea of red error messages.

I read the error message, and sure enough, the host is not a part of a vCenter cluster and therefore does not have proper licensing to complete the import using PowerCLI. This is a limitation that VMware enforces.

No worries, I could still connect to the web interface of the host and manually import using the HTML5 interface. The wizard walks you through each step, give the imported appliance a name, choose the OVF, datastore, deployment type (thick or thin provisioned), and verify the configuration. After that, select Finish and the import begins.

While the previous import attempt would work great with a vCenter cluster, it was simply not going to work in this situation. This took a little longer than expected but was straightforward. You can read more about the process here.

In the end, the import was a success, and my colleague met their deadline.

Summary

Until this exercise, I was not aware that not all PowerCLI cmdlets were available in all situations. However, Both of us learned a new skill and, while experiencing some unforeseen adversity, we still accomplished the task at hand.

Too often we rush through IT projects looking for the ‘quick’ fix. Watch your speed, take another minute or two to ask questions, step back and understand the problem you are trying to solve. You may find you’ll learn something new.