Automation – Page 193

Did you know of an additional cool vMotion capability in vSphere 6.0?

02.19.2015 by William Lam // 59 Comments

There was an excellent blog post from Duncan a couple of weeks back going over the new vMotion capabilities in vSphere 6.0 which includes: Cross vSwitch vMotion, Cross vCenter vMotion (xVC-vMotion) and Long Distance vMotion (LD-vMotion). If you have not checked out his article, I highly recommend you give it a read before proceeding further. After reading through Duncan's article, I noticed he had missed out on one additional vMotion capability which might not be obvious as the option is no where to be found in the vSphere Web Client UI. In fact, I was only aware of this additional capability after hearing about it from Engineering during the development of vSphere 6.

The additional vMotion capability actually extends the Cross vCenter Server vMotion (xVC-vMotion) workflow which allows an administrator to live migrate a running virtual machine between two vCenter Servers that are part of the same SSO Domain. By virtue of being in the same SSO Domain using the new Enhanced Linked Mode feature, both vCenter Servers will be visible in the vSphere Web Client and will be available to be selected either as a source or destination for a vMotion operation.

This extended Cross vCenter Server vMotion capability (unofficially I am calling it ExVC-vMotion) allows an administrator to live migrate a running virtual machine between two vCenter Servers which are NOT part of the same SSO Domain. How cool is that!? In my opinion, this is actually a pretty big deal because I think it truly removes any boundaries for a vSphere virtual machine and will open up an entire new class of mobility use cases that were never thought possible before. This will definitely make it interesting for customers who wish to migrate workloads from their on-premises datacenter into a completely different vSphere environment or even one that is hosted by a service provider or maybe even vCloud Air?

The ExVC-vMotion operation is currently only available today using the vSphere API, not because it is a private API but because there is no UI wizard for this operation. The reason the current xVC-vMotion is so seamless today is that both your source and destination vCenter Server is visible by being part of the same SSO Domain. If you have two completely different vCenter Servers which are not joined to the same SSO Domain or have completely different SSO Domains, then you will need to use the vSphere API to perform this operation.

All vMotion operations including vMotion without shared storage uses the vSphere API RelocateVM_Task() method. In vSphere 6.0, the method has been enhanced to accept a new property called ServiceLocator which provides a service endpoint to a vCenter Server where a VM can be migrated to. One important thing to note is that if you wish to migrate a VM between two vCenter Servers located in the same SSO Domain, there is an sslThumbprint property that is not required to be set. However, if the two vCenter Servers are NOT part of the same SSO Domain, then you need to set that property. In addition, if the VM is migrated to a different vCenter Server, additional properties such as the ESXi host, vSphere Cluster/Resource Pool and Datastore must be specified as part of the migration spec.

UPDATE (05/25/16) - I have re-factored and simplified my xVC-vMotion script which supports additional capabilities. Please have a look at the blog post here for more details.

To demonstrate this awesome ExVC-vMotion operation, I have created a simple PowerCLI script called run-cool-ExVC-vMotion.ps1 which accepts 12 command-line parameters which are described in more detail below:

Variable	Description
sourceVC	The hostname or IP Address of the source vCenter Server
sourceVCUsername	The username to connect to source vCenter Server
sourceVCPassword	The password to connect to source vCenter Server
destVC	The hostname or IP Address of the destination vCenter Server
destVCUsername	The username to connect to the destination vCenter Server
destVCPassword	The password to connect to the destination vCenter Server
destVCThumbprint	The SSL Thumbprint (SHA1) of the destination vCenter Server (can be retrieved using either this or this)
datastorename	The destination vSphere Datastore where the VM will be migrated to
clustername	The destination vSphere Cluster where the VM will be migrated to
vmhostname	The destination vSphere ESXi host where the VM will be migrated to
vmnetworkname	The destination vSphere VM Portgroup where the VM will be migrated to
vmname	The name of the source VM to be migrated

In my lab environment, I have configured two vCenter Server's which are part of two different SSO Domains as seen in the screenshot below:

I have tiny Linux VM (vMA) that I am using which I will be migrating from vcenter60-4 to vcenter60-5 which has a completely different datastore and VM portgroup (if you have stretched/extended L2, then the VM would stay online during this migration). I then execute the script using the following parameters based on my own environment and we can see the migration is kicking off:

.\run-cool-ExVC-vMotion.ps1 vcenter60-4.primp-industries.com *protected email* VMware1! vcenter60-5.primp-industries.com *protected email* VMware1! 82:D0:CF:B5:CC:EA:FE:AE:03:BE:E9:4B:AC:A2:B0:AB:2F:E3:87:49 vesxi60-8-local-storage NY-Cluster vesxi60-8.primp-industries.com NY-VM-Network vMA

