WilliamLam.com

Search Results for: ovftool

How to Deploy an OVF/OVA in the ESXi Shell

by // 54 Comments

I recently answered, what I thought was pretty straight forward question on the VMTN forums about whether it was possible to to deploy an OVA directly onto an ESXi host without leveraging remote tools such as the vSphere Client or the ovftool. The response that I provided was, no it was not possible to deploy an OVF/OVA within the ESXi Shell and recommended the user to take a look at the vSphere Client or the ovftool.

For whatever reason, my brain decided to ponder about this specific question over the weekend (even though I had answered dozen or so questions earlier in the week) and came up an idea that could make this work. As many of you know, I am a big fan of the ovftool and I have written several articles about the tool such as here and here. I wanted to see if I could get the ovftool to run in the ESXi Shell as all the necessary libraries and required packages are all self contained within /usr/lib/vmware-ovftool directory. If this works, it would allow a user to deploy a VM from an OVF or OVA format within the ESXi Shell and would not require a remote system which is great for kickstart deployments or ISO installations. As you probably have guessed, I was able to get this to work 🙂

Disclaimer: This is not officially supported by VMware, please test this in a lab before deploying on production systems.

Before you begin, you will need to get the ovftool installed on an existing Linux system, you can use vMA for your convenience. Next, you will need to use the scp command to copy the entire /usr/lib/vmware-ovftool directory onto an ESXi host. Ensure you place the contents on either a shared or local datastore as the size of the ovftool content is quite large (~119 MB).

In this example, I am scp'ing the ovftool directory to a local VMFS datastore (/vmfs/volumes/datastore1)

scp -r /usr/lib/vmware-ovftool/ root@vesxi50-7:/vmfs/volumes/datastore1

Once you have successfully copied the ovftool directory over to your ESXi host, you will need to make a small tweak to the file located in /vmfs/volumes/datastore1/vmware-ovftool/ovftool (shell script that calls the ovftool binary). You will need to modify the the first line using the vi editor from #!/bin/bash to #!/bin/sh as ESXi does not recognize the bash shell. You are now ready to copy an OVF or OVA to your ESXi host which should also reside within a shared or local datastore.

In this example, I uploaded a SLES OVF to the same datastore which contains the ovftool as seen below from the datastore browser:

Let's go ahead and perform a simple probe operation on the OVF we just uploaded to ensure that ovftool is working as expected. To do so, you just need to specify the full path to the ovftool as well as the full path to either your OVF or OVA file.

Note: The ovftool does take slightly longer to run in the ESXi Shell compared to a regular system with the ovftool installed.

Now that we have confirmed the ovftool is working, let's go ahead and deploy from the OVF image. Even though we are running the ovftool locally in the ESXi Shell, you will still need to specify the credentials to your ESXi host during deployment as ovftool was not designed for this use case.

Note: You must specify both the username and password in the ovftool command line, as the password prompt does not function properly in the ESXi Shell and you will see a looping of  "*" characters on the screen.

If you are familiar with the ovftool, you know you can specify an OVF/OVA from both a local resource as well as remote location such as a web server. Here is another example of deploying an OVF from a remote web server:

We can see that is pretty easy to deploy an OVF or OVA from within the ESXi Shell, but what about unattended installations such as ESXi kickstart? Yep, we can do that too! The easiest way is to compress the vmware-ovftool directory using tar command and then download it remotely using the wget command during the %firstboot stanza. I would also recommend placing your OVF/OVA images on a remote web server as well for centralize management and deployment.

Here is the sample code snippet that can be used in your kickstart:

# download ovftool tar to local storage
wget http://air.primp-industries.com/vmware-ovftool.tar.gz -O /vmfs/volumes/datastore1/vmware-ovftool.tar.gz

# extract ovftool content to /vmfs/volumes/datastore1
tar -xzvf /vmfs/volumes/datastore1/vmware-ovftool.tar.gz -C /vmfs/volumes/datastore1/

# deploy OVF from remote HTTP source
/vmfs/volumes/datastore1/vmware-ovftool/ovftool -dm=thin -ds=datastore1 "--net:access333=VM Network" "http://air.primp-industries.com/SLES-VM/SLES-VM.ovf" "vi://root:[email protected]"

