How to Run Windows 8 Consumer Preview & Windows 8 Server on vSphere 5

A few weeks back I wrote an article on how to run Windows 8 Developer Preview on ESXi 5, which required a small trick to get working. Today, it looks like Microsoft just released the Windows 8 Consumer Preview and Windows 8 Server. For those looking to give these a try, you can do so by using vSphere 5.

Disclaimer: VMware still does not officially support Windows 8 on vSphere, this is mainly for educational and testing purposes. Do not use this in a production environment

UPDATE (06/02/12): The steps below are the same for the recent release of Windows 8 Release Preview and Windows Server 2008 (Windows 8 Server) RC.

Here are the three easy steps to run Windows 8 on ESXi 5

1. Download and install ESXi500-201112001 (patch02) from VMware patch repository.
2. Create either a Windows 7 or Windows 2008 R2 regular VM (You will need to use e1000 network driver, VMXNET3 does not work)
3. Install Windows 8 Consume Preview or Server using the ISO (tested with 64bit) 

Note: Unlike the Developer Preview, no additional tweaks are needed to install Windows 8 Consumer Preview other than the ESXi 5.0 patch. 

When you first boot up Windows 8, you should see this fish logo. Be patient and give it a few minutes to load:

 Shortly after, you will be prompted to start the installation:

Here is a screenshot of Windows 8 Consumer Preview running on ESXi 5.0:

Here is a screenshot of Windows 8 Server running on ESXi 5.0:

Here is a screenshot of Windows 8 Server w/Hyper-V role enabled running on ESXi 5.0:

To enable Hyper-V role, you will need to perform the following changes:

• Update the guestOS to Windows 8 64bit using the vSphere Client
• Add the following CPUID bits using the vSphere Client
• Add the advanced setting using the vSphere Client hypervisor.cpuid.v0 = FALSE as described by this article as well as mce.enabled = TRUE (this is a new parameter introduced in ESXi 5) which is needed to run Hyper-V3 in Windows 8
• Install Hyper-V role
• Shutdown host
• Remove advanced setting using the vSphere Client
• Host should now boot and you should see the Hyper-V manager interface

Note: You can install VMware Tools on either Windows 8 releases by right clicking on the VM->Guest->Install VMware Tools. If you install VMware Tools on Windows 8 Server, you may need to enable 3D support if you get a black screen after installation as noted in this article.

So if you are itching to try out the new Windows 8 Consumer Preview or Server, you can install it and run it on vSphere 5!

How to Access vCloud Director Remote Console using vCloud & VMRC API

If you are familiar with the vCloud Director UI and have used the virtual console for a virtual machine, you may have noticed it is serviced by the VMRC (Virtual Machine Remote Console) vCD browser plugin which is only accessible in the vCD UI. If you are building a custom provisioning portal, you may want to provide similar functionality in your own portal for your users to access their VMs. 

You can do so by leveraging the vCloud API and the new VMRC API that was made available with the release of vCloud Director 1.5.

In addition to the VMRC API documentation, there is an sample VMRC API Reference Implementation that you can download and experiment with. When you extract the contents of the zip file, you will find an index.html and console.html web page and you can use this locally on your system or host it on a web server.

The index.html is the landing page that you will use to provide the vCloud VM's screen ticket using the vCloud API's AcquireTicket REST API method. The console.html will then load the VMRC for the requested VM assuming you provided a valid screen ticket.

Here are the four simple steps to access a vCloud VM's remote console using the vCloud REST API & VMRC API using curl:

Step 1 - Login

You will need a system that has curl installed and you will need an account in vCD that has access to some powered on VMs. In the example below, I will be logging into a regular organization and not the System organization. There are a few parameters you need to specify to login to vCD and obtain an authorization token. You will need to specify the following parameters and the URL to your vCloud Director instance which should be in the form of https://vcd-fqdn/api/sessions:

• -i = Include headers
• -k = Performs an "insecure" SSL connection
• -H = Setting the header for the version of vCloud Director (1.5 in this example)
• -u = User credentials in the format of [username@org:password]
• -X = Request type

Note: For more details on the cURL flags, please refer to the cURL documentation.
curl -i -k -H "Accept:application/*+xml;version=1.5" -u coke-admin@Coke:vmware -X POST https://vcd.primp-industries.com/api/sessions

HTTP/1.1 200 OK
Date: Tue, 28 Feb 2012 22:20:54 GMT

x-vcloud-authorization: n/+ZglmIwJ2SbWlyz04XC5sHUDJqefU1mCMa9TFu9lk=

Set-Cookie: vcloud-token=n/+ZglmIwJ2SbWlyz04XC5sHUDJqefU1mCMa9TFu9lk=; Secure; Path=/
Content-Type: application/vnd.vmware.vcloud.session+xml;version=1.5
Date: Tue, 28 Feb 2012 22:20:55 GMT
Content-Length: 894


<?xml version="1.0" encoding="UTF-8"?>
<Session xmlns="http://www.vmware.com/vcloud/v1.5" user="coke-admin" org="Coke" type="application/vnd.vmware.vcloud.session+xml" href="https://vcd.primp-industries.com/api/session/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
<Link rel="down" type="application/vnd.vmware.vcloud.orgList+xml" href="https://vcd.primp-industries.com/api/org/"/>
<Link rel="down" type="application/vnd.vmware.admin.vcloud+xml" href="https://vcd.primp-industries.com/api/admin/"/>
<Link rel="down" type="application/vnd.vmware.vcloud.query.queryList+xml" href="https://vcd.primp-industries.com/api/query"/>
<Link rel="entityResolver" type="application/vnd.vmware.vcloud.entity+xml" href="https://vcd.primp-industries.com/api/entity/"/>
</Session>