One the migration has completed, if we now take a look at our vSphere Web Client, we can see the VM has now been migrated to the other vCenter Server.

I really hope to see the vSphere Web Client get enhanced to support this cool vMotion capability, but in the mean time you can easily perform this operation using the above PowerCLI script or any other scripting/programming language calling into the vSphere API. Set your VM free and let it migrate where your heart desires 🙂

Ultimate automation guide to deploying VCSA 6.0 Part 1: Embedded Node

02.18.2015 by William Lam // 28 Comments

In this article, I will share alternative methods of deploying the new VCSA 6.0 using an Embedded Node configuration. Take a look at the various deployment methods below and their respective instructions for more details. If you are deploying using one of the scripts below, you will need to extract the contents of the VCSA ISO. If you are deploying to Workstation/Fusion, you will need to extract the VCSA ISO and add the .ova extension to the following file VMware-VCSA-all-6.0.0-2562643->vcsa->vmware-vcsa before deploying.

Disclaimer: Though these alternative deployment options work, they are however not officially supported by VMware. Please use at your own risk.

Deploying to an existing vCenter Server using ovftool (shell script)

I have created a shell script called deploy_vcsa6_embedded_to_vc.sh which requires using ovftool 4.1 (included in the VCSA ISO) to specify the appropriate OVF "guestinfo" properties for an Embedded configuration. You will need to edit the script and modify several variables based on your environment.

Here is an example of executing the script:

Deploying to an ESXi host using ovftool (shell script)

I have created a shell script called deploy_vcsa6_embedded_to_esxi.sh which requires using ovftool 4.0 or greater to specify the appropriate OVF "guestinfo" properties for an Embedded configuration. You will need to edit the script and modify several variables based on your environment. The behavior of this script is similar to the one above, except you are deploying directly to an ESXi host.

Deploying to an existing vCenter Server using ovftool (PowerCLI)

I have created a PowerCLI script called Deployment-Embedded.ps1 which also allows you to specify the appropriate OVF "guestinfo" properties for an Embedded configuration. You will need to edit the script and modify several variables based on your environment.

Deploying to VMware Fusion & Workstation

To properly deploy the new VCSA 6.0, the proper OVF properties MUST be set prior to the booting of the VM. Since VMware Fusion and Workstation do not support OVF properties, you will need to manually deploy the VCSA, but not power it on. Once the deployment has finished, you will need to add the following entries to the VCSA's VMX file and replace it with your environment settings. Once you have saved your changes, you can then power on the VM and the configurations will then be read into the VM for initial setup.

guestinfo.cis.deployment.node.type = "embedded"
guestinfo.cis.vmdir.domain-name = "vghetto.local"
guestinfo.cis.vmdir.site-name = "vghetto"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.addr = "192.168.1.54"
guestinfo.cis.appliance.net.pnid = "192.168.1.54"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "true"

For more information, you can take a look at this article here.

Deploying using new scripted install (bonus)

As mentioned earlier, there is also a new scripted installer included inside of the VMware-VCSA ISO under /vcsa-cli-installer which supports Windows, Mac OS X and Linux, but must be connected directly to an ESXi host. There are several templates that are also included within the /vcsa-cli-installer/templates. I thought as a bonus I would also share the template I have been using to deploy an Embedded VCSA 6.0 using a static IP Address which some of you may find useful.

{
    "__comments":
    [
        "William Lam - www.virtuallyghetto.com",
        "Example VCSA 6.0 Embedded Deployment w/Static IP Address"
    ],

    "deployment":
    {
        "esx.hostname":"192.168.1.200",
        "esx.datastore":"mini-local-datastore-1",
        "esx.username":"root",
        "esx.password":"vmware123",
        "deployment.option":"tiny",
        "deployment.network":"VM Network",
        "appliance.name":"embedded-vcsa-node",
        "appliance.thin.disk.mode":true
    },

    "vcsa":
    {

        "system":
        {
            "root.password":"VMware1!",
            "ssh.enable":true,
            "ntp.servers":"0.pool.ntp.org"
        },

        "sso":
        {
            "password":"VMware1!",
            "domain-name":"vghetto.local",
            "site-name":"virtuallyGhetto"
        },

        "networking":
        {
            "ip.family":"ipv4",
            "mode":"static",
            "ip":"192.168.1.60",
            "prefix":"24",
            "gateway":"192.168.1.1",
            "dns.servers":"192.168.1.1",
            "system.name":"192.168.1.60"
        }
    }
}

The use the scripted installer, you just need to change into the appropriate OS platform directory (win32,mac or lin64) and there should be a binary called vcsa-deploy. To use this template, you just need to save the JSON to a file and then specify that as the first argument to vcsa-deploy utility.