# power on VM
vim-cmd vmsvc/power.on $(vim-cmd vmsvc/getallvms | grep "SLES-VM" | awk '{print $1}')

As you can see, virtually anything is possible ... even if you thought it was not earlier 🙂

Unattended Deployment of vCenter Infrastructure Navigator

by // 2 Comments

I deployed VMware's new vCenter Infrastructure Navigator in my lab over the weekend and just like the rest of the other virtual appliances (vCloud, vCO, vCC, vShield), here is how you can automate the deployment of VMware vIN.

Here are the ovf parameters that are available to deploy vCenter Infrastructure Navigator:

  • vm.password
  • vami.gateway.vCenter_Infrastructure_Navigator
  • vami.DNS.vCenter_Infrastructure_Navigator
  • vami.ip0.vCenter_Infrastructure_Navigator
  • vami.netmask0.vCenter_Infrastructure_Navigator

To see these properties before deploying, you can query using the ovftool which can help you identify the name of the ovf variables using the following command:

ovftool --hideEula Navigator-1.0.0.49-592384_OVF10.ova

Note: Before deploying vIN, ensure that you have the vCenter advanced setting VirtualCenter.ManagedIP configured as it is needed by the vService in vIN. For more details, take a look at this blog post on how you can easily automate this.

Here is an example of the ovftool command to deploy vIN Server:

ovftool --acceptAllEulas --skipManifestCheck '--net:Network 1=VM_Network' --datastore=iSCSI-4 --diskMode=thin --name=vin --prop:vami.DNS.vCenter_Infrastructure_Navigator=172.30.0.100 --prop:vami.gateway.vCenter_Infrastructure_Navigator=172.30.0.1 --prop:vami.ip0.vCenter_Infrastructure_Navigator=172.30.0.150 --prop:vami.netmask0.vCenter_Infrastructure_Navigator=255.255.255.0 --prop:vm.password=vmware123 Navigator-1.0.0.49-592384_OVF10.ova 'vi://root:*protected email*/?dns=vesxi50-3.primp-industries.com'

Of course, I wrote a simple shell script deployvIN.sh to help with the deployment. The script assumes you have ovftool installed and the OVF files located in the same directory as the script. You will need to edit the following variables if you wish to deploy vIN:

Note: There are many ways of using the ovftool to deploy an OVF. In this simple example, it requires you to specify an ESX(i) host, but you can modify the locator to deploy to a VM folder or datacenter path. For more examples and options, please take a look at the ovftool documentation.

Here is an example of the script in action:

Once the vIN virtual appliance has been deployed, you can also have it automatically power on by specifying the following parameter --powerOn.

If everything was successful, you should be able to license vCenter Infrastructure Navigator using the vSphere Client C# client and then login to the vSphere Web Client to enable the discovery process for your virtual machines. Shortly after, you should start seeing some application dependency within your vSphere environment like this:

How to Create Manifest File for OVF Signing

by // 4 Comments

While browsing the VMTN forums the other day, I just learned that you can sign your own OVF files using VMware's ovftool. To sign your OVF files, you will need the .ovf, .vmdk files and an X.509 certificate. Though not mandatory, you should also have a manifest file that includes a hash of the files to be signed. ovftool will still allow you to sign the OVF files, but a warning will be thrown if the manifest file is not included.

If you export a virtual machine/vApp using the vSphere Client or the ovftool, the manifest file is automatically generated for you and it ends with .mf extension.

If you have some OVF files that you want to sign but do not have the manifest file or somehow lost it, it is actually quite easy to re-create using the openssl utility.

To create the manifest file, run the following command for all files to be signed:

openssl sha1 *.vmdk *.ovf > MyVM.mf

You can use cat utility to view the contents of the manifest file:

To sign your OVF files, run the following command which will include the path to your X.509 certificate and the new signed OVF name:

ovftool --privateKey=ghetto.pem MyVM.ovf MyVM-Signed.ovf

Note: There is no space between --privateKey= and the path to X.509 certifcate, else you may get an odd error message.

If the signing was successful, you should not see any errors:

To view the newly signed OVF files, you can run the following command:

ovftool MyVM-Signed.ovf

You will find that the OVF has been signed under the "Manifest Info" section:

Now when you import the OVF back into your environment using either the vSphere Client or ovftool, you should now see the certificate information:

For more details and examples of using the ovftool, take a look at the user guide here.