If you have successfully logged in, you should get an HTTP 200 response and get similar output as above. You will need to make note of your authorization token which is located on the third line that starts with "x-vcloud-authorization". This will be needed throughout the remainder of the session

Step 2 - Query All Powered On VMs

Using the new Query Service API in vCloud 1.5, we will locate all VMs within the vCD instance with the vm type. If you are logged in as a System Administrator and using the System Org, use the adminVM type instead. You can see the command is very similar to the one above but instead of specifying the credentials, we are using the authorization token from step 1. We are also including specific fields in the XML output for readability (VM name + vApp name), if you remove '&fields=name,containerName', you will see the other fields in the XML response. We also want to filter for only powered-on VMs, we can do this by adding '&filter=status==POWERED_ON'.

curl -i -k -H "Accept:application/*+xml;version=1.5" -H "x-vcloud-authorization: n/+ZglmIwJ2SbWlyz04XC5sHUDJqefU1mCMa9TFu9lk=" -X GET "https://vcd.primp-industries.com/api/query?type=vm&filter=status==POWERED_ON&fields=name,containerName"

HTTP/1.1 200 OK
Date: Tue, 28 Feb 2012 22:22:09 GMT
Content-Type: application/*+xml;version=1.5
Date: Tue, 28 Feb 2012 22:22:09 GMT
Content-Length: 1356

<?xml version="1.0" encoding="UTF-8"?>
<QueryResultRecords xmlns="http://www.vmware.com/vcloud/v1.5" total="2" pageSize="25" page="1" name="vm" type="application/vnd.vmware.vcloud.query.records+xml" href="https://vcd.primp-industries.com/api/query?type=vm&page=1&pageSize=25&format=records&filter=status==POWERED_ON&fields=name,containerName" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
<Link rel="alternate" type="application/vnd.vmware.vcloud.query.references+xml" href="https://vcd.primp-industries.com/api/query?type=vm&page=1&pageSize=25&format=references&filter=status==POWERED_ON&fields=name,containerName"/>
<Link rel="alternate" type="application/vnd.vmware.vcloud.query.idrecords+xml" href="https://vcd.primp-industries.com/api/query?type=vm&page=1&pageSize=25&format=idrecords&filter=status==POWERED_ON&fields=name,containerName"/>

<VMRecord name="WebServerVM" containerName="WebServer-Test-1" href="https://vcd.primp-industries.com/api/vApp/vm-25a4228e-1202-45a7-8f85-cafaeb1c3bc8"/>

<VMRecord name="ApplicationVM" containerName="AppTesting" href="https://vcd.primp-industries.com/api/vApp/vm-fadffc47-fa24-4ca0-9a90-f1048bc9f731"/>
</QueryResultRecords>

If the operation was successful, you should see a HTTP 200 response and list of VMs in your vCD instance. You will need to make a note of the VM's href property that you wish to obtain the remote console screen ticket for which is needed in the next step.

Step 3 - Obtain Screen Ticket for VM

Next we need to obtain the screen ticket using the AcquireTicket vCloud REST API method. You will need to perform a POST operation and using the href property from the previous step, append "/screen/action/acquireTicket". This link is only available IF the VM is powered-on and must be used within 30seconds or it will be considered invalid. 

curl -i -k -H "Accept:application/*+xml;version=1.5" -H "x-vcloud-authorization: n/+ZglmIwJ2SbWlyz04XC5sHUDJqefU1mCMa9TFu9lk=" -X POST https://vcd.primp-industries.com/api/vApp/vm-25a4228e-1202-45a7-8f85-cafaeb1c3bc8/screen/action/acquireTicket

HTTP/1.1 200 OK
Date: Tue, 28 Feb 2012 22:23:21 GMT
Content-Type: application/vnd.vmware.vcloud.screenticket+xml;version=1.5
Date: Tue, 28 Feb 2012 22:23:21 GMT
Content-Length: 895

<?xml version="1.0" encoding="UTF-8"?>
<ScreenTicket xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">mks://172.30.0.140/vm-180?ticket=cst-HtefHNvLNiLmfK1na3mx74rqmLmM%2FjhWu3UHHTFrRlnGZg%2FtgjfqwanE4HUvWgvaclaR5vRI3iJrOvJS4P%2Fq6vH%2FfU06v0kMJ4U1ngSCNnt2SmHpaazWp%2B7JPLMCPQz0f88bxnU3t2NIX3bn%2BrsIznRNaDkQeIEldti%2F7pWsH%2FWm1PGIAk%2Fh54IpBuaGmlwPtNjs40zGTLjSYzRtO9oII75jgWA%2F%2FVcRBXtIPgoQzL4GHpyS6PZ7vaTklxdjCUJklJnlAbpVjo7P5uUqzfhhFQa52GNxZK%2FCLS6nNJpVkmvV12J5aUwsWe3OXdecsckW%2By3VLdcKe9Fp8N44TEgGfqrjzvCsXOv5DbiChjrfhIBKlUhN2%2BHL2fHqbtrBbKvtteNERMl08cqExR7qyf4n1w%3D%3D-X6PBbcMUeRCaF5G6lkqOrrdPbjm%2FfLOj1Exk8w%3D%3D--tp-9B%3A2B%3A82%3A8D%3AA2%3AFD%3AF1%3A8F%3A42%3A20%3ABF%3A75%3AA9%3A4F%3AFA%3AA6%3AC4%3A09%3ACA%3A4F--</ScreenTicket>

Step 4 - Access VM Remote Console

Now we just need to take the screen ticket which starts with mks://..... and copy that over to our VMRC sample web page and hit the submit button. If everything was successful, you should see the a remote console popup up for the VM you had just requested the screen ticket from. You will also notice the IP Address in the screen ticket is not the same address as your vCloud Director Cell, it is actually the console proxy address if you were wondering why the IP is different.

So this is great, but you still need some interaction with the browser to actually submit the screen ticket request. What if we just wanted to provide a single URL that would automatically launch the remote console for a requested VM? You can definitely do so, but you will need to perform a URL encoding on the mks://... ticket and construct the proper URL.

Here is a simple shell script called vcloud-vAppRemoteConsole.sh that uses the same vCloud REST API calls as above and allows a user to select the vCloud VM to to retrieve a screen ticket and returns back a single URL to access the remote console of the VM.

The script requires three parameters: (username@organization, password and vcloud-host)

Here is an sample execution:

Once you have successfully logged in, you should see a list of VMs that are currently powered on (highlighted in blue). You will need to select a VM and provide the "href" property as input (highlighted in green). Then the AcquireTicket method will be called and the screen ticket is then encoded using a quick Perl one-liner. The encoded entry is then appended to the hosted URL of the VMRC sample https://air.primp-industries.com/vmrc/console.html? (you can replace the URL to fit your environment). The output of the script (highlighted in orange) is the URL you would then paste into a supported web browser and the remote console will automatically launch without any additional user input.

With the above knowledge, you can easily translate this using any of the vCloud SDKs (Java, .NET, PHP), vCO or the new vCloud Director cmdlets and provide console access to your vCloud VMs.

Note: For vSphere virtual machine remote console access instructions, please take a look at this article here. 

Thank You For Voting!

Eric Siebert of vSphere-Land.com just released the annual Top 25 Virtualization Blog results for 2012 this weekend and I am very proud and honored to announce that virtuallyGhetto has moved up from last year's #25 spot to now the #8 spot on the list! It was only a year ago that virtuallyGhetto first made it onto the Top 25 Virtualization Blog after only been around for 4 months. I am very humble to be among some of the smartest and most respected folks in the virtualization community!

New this year, in addition to the top virtualization blog post are the individual categories such as top storage, video, news, etc blogs. Of course scripting was one of the categories and though I did not get number 1, which went to my good friend/colleague Alan Renouf. I did win second place and following third went to Luc Dekens, another awesome scripter/friend in the scripting/automation community.

I wanted to take this time and thank all my readers and supporters from the blog, VMTN forums, twitter and email for voting for virtuallyGhetto! I am very happy to see that the topics/content that interests me also interest others and I really appreciate your support. I hope to continue to put out great and unique content in 2012 and beyond. Thank you again for all your support!

Lastly, I wanted to give shout out to some of the guys who made the top favorite new blogs: Barry Coombs, Josh Atwell, Andrew Mauro to just name a few and Jake Robinson (who did not make it to that list!?). Keep doing what you are doing and never give up, it will all payoff at the end!

Congrats to all the Top 25 virtualization bloggers! 2012 will be be another great year for bloggers!

Automating VMware Tools Upgrade Policy

I received a question this week from a reader who was looking to change the VMware Tools upgrade policy for a few hundred virtual machines and wanted to know if it was possible to automate this. The answer is absolutely yes!

By default the VMware Tools upgrade policy is disabled and set to "manual" mode. If you want the vSphere platform to automatically check and upgrade VMware Tools upon a system power cycle, then you can enable it by going to Edit VM->Options->Tools->Check and upgrade Tools during power cycling.

To update this configuration, there is a property in the vSphere API called toolsUpgradePolicy which can accept two values: manual or upgradeAtPowerCycle.

Here is a vSphere SDK for Perl script updateVMToolsPolicy.pl that supports two types of operations: "list" and "update". The list operation will show you all VMs and their currently configured upgrade policy, by default they should be all manual unless you have changed it manually. The update operation will allow you to configure a list of VMs and policy you designate. This change can be done while the VM is running, you do not need to make any changes to the guestOS that is running.

Here is an example of the "list" operation:

If you want to take all the VMs that have "manual" policy and change them over to "upgradeAtPowerCycle", you can copy the output to a file and then use a find or UNIX/Linux grep command to search for entries that have the word "manual".

Here is the command you can use if you are on a UNIX/Linux system:

cat output | grep "manual" | awk -F '["|"]' '{print $2}'


Here is the command to get the first column which contains the VM display name:

cat output | grep "manual" | awk -F '["|"]' '{print $2}' > VMLIST

Lastly, you just need to take the previous command and redirect that to a file which will then be used in the "update" operation. You can also take the output and using an editor to get to the final output, use whatever you are comfortable with.

Here is an example of the commands listed above:

Now that we have the list of VMs we are interested in updating, we just need to select the policy and perform the "update" command. Here is an example:

So there you have it, you can now easily automate the the VMware Tools upgrade policy for any or all your VMs without having to edit each one manually. 

Performing A Storage vMotion in vCloud Director Using vCO

I wrote an article yesterday called Performing A Storage vMotion in vCloud Director Using vCloud REST API and at the beginning I mentioned a few alternative solution to using the vCloud REST API such as the vCloud SDKs: Java, .NET, PHP or the new vCloud Director cmdlets. Afterwards, I realized I left out one very important solution, which is using vCenter Orchestrator (vCO) with the vCloud Director plugin.

I was able to quickly put together a vCO workflow using the Query Service in the vCD plugin and with the help of this VMTN thread from Christophe Decanni. I have exported my workflow so you can easily import it into your vCO Server without any hassle.

Disclaimer: Please thoroughly test this in a non-critical environment before using it on production systems.

Download: StoragevMotionForvCloud.workflow

To start using the workflow, you will need to ensure you have the vCloud Director 1.5 vCO plugin installed and import the workflow after you have downloaded it to your local system:

Here is a quick view of what the Storage vMotion for vCloud Director workflow looks like:

Here is an example execution of the workflow where we will Storage vMotion (using vCloud "relocate" API operation) to move "vESXi-01" VM from "iSCSI-3" to "iSCSI-4" datastore.

Step 1 - Select vCloud vDC and vCloud VM that you wish to performed the Storage vMotion. As part of the initial query, user will be provided with the current datastore the vCloud VM is residing on:

Step 2 - Once the query has completed to identify the current datastore the vCloud VM is residing on, a user interaction request will be needed to select the destination datastore to perform the migration to. You will notice the workflow icon will change to a yellow color and requiring an "answer" from the user. Right click on the workflow and click on "Answer" to continue the workflow:

Step 3 - You will see a "result" field which is the query of the vCloud VM that was selected and the datastore it's currently residing on. You will now have the option to select the vCloud datastore you wish to Storage vMotion the vCloud VM to:

Step 4 - Now you are ready to kick off the Storage vMotion operation. This may take sometime to finish depending on the size of the VM and the speed of your underlying storage. You should see a message under "Log" specifying the operation has been started. If everything is successful, you should see the vCloud VM now running on the new datastore.

Now you can enjoy performing Storage vMotions in vCoud Director with just a click of a button with the help of vCenter Orchestrator! Happy workflowing :-)

Performing A Storage vMotion in vCloud Director Using vCloud REST API

Currently there is not a way to perform vSphere Storage vMotion using the vCloud Director UI, but it is possible using the vCloud REST API. Since this feature is exposed in the vCloud API, it is also available using one of the three vCloud SDKs (Java, .NET, PHP), vCO or the new vCloud Director cmdlets but it does require some lines of code.

Since the vCloud API is exposed as a REST API, you can also interact with directly using a command line tool such as cURL or a REST client like the RESTClient Firefox plugin. In the example below, I will show you how to perform a Storage vMotion using cURL with the vCloud Director API 1.5.

Here we have a vApp in vCloud Director and it has two VMs, and as you can see both are located on the same datastore called "iSCSI-3".

Let's say we wanted to migrate the VM called "vESXi-01" to some other available datastore.

Step 1 - Login

You will need a system that has curl installed and you will need an account that has the "System Administrator" role to perform this operation. There are a few parameters you need to specify to login to vCD and obtain an authorization token. You will need to specify the following parameters and the URL to your vCloud Director instance which should be in the form of https://vcd-fqdn/api/sessions:

• -i = Include headers
• -k = Performs an "insecure" SSL connection
• -H = Setting the header for the version of vCloud Director (1.5 in this example)
• -u = User credentials in the format of [username@org:password]
• -X = Request type

Note: For more details on the cURL flags, please refer to the cURL documentation.

$ curl -i -k -H "Accept:application/*+xml;version=1.5" -u administrator@system:vmware -X POST https://vcd.primp-industries.com/api/sessions

HTTP/1.1 200 OK
Date: Sun, 19 Feb 2012 01:08:59 GMT
x-vcloud-authorization: aMcbkioTMvgVDDDJtdlwjrh6iutLPZ7fjL09hPa89mU=
Set-Cookie: vcloud-token=aMcbkioTMvgVDDDJtdlwjrh6iutLPZ7fjL09hPa89mU=; Secure; Path=/
Content-Type: application/vnd.vmware.vcloud.session+xml;version=1.5
Date: Sun, 19 Feb 2012 01:08:59 GMT
Content-Length: 1035

<?xml version="1.0" encoding="UTF-8"?>
<Session xmlns="http://www.vmware.com/vcloud/v1.5" user="administrator" org="System" type="application/vnd.vmware.vcloud.session+xml" href="https://vcd.primp-industries.com/api/session/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
<Link rel="down" type="application/vnd.vmware.vcloud.orgList+xml" href="https://vcd.primp-industries.com/api/org/"/>
<Link rel="down" type="application/vnd.vmware.admin.vcloud+xml" href="https://vcd.primp-industries.com/api/admin/"/>
<Link rel="down" type="application/vnd.vmware.admin.vmwExtension+xml" href="https://vcd.primp-industries.com/api/admin/extension"/>
<Link rel="down" type="application/vnd.vmware.vcloud.query.queryList+xml" href="https://vcd.primp-industries.com/api/query"/>
<Link rel="entityResolver" type="application/vnd.vmware.vcloud.entity+xml" href="https://vcd.primp-industries.com/api/entity/"/>
</Session>

If you have successfully logged in, you should get an HTTP 200 response and get similar output as above. You will need to make note of your authorization token which is located on the third line that starts with "x-vcloud-authorization". This will be needed throughout the remainder of the session

Step 2 - Locate VM

Using the new Query Service API in vCloud 1.5, we will locate all VMs within the vCD instance with the adminVM type since we are in the System organization. As you can see the command is very similar to the first one but instead of specifying the credentials, we using the authorization token from step 1. We are also including specific fields in the XML output for readability, if you remove '&fields=name,datastoreName', you will see the other fields in the XML response.

$ curl -i -k -H "Accept:application/*+xml;version=1.5" -H "x-vcloud-authorization: aMcbkioTMvgVDDDJtdlwjrh6iutLPZ7fjL09hPa89mU=" -X GET 'https://vcd.primp-industries.com/api/query?type=adminVM&fields=name,datastoreName'

HTTP/1.1 200 OK
Date: Sun, 19 Feb 2012 01:09:53 GMT
Content-Type: application/*+xml;version=1.5
Date: Sun, 19 Feb 2012 01:09:53 GMT
Content-Length: 1275

<?xml version="1.0" encoding="UTF-8"?>
<QueryResultRecords xmlns="http://www.vmware.com/vcloud/v1.5" total="2" pageSize="25" page="1" name="adminVM" type="application/vnd.vmware.vcloud.query.records+xml" href="https://vcd.primp-industries.com/api/query?type=adminVM&page=1&pageSize=25&format=records&fields=name,datastoreName" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
<Link rel="alternate" type="application/vnd.vmware.vcloud.query.references+xml" href="https://vcd.primp-industries.com/api/query?type=adminVM&page=1&pageSize=25&format=references&fields=name,datastoreName"/>
<Link rel="alternate" type="application/vnd.vmware.vcloud.query.idrecords+xml" href="https://vcd.primp-industries.com/api/query?type=adminVM&page=1&pageSize=25&format=idrecords&fields=name,datastoreName"/>
<AdminVMRecord name="vESXi-01" datastoreName="iSCSI-3" href="https://vcd.primp-industries.com/api/vApp/vm-0332975f-394f-49d2-baf9-b222d126b942"/>
<AdminVMRecord name="vCenter" datastoreName="iSCSI-3" href="https://vcd.primp-industries.com/api/vApp/vm-c0e4ead6-6e7d-4914-979b-0da49a8103a8"/>
</QueryResultRecords>

If the operation was succesful, you should see a HTTP 200 response and list of VMs in your vCD instance. You will need to make a note of the VM's href property that you wish to perform the Storage vMotion on.

Step 3 - Locate Datastore

Next we will use the Query Service API again to locate all available datastores within the vCD instance. We are also limiting it to the name field (href property is included by default). If you want to further filter the output to a particular vCenter Server, you can specify a filter for the particular vCenter href. For more details, you can take a look at the Query Service API documentation. 

curl -i -k -H "Accept:application/*+xml;version=1.5" -H "x-vcloud-authorization: aMcbkioTMvgVDDDJtdlwjrh6iutLPZ7fjL09hPa89mU=" -X GET 'https://vcd.primp-industries.com/api/query?type=datastore&fields=name'

HTTP/1.1 200 OK
Date: Sun, 19 Feb 2012 01:10:15 GMT
Content-Type: application/*+xml;version=1.5
Date: Sun, 19 Feb 2012 01:10:15 GMT
Content-Length: 1232

<?xml version="1.0" encoding="UTF-8"?>
<QueryResultRecords xmlns="http://www.vmware.com/vcloud/v1.5" total="2" pageSize="25" page="1" name="datastore" type="application/vnd.vmware.vcloud.query.records+xml" href="https://vcd.primp-industries.com/api/query?type=datastore&page=1&pageSize=25&format=records&fields=name" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
    <Link rel="alternate" type="application/vnd.vmware.vcloud.query.references+xml" href="https://vcd.primp-industries.com/api/query?type=datastore&page=1&pageSize=25&format=references&fields=name"/>
    <Link rel="alternate" type="application/vnd.vmware.vcloud.query.idrecords+xml" href="https://vcd.primp-industries.com/api/query?type=datastore&page=1&pageSize=25&format=idrecords&fields=name"/>
    <DatastoreRecord name="iSCSI-4" href="https://vcd.primp-industries.com/api/admin/extension/datastore/a5d6bf25-7916-45cb-a65a-5dfa14d2ba38"/>
    <DatastoreRecord name="iSCSI-3" href="https://vcd.primp-industries.com/api/admin/extension/datastore/c9bff014-deaf-4ad1-8871-b2f2479f454f"/>

Again, if the operation was successful, you should see an HTTP 200 response and a list of datastores in your vCD instance. From the output, we can see we have two available datastores "iSCSI-3" and "iSCSI-4". Let's go ahead and select "iSCSI-4" to migrate "vESXi-01" to. Also make a note of the datastore href property you wish to migrate the VM to.

Step 4 - Perform Storage vMotion

Lastly, we just now just need to invoke the "relocate" API operation for a VM. We need to first create the XML response for relocate operation as specified by the API. You will need to create a file that contains href of the datastore you wish to Storage vMotion the VM to:
$ cat relocate-response

<RelocateParams xmlns="http://www.vmware.com/vcloud/v1.5">
    <Datastore href="https://vcd.primp-industries.com/api/admin/extension/datastore/a5d6bf25-7916-45cb-a65a-5dfa14d2ba38"/>
</RelocateParams>

 Now we are ready to craft our final command to perform the Storage vMotion operation. Taking the information we recorded earlier for the VM, we need to append to the URL "/action/relocate" which will perform the relocate operation on this particular VM. You will also notice in this curl request, it is a POST request and we including an extra header specifying the "Content-Type" for the operation as defined in the vCloud API for "relocate" operation. The last parameter is specifying some data which is our relocate-response file that is needed as part of the request body.

$ curl -i -k -H "Accept:application/*+xml;version=1.5" -H "x-vcloud-authorization: aMcbkioTMvgVDDDJtdlwjrh6iutLPZ7fjL09hPa89mU=" -H "Content-Type:application/vnd.vmware.vcloud.relocateVmParams+xml" -X POST https://vcd.primp-industries.com/api/vApp/vm-0332975f-394f-49d2-baf9-b222d126b942/action/relocate -d @relocate-response

HTTP/1.1 202 Accepted
Date: Sun, 19 Feb 2012 01:11:46 GMT
Location: https://vcd.primp-industries.com/api/task/2078bfe6-0a47-4615-a377-01ed8067c637
Content-Type: application/vnd.vmware.vcloud.task+xml;version=1.5
Date: Sun, 19 Feb 2012 01:11:46 GMT
Content-Length: 1283

<?xml version="1.0" encoding="UTF-8"?>
<Task xmlns="http://www.vmware.com/vcloud/v1.5" status="running" startTime="2012-02-18T17:11:46.883-08:00" operationName="vappRelocateVm" operation="Relocating Virtual Machine (0332975f-394f-49d2-baf9-b222d126b942)" expiryTime="2012-05-18T17:11:46.883-07:00" name="task" id="urn:vcloud:task:2078bfe6-0a47-4615-a377-01ed8067c637" type="application/vnd.vmware.vcloud.task+xml" href="https://vcd.primp-industries.com/api/task/2078bfe6-0a47-4615-a377-01ed8067c637" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://172.30.0.139/api/v1.5/schema/master.xsd">
    <Link rel="task:cancel" href="https://vcd.primp-industries.com/api/task/2078bfe6-0a47-4615-a377-01ed8067c637/action/cancel"/>
    <Owner type="application/vnd.vmware.vcloud.vm+xml" name="" href="https://vcd.primp-industries.com/api/vApp/vm-0332975f-394f-49d2-baf9-b222d126b942"/>
    <User type="application/vnd.vmware.admin.user+xml" name="administrator" href="https://vcd.primp-industries.com/api/admin/user/b99d6670-5884-4345-a70d-f417d2e7556b"/>
    <Organization type="application/vnd.vmware.vcloud.org+xml" name="System" href="https://vcd.primp-industries.com/api/org/a93c9db9-7471-3192-8d09-a8f7eeda85f9"/>
</Task>

If everything went well, you should see an HTTP response code of 202 which means the operation was accepted by the server. Within the response of the "relocate" operation, you will get back a task handle for the Storage vMotion operation. If you watch your vCenter Server after you performed the command, you should see a Storage vMotion operation kick off for the VM that you have selected.

Once the operation has been completed, we can open up our vCloud Director UI and we should see that our VM has now been Storage vMotion to the datastore we specified.

Though you can interact with vCD directly with the REST API, you still may want to use one of the higher level abstraction languages to perform this type of operation in bulk.

Ruby vSphere Console (RVC) 1.6 Released

Rich Lane the creator of Ruby vSphere Console just recently released RVC 1.6 which includes some new features and bug fixes. If you are a current RVC user, you can update to the latest version by using the "gem" utility. For those of you who are not familiar with RVC, it is console UI for vCenter Server and ESX(i) host and it provides a way to interact with your vSphere infrastructure like the vSphere Client but using a console shell. RVC can be installed on a Windows, Linux or Mac OSX system and it's built on RbVmomi which is an open source Ruby library/bindings to the vSphere API.

I recently spent sometime revising RVC as it has gotten a significant amount of new features from the last time I looked at it. RVC currently has over 120+ commands that simplify some of the most common tasks such as cloning a VM (Full & Linked Clone), vDS Management, Cluster/Host/VM Management and many many others.

There are so many cool and unique features that RVC offers that I could not name them all, but I thought I share with you my top 5 favorite features of RVC.

1. vSphere Virtual Filesystem
RVC presents the vSphere infrastructure as a virtual filesystem, this allows you to quickly navigate your Hosts, Cluster, Datacenter, VMs, etc. in a very user friendly and intuitive manner. It also allows for tab completion of commands and the use of wild cards when referring to objects.

Here is an example of connecting to a vCenter Server and quickly building out a new infrastructure by creating a new datacenter, cluster, adding an ESXi host and then creating a Linked Clone VM in just seconds:

Here is another example of what can be done with the virtualFS that Rich has created, you can easily view or edit files within the datastores (e.g. .vmx,.vmdk,vmware.log).

2. Multi-vCenter Support

You can connect to multiple vCenter Server(s) at once and quickly navigate to any of your vCenter Servers to perform various operations. Each vCenter will have it's own constructed virtual filesystem that will show up when you login. 

Here is an example of connecting to 4 different vCenter Servers:

3. Performance Graphs
You can view performance charts using RVC similar to the vSphere Client. RVC quickly allows you to see what performance metrics are relevant for an object and displaying the graph using gnuplot:

Here is an example of displaying the live "cpu.usagemhz.average" metric for an ESXi host:

4. Marks
You can think of marks like an alias, RVC allows you to quickly save your favorite paths for later use and also include them within commands. This can be really helpful if you do not want to keep typing out a super long path and just give it a short and easy name to remember.

Here is an example of creating a mark called "favVM" to a particular VM in my vSphere infrastructure and perform a linked clone operation using the mark I created:

5. Extensibility

RVC as Rich stated does not (yet) have every single capability that the vSphere Client has, but is extremely extensible. Anyone with a bit of Ruby and vSphere API knowledge can extend or create new commands for RVC. It it modular in nature and when you create/extend a new command, you do not necessary need to add it to the original RVC source code. You can actually add your *.rb files into the .rvc directory in your home directory and RVC will automatically pickup the commands you added. If you create some cool and useful new commands, be sure to send them to Rich via the github project so he can include it in the main branch.

Here is an example of extending two new commands for "cluster" object. There are currently only three cluster commands by default: add, configure_ha and create. You may have noticed that configuring DRS is not one of the available commands, but wouldn't it be nice to have it? I created two new commands called "configure_drs" and "configure_automationlevel" which allows you to enable/disable DRS for a cluster and also specifying the DRS automation level.

Here is the source code for two commands that were added in .rvc/cluster.rb

Note: This was my first time writing any Ruby code, I'm sure I could have combined the two operations with some conditionals and then create the property drsConfig object.

If these five features of RVC seems really cool, I would highly recommend you go download and install RVC and give the rest a spin. If you have any feedback, questions or want to submit a patch for the RVC project, be sure to check out the RVC github project page for all the details.

How to Configure Nested ESXi 5 to Support EVC Clusters

Dave Hill recently wrote an article about running nested ESXi and a gotcha with EVC (Enhanced vMotion Compatibility). In vSphere 4.x, you could not join a nested ESXi host into a cluster with EVC enabled. With vSphere 5, there's actually a way to connect a nested ESXi 5 host to an EVC enabled cluster AND still power on 64bit nested guestOSes.

I have to thank my friend and partner in crime Tuan Duong for showing me this trick awhile back. Tuan was performing some tests using both nested and physical ESXi 5 hosts and discovered this method after a bit of tinkering. At the time, I was not sure if others would find this useful and I did not document the process.

Disclaimer: As usual, this is not officially supported by VMware, use at your own risk. 

Here are the steps:

1. You must be running vSphere 5, create a nested ESXi 5 host using this article How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5

2. Create an EVC enabled cluster or use an existing cluster with whatever baseline you would like and click on the "Current CPUID Details" in cluster settings.

3. Copy down the CPU mask flags for that particular EVC baseline, you will need this in the next step

4. Shutdown your nested ESXi 5 host and edit the VM's settings and under "Options" tab click on "CPUID Mask->Advanced". You will take the CPU mask from the above step and update the nested ESXi 5 VM to make it match

5. Go ahead and power on your nested ESXi 5 host and join it to the EVC enabled cluster you created earlier. You should not see any errors when connecting to the cluster and after that you can create a nested 64bit VM within that virtualized ESXi 5 host.

There you have it, running a nested ESXi 5 host and joined to an EVC enabled cluster! Isn't VMware technology awesome! :-)

How to Run Windows 8 on vSphere 5 (for reals)

Awhile back I wrote an article about running Windows 8 on vSphere 5, but the trick did not work. There was an issue during the installation that caused a system panic in the OS and prevented Windows 8 to be installed. VMware did not officially support Windows 8 as a guestOS in vSphere 5 as Windows 8 itself was not released, only a developer preview was available.

It looks like VMware has been hard at work to get support for Windows 8 running on the vSphere 5 platform and I recently got a tidbit that the issue was resolved in a recent ESXi 5 patch. Make sure you keep this on the DL .... they maybe watching :-)

Disclaimer: VMware still does not officially support Windows 8 on vSphere, this is mainly for educational and testing purposes. Do not use this in a production environment

Here are the five easy steps to run Windows 8 on ESXi 5

1. Download and install ESXi500-201112001 (patch02) from VMware patch repository.
2. Create either a Windows 7 or Windows 2008 R2 regular VM (must be either of these guests)
3. Edit your VM and under "Hardware->Video Card" enable 3D graphics support (this is required if you plan on running VMware Tools). You will also need to use e1000 network driver, VMXNET3 does not work
4. Install Windows 8 using ISO
5. Sit back and wait for the installation to complete. 

Here are a few screenshots of Windows 8 running on ESXi 5

So there you have it, you can now run the developer preview of Windows 8 on vSphere 5!

FYI - VMware does have a KB article regarding Windows 8 on vSphere which I hear will be updated very shortly. Be sure to follow it for the full details when it is updated.

UPDATE: 

If you decide to install VMware Tools (which you should always), after a reboot, you may notice the system just sitting on the splash screen and not allowing you to login. The fix is to enable 3D graphics support. Power down your Windows 8 VM and edit the settings under Hardware->Video Graphics and check the 3D box and then power back on your VM.

Automating vCenter Server Appliance 5.0 (VCSA) Configurations

I recently had a need to deploy half a dozen or so vCenter Server Appliance (VCSA) in my home lab and even though it is one of the easiest appliances to setup, going through the web management interface can still be time consuming. I was looking to see if there was a way to automate some of the configurations and while digging in some of the vCenter logs I came across /var/log/vmware/vpx/vpxd_cfg.log which provided the answer I was looking for.

If you watch the log as you configure the VCSA through the web management interface, you will see a series of commands calling /usr/sbin/vpxd_servicecfg. This utility is actually just a shell script wrapper for the configuration of vpxd (vCenter Server Daemon) and it's respective services.

As you can see there is a warning message about the use of the tool, so I will also re-iterate with my own disclaimer:

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Please test this in a development environment before using it on actual systems.

For my lab, this was exactly what I was looking for to quickly spin up VCSA and configure all the necessary services to start the vCenter Service. In my lab, I was able to get the VCSA booted up via DHCP and execute a simple shell script remotely via SSH to VCSA and then connect to vCenter Server after the process was completed.

Here is script with the minimal commands needed for running an embedded configuration:

To run the script remotely (you do not need to copy it to VCSA), use the following command:

# ssh root@[vcsa-ip] < configureVCSA.sh

The script accepts the EULA, configures the database as embedded configuration and then starts up the vCenter service. A return code is provided upon each command execution which has VC_CFG_RESULT=N where N can be 0 which is a successful execution and any other value means there is an error. To figure out what the code means, there is a section in the shell script that lists all the codes and their meaning. In general, you should be getting 0 for all commands

Here are some other useful commands that I tested with:

Configure Active Directory:
/usr/sbin/vpxd_servicecfg ad write [AD_USERNAME] [AD_PASSWORD] [AD_DOMAIN]

Re-initialize vCenter DB *** PLEASE BE VERY CAREFUL WHEN USING THIS COMMAND, AS DB IS WIPED***


//ensure vpxd has stopped
vpxd_servicecfg stop

//re-init DB
vpxd_servicecfg db initialize

You can also configure an external database for vCenter, NIS directory service and even replace SSL certificates but I will leave that to the reader for some exploration.

Unattended Deployment of vCenter Infrastructure Navigator

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:vmware@vcenter50-4.primp-industries.com/?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:

Automating vCenter Server Advanced Settings

This weekend I needed to make a change to one of the advanced settings in my vCenter Server. This can be done using the vSphere Client, but it is also possible to use the vSphere API, (although it is not well-known). This can come in handy especially when you need to make a change across several dozen vCenter Servers and not have to manually login to each one. In the vSphere API, there is a property under the service content called setting which contains an array of advanced settings that can be modified.

I wrote a quick vSphere SDK for Perl script called vCenterAdvSettingMgmt.pl which allows for two type of operations "list" and "update". When you use the update operation, you will be required to pass in both the key and value that you would like to change.

Here is an example of the "list" operation:

Here is an example of the "update" operation where I am updating the "VirtualCenter.ManagedIP" setting:

You can verify the change by re-running the "list" operation:

This script came in very handy when deploying the new vCenter Infrastructure Navigator which requires "VirtualCenter.ManagedIP" to be configured prior to deploying.

How to Change the IP Address for vCenter Operations 5 vApp

There was an interesting question on twitter from Matt Cowger yesterday asking how to modify the IP Address of the Analytics VM in the new vCenter Operations 5 vApp after it has been deployed. The new VC Ops 5 is actually composed of two virtual machines: UI and Analytics VM. As part of the initial deployment, they're is an exchange of information between the two VMs to properly get setup which includes the IP Addresses of each other. Simply modifying the IP Address of either VM will result in VC Ops not functioning correctly.

I personally have not had to re-IP my home deployment of VC Ops, but I did have some experience with CapacityIQ before it was combined into the VC Ops product and there was a nifty CLI tool called ciq-admin that was not very well known. I thought I check to see if the new VC Ops had something similar and to my surprise, an updated version of the tool exists and has been renamed to vcops-admin.

After a few minutes of looking around, it was clear that one could modify the IP Address of the Analytics VM and here are three simple steps.

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Please ensure you test and backup your system before making any changes in a real production system. Data that was previously collected will still be available after the change of an IP Address.

Modifying IP Address for Analytics VM:

Step 1 - First we need to shutdown VC Ops, you can do this from the administrator page by going to https://[vcops-ip]/admin and stopping the service under the Status tab. In this example, I will be showing you how to so using the CLI on the UI VM (this is primary system you use to access VC Ops)

You will need to sudo to "admin" user to run the command "vcops-admin stop". If you accidentally logged into the analytics VM and try to run the command, you will receive an error as the CLI is only available on the UI VM.

Step 2 - Log into the remote console of the analytics VM, this is required as you will be changing the IP Address and may possible impact network traffic. You will need to edit /etc/sysconfig/network/ifcfg-eth0 using an editor such as "vi" and specify the IP Address you wish to change to. Once you are done, you will need to restart the network interface for the changes to take effect. To so so, run the following command "service network restart".

Step 3 - Go back to the UI VM (you will need to sudo over to "admin" account if you are not already) and you will now need to "repair" the connection between the UI and Analytics VM to ensure they can communicate with each other. To do so, you will run the following command "vcops-admin repair --ipaddress [new-analytics-ip]". If the UI VM is able to successfully connect to the new IP Address of the Analytics VM, it will automatically start up the VC Ops service. Once the service has been started, VC Ops is now running and operational.

Now what if you want to change the UI VM's IP Address? I thought this should be pretty straight forward right? Well, it took me a bit longer than I was expecting but the process is just four easy steps.

Modifying IP Address for UI VM:

Step 1 - Stop VC Ops service, you can do this using the admin portal or via SSH as shown in Step 1 of Analytics VM

Step 2 - Login to the remote console of the UI VM this is required as you will be changing the IP Address and may possible impact network traffic. You will need to edit /etc/sysconfig/network/ifcfg-eth0 using an editor such as "vi" and specify the IP Address you wish to change to. Once you are done, you will need to restart the network interface for the changes to take effect. To so so, run the following command "service network restart".

Step 3 - Login via SSH to UI VM using the new IP Address (you will need to sudo over to "admin" account if you are not already) and you will now need to "repair" the connection between the UI and Analytics VM to ensure they can communicate with each other. To do so, you will run the following command "vcops-admin repair --ipaddress [new-analytics-ip]". If the UI VM is able to successfully connect to the Analytics VM, it will automatically start up the VC Ops service.

Step 4 - The last step is to update the vCenter VC Ops plugin information so when you navigate to the VC Ops extension, it knows the new IP Address. This step can be done by logging into the admin portal and under "Registration" tab, you will need to click on the "update" button for each and every vCenter that is attached to the VC Ops. In this example, I will show how to do so using the "vcops-admin" CLI. You will need to run the following command "vcops-admin register update --vc-name [vc-name] --vc-server [https://vc-server/sdk] --username [vc-username] --password [vc-password] --force"

Note: This process may take a few minutes for each vCenter that you need to update, also if you  have a dedicated service account for the collector, you can specify --collection-user and --collection-password agruments.

Though the process of modifying the IP Address is not available through the UI today, it is a feature that I will be requesting as this should be a trivial task for users.