Expected behavior when enumerating snapshots

[wsaxon]

I am trying to write a script to build a report on every VM in my cluster. In the past, I have built this by hitting the vCenter database directly, but I am trying to redo it using the API. The ultimate goal is to be able to get, for every VM, a clear picture of basic CPU/RAM/Disk configuration as well as guest OS, consolidated storage usage and a snapshot tree (with age and storage). I can get all of this minus the snapshot info right now, but as soon as I try to include anything with snapshots I run into trouble.

I'm using vCenter Server 4.1 and SDK 4.1. I've tried the attached script on both Linux (Ubuntu Lucid, perl 5.10.1) and Windows (using the perl distributed w/ the SDK) with identical results.

If I get views for all VMs, like this:

my $entity_views = Vim::find_entity_views(

view_type => 'VirtualMachine',

properties => [

'name',

'config.hardware',

'config.guestFullName',

'summary.storage',

]

);

and then pull out configuration and storage information, my script completes in about 20 seconds. However, if I try to add 'rootSnapshot' to the property filter I get an InvalidPropertyFault, even though I see the property is available when browsing the MOB on the vcenter server. I am able to add 'snapshot.rootSnapshotList' to the property filter, and just doing that doesn't cause the script to take much more time to complete. However, as soon as I try to do something like this:

     $view->get_property("snapshot.rootSnapshotList");

the script never completes. Progress stops as soon as I call get_property() for the snapshot list. The perl.exe process takes 100% of its CPU as long as I let the script continue to run.

What am I doing wrong? Is this known behavior? Is there perhaps a better way to get the information I want?

[lamw]

This health check script gathers quite a bit including what you're trying to do and the data output is 100% configurable - http://communities.vmware.com/docs/DOC-9842

[wsaxon]

Thanks, this does help. I see that snapshot delta data is not being resolved by VM, instead it's just being dumped from each datastore. There is no explicit connection between the discovered deltas and the snapshots they belong to, nor is there an easy way to display total delta size per VM. This still gets me a lot closer to what I want than before I asked, though.

[stumpr · Accepted solution]

So I downloaded and ran your script.  I'm seeing the same issue when you attempt to get_property() on a VM with no snapshots.

It looks like the problem is in the get_property subroutine.  It's going into an endless loop.  The problem is because the 'snapshot' is not set by the SDK.  I think the subroutine needs an "else" clause to handle the case of the path string having only one sub element remaining (in this case 'snapshot') that isn't defined.

I would suggest you use a simple property call without the utility function for now.  The proper fix will be to update the get_property() subroutine in the Perl SDK package.

Try the following:

## The following causes the script to run 'forever' ##

# my $snapshots = $vm->get_property('snapshot.rootSnapshotList'); # Bug in get_property() code

# This will fix the endless loop bug by avoiding get_property()

my $snapshots = $vm->{'snapshot.rootSnapshotList'};

You'll have to check if $snapshots is undefined before making use of it to avoid a runtime error.  Of course, you will likely want to replace get_property() throughout your code to be sure you don't encounter the same issue.  Or you can patch the SDK code.  I have a post somewhere on this forum using Sub::Override ( a source module that you can embed in your scripts if you needed transportability ) that you could use to override the default get_property() call with your own version.  I think the simple fix would be to add an "else" clause that sets "$val" to "undef".  The get_property() sub is on line 1696 in VICommon.pm.

[wsaxon]

Thanks, this is exactly what I was looking for.

I wonder if this is something that should be filed officially as a bug.

[stumpr]

It most definitely is a bug and should be reported.  I'll probably reach out internally when I get a chance.

[lsemis]

This bug is still there I guess no one reported it?

sub get_property {

   my ($self, $path) = @_;

   my @subpaths = ();

   my $val;

   while ($path) {

      if (exists $self->{$path}) {

         $val = $self->{$path};

         last;

      } elsif ($path =~ /^(.+)\.([^.]+)$/) {

         $path = $1;

         unshift @subpaths, $2;

      }

   }

   if (defined($val)) {

      foreach (@subpaths) {

         $val = $val->{$_};

      }

   }

   return $val;

}

----

so if $self->{$path} does not exist and $path !~ /^(.+)\.([^.]+)$/ it just loops forever on $path adding a else {last;} fixes this