Finding Size of Snapshot

[cpaterik]

Using Orchestrator, how do you find the size of a snapshot?

[tschoergez]

Hi!

See the "Library/vCenter/Virtual Machine management/Snapshot/Remove snapshots of a given size" workflow in the library.

Its first element contains to logic to get the size of a snapshot...(by traversing through the files of the VM.)

To you have a given snapshot, or a given Virtual Machine you want to examine?

Cheers,

Joerg

[Gkeerthy]

if you have SSH, log in to the shell

ls -lsh /vmfs/volumes/<datastore>/<virtual machine folder>

you can see the exact size of all the files.. including the vmdk and delta vmdks

[cpaterik]

I actually looked at that workflow and cut-and-pasted that into a workflow that I was building. When I printed out the sizes it generated, they were not correct. I think that “dataKey” is the wrong file. I hard coded “7” instead and that was the correct size, but only worked for the first snapshot of a VM. If I had multiple snapshots for a VM, hardcoding 7 didn’t work.

Carl Paterik, VCI, VCAP-DCA, RHCSA, MCSE

VMware, Inc.

Senior Learning Consultant

cpaterik@vmware.com<mailto:cpaterik@vmware.com>

(480) 789-2887 (Cell)

[cpaterik]

I think it should be (see comment in red in script below):

var size;
if(I_vm.runtime.connectionState.value == "connected" && !I_vm.config.template){
var vmLayout = I_vm.layoutEx;
if(vmLayout != null){
  var layoutFiles = vmLayout.file;
  var layoutSnapshots = vmLayout.snapshot;
  for(l in layoutSnapshots){
   var layoutSnapshot = layoutSnapshots[l];
   var dataKey = layoutSnapshot.dataKey - 1;  <-- Not just layoutSnapshot.dataKey
   for(m in layoutFiles){
    if(layoutFiles[m].key == dataKey){
     size = layoutFiles[m].size/1024/1024;
    }
   }
  }
}
}

[tschoergez]

You are right: The workflow I mentioned in the library just checks the size of the .vmsn-file, not the size of the delta.

with the -1 in your script you change this behaviour, to check the size of another file. However, I'm not sure if it is guaranteed that the file with key = vmsn-key - 1 always is the related delta.vmdk :smileyconfused:.

All of this is not an issue of vCO, but a limitation of the vCenter API.

BTW: I took the challenge what happens if you don't have a given VM, but just a given Snapshot. In the vCenter Data Model there is no direct way back to get the corresponding VM object, so you have to do some further search:

//snapshot is of type VcVirtualMachineSnapshot
var snapconfig = snapshot.config;
var vmuuid = snapconfig.uuid;
var sdkConnection = snapshot.sdkConnection;
var filterStr = "xpath:config/uuid[matches(.,'" + vmuuid + "')]";
System.debug('filterStr: ' + filterStr);
var vm = sdkConnection.getAllVirtualMachines(null, filterStr)[0]; //you might want to add some error handling/check that exactly one VM is found

Cheers,

Joerg

[stumpr]

I wouldn't call it a limitation, just how the snapshot structure is organized.  The tricky part is determining the 'running delta' with the current VMDK deltas and vmsn file.  I definitely would not rely on 'dataKey - 1' being relevant.  That is the vmsn file key in the file array and has no relationship with earlier snapshot vmsn file keys.

You also have to account for multiple disks per VM and multiple snapshots (and you may be currently running on a different snapshot leaf than the most recently created).

[2012-07-21 16:00:48.452] [I] Total VirtualMachine file usage: 2542.82 MB

[2012-07-21 16:00:48.453] [I] Total VirtualMachine disk usage: 1002.87 MB

[2012-07-21 16:00:48.453] [I] Snapshot Tree for VirtualMachine 'ImportTest00':

[2012-07-21 16:00:48.454] [I]   First (sizeMB=1515.36; %Total=59.59)

[2012-07-21 16:00:48.454] [I]     Second (sizeMB=513.32; %Total=20.19)

[2012-07-21 16:00:48.455] [I]     First-1 (sizeMB=0.23; %Total=0.01)

[2012-07-21 16:00:48.455] [I]       *First-2 (sizeMB=513.42; %Total=20.19)

In my example output, snapshot 'First-1' was called without saving the current memory state, which is why it's particularly small.  I didn't have any disk activity to increase the VMDK files on the other snapshots, which is why they are all the same size.  Note, 'First' is 1.5 GB because it includes the original VMDKs as the root snapshot.  The current snapshot is 'First-2', marked with '*'.

I attached the workflow if you want to review the logic.  I'm sure there are improvements that can be made to it.

If you wanted the size of a particular snapshot, but didn't care about the % usage or running deltas, then you can just get the snapshot from layoutEx, sum up all the disks by using the chain keys and add the dataKey disk size (vmsn file).  That would in essence be the size of the snapshot.  Just bear in mind the first snapshot will include the parent VMDK files.

[tschoergez]

This is GREAT stuff!

Thank you very much for sharing!

Cheers,

Joerg