WilliamLam.com

How to Copy VMs Directly Between ESXi Hosts Without Shared Storage

by // 93 Comments

There were some discussions earlier this week about copying Virtual Machines from one ESXi host to another ESXi host that reminded me of a very cool feature in the ovftool that could help with this task(which I thought I had written about already). As you probably have guessed by now, I am a big fan of the ovftool and have written several articles here, here and here. It still surprises me with the amount of features this little utility contains and this particular one is definitely a cool one!

If you have ever needed to copy a Virtual Machine from one host to another, it can be a challenge sometimes, especially if you do not have shared storage. You can of course leverage tools like VMware Converter or exporting the VM to a "middle man" system and then re-importing that VM into the destination host but it could take awhile or you have to run a Windows system. Well, if you are looking for a quick and easy way to copy a VM from one host to another, try using the ovftool.

In this example, I have two ESXi hosts called vESXi-03 and vESXi-04 and they both contain a single local datastore (no shared storage). I have a VM called vMA5 that is located on vESXi-03 and I would like to copy that directly to vESXi-04 without needing any additional storage.

Here is an example of using ovftool to probe the ESXi host to see the list of available VMs:

Note: A VM must be powered off for ovftool to transfered or exported.

Now that we have identified our VM, we just need to specify the source ESXi host and the destination ESXi host as well as the datastore using the -ds option. Here is an example of using ovftool to export the VM from one ESXi host to another ESXi host:

There are also other options that you can specify such as the network configuration and power options, please refer to the ovftool documentation for more details.

If you open up a vSphere Client connection to each of your ESXi hosts, you will see that the source host will have an export task and the destination host will have an import task as shown in the screenshot below:

Pretty nifty huh? 🙂

If anyone is interested in how this works, the system that is running ovftool acts as a proxy between your source and destination. The system running ovftool IS in the data path during the transfer but its only for the data to stream from source->client->destination. Nothing is stored on the client system and you do not need to have the storage capacity of what you are transferring. This is very nifty little feature that many people are not aware of with ovftool.

OVF Runtime Environment

by // 36 Comments

I recently noticed a trend of questions from various users about extracting specific bits of information such as the version of ESXi that's running or the MoRef ID of the VM, all while within the guestOS. I had already written an article about this topic awhile back called How to extract host information from within a VM? but it seems like there is still a continued interest to easily obtain this information about the underlying vSphere infrastructure from within the guestOS.

I came across another method while researching a different topic which is to use the vApp property of a VM called the OVF runtime environment. This is a feature that has been around since the early days of vSphere 4.x, if not earlier which provides a mechanism to retrieve some of this information as well as custom properties. The OVF feature provides users with the capability to pass in any type of metadata information such as application start up parameters, network configuration, password management, etc. directly into the guestOS for flexible guest customization.

[Read more...]

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/ [email protected]:/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 🙂