Here is an example of deploying an Embedded VCSA using the vcsa-deploy scripted installer.

Cool Docker Container for VMware Utilities

02.17.2015 by William Lam // 11 Comments

Last week during lunch I learned about a cool little project that my colleague Alan Renouf was working on in his spare time at night. He was interested in learning more about Docker and thought the best way to learn about something new was by using it, which is normally how I learn as well. He came up with a nifty idea to create a Docker Image that would house a bunch of useful VMware tools which included several VMware open source projects as well.

UPDATE (11/23/16) - The Docker Container has now been updated with all the latest vSphere 6.5 SDK/CLI/Tools. We also plan to make this new version of the Docker Image available on Docker Hub, so stay tuned for those details shortly.

Some customers in the past have built similar offerings by using a free VMware Appliance called vMA (vSphere Management Assistance). vMA is nothing more than a stripped down version of SLES that has the vSphere CLI (vCLI) pre-installed. In my opinion, vMA is pretty limited and you can not install additional packages without voiding official support. Even if you decide to ignore support and install custom packages, I have often seen this break existing dependencies. When I talk to customers about their use of vMA, most used it because it was just there, but the majority prefer to use their own harden distribution of Linux and install their own admin utilities and packages which may also include non-VMware tools.

I personally have no problem building my own VM appliance that contains the various VMware packages, utilities and scripts that I use on a daily basis. However, not everyone is comfortable with this idea. Wow could this be further simplified and automated? Well, enter vmware-utils a Docker Image that allows you to automatically build a new image that contains some of the most popular and widely used VMware Utilities.

I wanted to enhance the awesome work that Alan had done with couple more VMware open source tools that I thought might be useful to VMware Administrators, which I actually wrote about here in my List of VMware CLIs, SDKS and DevOps Tools article. I have already submitted a pull request for my changes here. If there are other tools or packages you think that are useful and wish to contribute back, feel free to clone the repository and submit a pull request!

The latest vmware-utils now contains the following:

vSphere CLI 6.5
PowerCLI Core 1.0
vSphere Management SDK 6.5
vSphere SDK for Perl 6.5
vSphere SDK for Ruby (rbvmomi)
vSphere SDK for Python (pyvmomi)
vSphere Automation SDK for Ruby 6.5
vSphere Automation SDK for Python 6.5
vSphere Automation SDK for Perl 6.5
vSphere Automation SDK for Java 6.5
VSAN Management SDK for Ruby 6.5
VSAN Management SDK for Python 6.5
VSAN Management SDK for Java 6.5
VSAN Management SDK for Perl 6.5
Virtual Disk Development Kit (VDDK) 6.5
OVFTool 4.2
PowerCLI Community Repository
PowerCLI Core Docker Container Samples
William Lam's vGhetto Script Repository
Pyvmomi Community Samples
Docker Client v1.12.3
Docker Compose v1.8.1

For those of you who are new to Docker, a great way to quickly get started is by using an awesome tool called boot2docker which allows you to run Docker Containers on either a Windows or Mac OS X system. This also helps remove any barriers if you do not want to setup a Linux machine to get Docker of if you are like me, running on Mac OS X and rather not have to spin up a VM just to use Docker. Below are the steps on getting boot2docker working and building your own vmware-utils Docker Image.

Step 1 - Download the Docker Client for your specific OS (Windows, Linux or Mac OS X)

Step 2 - Take a look at the vmware-utils README, I spent some time updating it to make it more consumable for new users of Docker and follow the "How" section which will have you download the 4 VMware utilities as well as the vmware-utils DockerFile which we will need to build the Docker Container.

Step 3 - Create a directory and place all files into that directory. In this example, I have called the directory "vmware-utils".

Step 3 - We are now ready to build our vmware-utils Docker Image. Change into the "vmware-utils" directory that contains the files you downloaded earlier we will need to specify a "tag" for our image as part of the build command. In this example, I have called my image "lamw/vmware-utils" and to start the build process run the following command:

docker build -t lamw/vmware-utils .

Step 4 - The build itself may take some time depending on the speed of your internet connection. You will know when it has successfully completed when it states "Successfully built X" where X will be some unique ID as seen in the screenshot below.

Step 5 - Once the Docker Image has finished building, you can then run and connect to the Container by running the following command:

docker run --rm -it lamw/vmware-utils

At this point, you are now logged into the vmware-utils Docker Container that you have just built! It contains all the VMware Utilities that I have listed earlier and for more details on what has been installed and the location of the utilities, take a look at the vmware-utils Github documentation. If there are other tools you would like to see, feel free to contribute back by cloning the repository and submitting a pull request. I am definitely looking forward to seeing how this project evolves and providing a more dynamic way of creating a vMA-like experience without the current limitations. Keep up the awesome work Alan!