Friday, August 26 2011 15:18 Written by VMGuru
It appears that when I did my site re-design a while back, I left out a few key blog posts. I was kindly reminded today, that my CBT Tracker post no longer exists, so I've decided to bring it back from the dead, as I was under the impression many people found high value in understanding data growth patterns of individual VMs in their environment.
I took it as a personal challenge this week to leverage PowerShell, PowerCLI and the vSphere API to track the amount of data that changes in a VM over a regular interval window. It turns out VMware does make it quite simple to query what blocks in a VMDK file have changed and what the length of data is as long as you know how to structure the API call.
The following script can be run as a scheduled task in Windows on a regular interval such as every 15 or 60 minutes, or even just once a day (depending on how granular you want your data) against a single VM. This is perfect for profiling the amount of data a particular VM will need to send (uncompressed) over a network connection for backup or replication purposes.
There are a few quick things to note about this script:
- It requires vSphere and CBT to be enabled for the selected virtual machine. This also means the VM Hardware version must be set to 7. There is an optional flag of "-enableCBT $true" that can be set as a script parameter to enable CBT for the specified VM. This executes an additional function in the script to turn CBT on. If CBT is already enabled, the function simply exits cleanly, no harm, no foul.
- I don't recommend running this script against a VM if there is potential overlap with other regular processes such as backup or replication that add snapshots to virtual machines. I don't have advanced snapshot debugging in here and simply don't know how all scenarios of snapshots being added/removed from multiple programs against a single VM will play out.
- I have it limited so a single instance of the script can be run against a single VM only. I started off with this being a simple proof-of-concept script, and haven't built in proper multi-VM intelligence yet. If there is enough demand, I'll definitely consider it.
You should create a standalone directory somewhere on an available hard drive of a Windows system. Create a new PS1 file using the built in script editor in PowerGUI. Copy and paste the following code block and save the file as "CBT_Tracker.ps1" in the newly created directory:
There is one optional parameter, and that is setting "-enableCBT = $true" in the batch file inside the quotes. What this will do is attempt to enable CBT on the specified VM. Once CBT is enabled, the flag is no longer needed. It also will not do any specific harm if CBT is already enabled, and will just exit the function and continue on its way.
With the script file created, use notepad or other simple text editor to create a new CMD file called "CBT_Tracker.cmd". This is what you will execute within Windows Task Scheduler. Paste the following line in the CMD file and edit with the proper parameters for your environment. Make sure you copy exactly, including the quotes.
You can now fire up Windows Task Scheduler and point to the CMD file. After the script runs for the first time, you will see 2 new files per VM that you set this to run against. $VMName-CBT_Tracker.cfg is used for tracking previous snapshot history for reference in the current script iteration. $VMName-CBT_Tracker.csv is the actual data file that contains the VMName, Timestamp, and Amount of data changed.
I've also attached a ZIP file containing the PS1 script for those that don't want to mess around with script editors and copy/paste actions.
How are we to interpret the ChangedMB information? I've been running this script against one of my DC's. I'm finding that every 15 minutes, there is roughly 30-75 "ChangedMB". If there are three intervals of 30 MB changes, does that mean that I would need to transfer 90 MB of new data uncompressed to my target location?
where does the CSV file get saved? i'm seeing snapshots created and removed, but not seeing the files that are supposed to be created. maybe i'm missing some background information on how this all works. VM ver = 7, vmware powerCLI installed, running as administrator. i am getting a certificate error, could that be it?
Thanks for this VM Guru, exactly what I was looking for:-)
I had some issues with the certificate error which I resolved by running the following command in PowerCLI...
Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore" -Confirm:$false
The other thing that had me lost for a while was the task, I had to put the name of the CMD file in as the program and then the directory in the 'Star in (optional):' box.
With that done I'm in business and happily monitoring a couple of test Windows 7 boxes every 15 mins from the vCentre VM. Both are thin provisioned, not being used for anything, one has Symantec Endpoint installed, no pending updates, nobody logged onto them, no active apps, basically doing nothing at all.
I've noticed that the 'Changed MB' on both VM's ranges from 5 to 98! Any thoughts on why the changed MB would be so high?
Hi VM Guru,
I'll have a look at the VMFS alignment.
When I had a closer look at the CSV file I realised that the big changes all seem to happen hourly, I was running a 15 min cycle! It could be something to do with a Windows 7 tasks buried away in the task scheduler or as you say SEP could be doing something. Strange that it also happens on the VM that doesn't have SEP though.
I was wondering where you would recommend running the tasks from? In DEV I'm running them from the VM that has vCentre installed but is that best practice?
One final noob question......
I have a server that creates a lot of temp files when reports are ran. If I replicated the server daily at 23:00 and had a script in place that deleted the temp files before the replication would all the writes and deletes of those temp files be seen as changes in blocks and need to be replicated?