WilliamLam.com

Thank You For Voting!

by // 1 Comment

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

by // 16 Comments

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

by // 10 Comments

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 🙂