WilliamLam.com

Exploring the vSphere Flash Read Cache (vFRC) APIs Part 3

by // Leave a Comment

To conclude our 3-part blog series in exploring the vSphere Flash Read Cache (vFRC) APIs, in this last article we will take a look at the vSphere APIs required to live migrate a running Virtual Machine which has been configured with vSphere Flash Read Cache. If you perform this migration using the vSphere Web Client, you will see that you are now presented with a new option in the migration wizard on whether or not to migrate the vFRC cache.

If you choose to migrate the vFRC cache, you have the option to migrate all of the Virtual Machine's vFRC cache or you can specify this on a per VMDK basis by selecting the "Advanced" option. By choosing to migrate the vFRC cache, the migration will of course take longer as it needs to not only transfer the running Virtual Machine, but also the vFRC cache.

To automate this operation from an API perspective, you will need to use the Virtual Machine RelocateVM_Task method. As part of creating the migration spec, there is a new property called migrateCache which can now be specified on each VMDK.

To demonstrate the use of this vSphere API, I have created a vSphere SDK for Perl sample script called migratevFRCVM.pl which accepts the name of the Virtual Machine to migrate, the name of the ESXi host to migrate to and an optional parameter on whether or not to migrate the vFRC cache. By default, the script will migrate the vFRC cache if no option is selected.

Here is an example of migrating a VM along with its configured vFRC cache:

./migratevFRCVM.pl --config .vcenter55-1 --vmname Test-VM --dst_vihost vesxi55-10.primp-industries.com --migrate_cache true

Note: I have simplified the script to apply the --migrate_cache to ALL VMDKs, but as mentioned earlier you can specify this on a per-VMDK basis so you can migrate the vFRC cache for specific virtual disks if you choose to.

Hopefully you have enjoyed this series and now have a better understanding of the vSphere Flash Read Cache APIs. Be sure to check out the other two articles if you have not already.

Auditing vMotion Migrations

by // 3 Comments

I saw an interesting question this week about auditing vMotion events and the number of times a VM has migrated to a particular ESX(i) host for license compliance. You can view this information using the Task/Events in your vCenter Server but you can also extract out the various types of events using the EventManager in the vSphere API. You will be able to go as far back in time as your vCenter Server's database retention policy allows you to. We will be searching for the VmMigratedEvent Event which will include variety of information including the source and destination host for the VM. The destination host will only be populated upon a successful vMotion.

Of course I had to write a script to help automate this, so here is a vSphere SDK for Perl script called getNumberOfvMotions.pl that accepts the name of an existing VM and will return the number of vMotions that has been performed on the VM as well as the list of destination hosts and the number of times it has migrated to those hosts. You will need a system that has the vCLI installed or you can you use vMA.

Note:  If you want to look at past vMotion for a VM that no longer exists, this is still possible, but you will need to parse the "message" within the Event as you can no longer look up that VM object in vCenter.

Here is an example of the script running:

You can easily modify the script to audit all VM's in your environment or just use a simple "for" loop to go through a set of VM's you are interested in, but I will leave that as an exercise for you.

vMotion' With Style

by // Leave a Comment

I got this idea after catching an interesting tweet by Cody Bunch last Friday:

I had just recently finished a post on How to Ack & Reset vCenter Alarm implementing hidden API method and thought this might work by using a vCenter alarm. After few hours in our skunkwork's lab, I found "a" method to exactly what Cody wished for. If you can not wait, jump straight to the video at the bottom 🙂

The following tools were used:

  • PsExec -Windows utility to perform remote operations
  • SayStatic - Windows text to speech utility
  • A random mp3 audio file found online

The environment consisted of two vESXi 4.1 hosts and Windows XP VM residing on shared storage that was vMotion functional:

You will need to upload some files to your vCenter server and to the desktop in which you want to implement this hack.

Local Desktop Server Setup

1) Download SayStatic to your local desktop ( in the example, it is located on the desktop)

2) Download a playable mp3 file (in the example, it is located on the desktop)

Note: If you decide to change the path to the files above, please make note of the path as it will be used later in the alarm script.

Here is a screenshot of my local desktop:

vCenter Server Setup

1) Download PsTools toolkit and extract the contents to your vCenter Server and make a note of the path (in the example, it is located on the desktop)

2) Create an alarm script and make a note of the path ( in the example, it is located in C:\alarm.cmd)

The alarm.cmd should contain the following:

You will need to edit the script and update at minimum the following variables:
REMOTE_SERVER = This is the hostname or IP address of your local desktop, make sure you keep the double slashes which is needed

REMOTE_USERNAME = This is the username to login to your local desktop and it should be the one you use to login else you will not see anything interesting. Make sure you include both the Domain and username, if your system is not part of a domain, use the local system name else the script will fail.

REMOTE_PASSWORD = The password to the account aove

Note: If you have changed the path of the files on either the local desktop or vCenter Server, you will need edit the remainder variables that specify where to look for the executable's.

Here is a screenshot of vCenter Server desktop:

vCenter Alarm:

Finally, we need to create an alarm in vCenter, you can create this at any level of the vCenter infrastructure.

1) Create an alarm and give it a name and ensure the type is of "Virtual Machines" and monitor type is "Monitor for specific events occurring on this object" (in the example, I call it VMOTIONIN_WITH_STYLE)

2) Now click on the Triggers tab and look for an event type called "VM emigrating", no this is not a typo. VMware apparently has both "VM migrating" and "VM emigrating", apparently the functional alarm is under the name emigrating ... don't ask me why they called it that ;). Make sure the status is set to "alert"

3) Next, click on the Actions tab and set the action to "Run a command" and specify the configuration to the path of the alarm.cmd. In the example, I stored the script in C:\alarm.cmd and then make sure it alarms when it hits "red" or error and then click okay for the alarm to be created.

Now you are ready to go. Instead of explaining and providing screenshots, I thought I show you what this would look like (explanation of what is going on is at the very bottom).

Without further ado, here is a recorded video of this in action:

vMotion' With Style from lamw on Vimeo.

What is actually going on:
When a vMotion is triggered, it will fire off the alarm.cmd script which basically uses SayStatic.exe to remotely execute on your local desktop to announce the virtual machine being vMotioned by capturing the VMware specific environmental variables and then it will also remotely playing the local audio file using Windows Media Player.One caveat that I was not able to solve, was clearing the alarm after the vMotion. You will notice the virtual machines that vMotion and fire off this alarm will stay alerted and will not play again until it has been resetted to green. I thought about creating another alarm to clear this initial alarm but it did not actually clear the alarm.

There you have it, vMotioin' with style ... though cool in concept, I doubt you will last very long with this kicking off on every single vMotion in your environment.

Big thanks to Cody Bunch for the idea! 🙂