vSphere

I know how to do something like this to print a value for guestId:

my $basevm_view = Vim::find_entity_view(view_type => 'VirtualMachine', filter => { 'name' => 'myguestvmname' } );

print "my guestId = " . $basevm_view->summary->config->guestId . "\n";

Can I get the guestId using the accessor method? If so, what is the perl code snippet that would demonstrate this? I'm trying to understand what all of the accessor methods are for, so if they aren't for this type of thing, a quick explanation would really help this newby out.

Thanks.

The find_entity_view() function just returns back managed object referenced and you can provide filters to help narrow down that list. There are no accessor method for the individual properties such as guestId or powerState. So you will need to save that into a variable or directly print it out, assumign the value is not NULL/etc.

This is based on how the vSphere SDK for Perl client stubs were created, you can technically create your own in the perl modules but they just don't exists. If you take a look at Steve Jin's VI Java SDK, he has not only create a Java SDK but also create most if not all accessor methods/etc. for the various properties so you could do something like vm.getGuestId() and you would have the guestId returned back to you.

Hopefully this makes sense.

Though this is a little outdated, it's still relevant to the vSphere SDK for Perl, but check out this document for more details - http://www.vmware.com/support/developer/viperltoolkit/doc/perl_toolkit_appliance_idx.html. It goes into detail on describing the available methods and how they're used and what they return/etc.

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

As William pointed out, there aren't really any direct accessor methods and as you found out, the object's are exposed as a series of nested, anonymous hashes.

You can create a utility function if you would like a cleaner accessor. This is probably a good idea since you can build exception handling into it and avoid a lot of messy test code in your main logic branch.

Something like the following would be a good starting point:

#!/usr/bin/perl

use strict;
use warnings;

use VMware::VIRuntime;

Opts::parse();
Opts::validate();

Util::connect();

my ($host_views);							

$host_views = Vim::find_entity_views( view_type => "HostSystem",
									 );

foreach ( @{$host_views} ) {
	print "summary.config.name = " . get_value($_, "summary.config.name") . "\n";
	print "summary.managementServerIp = " . get_value($_, "summary.managementServerIp") . "\n";
	print "summary.bogusProperty = " . get_value($_, "summary.bogusProperty") . "\n";
}

sub get_value {
	my ($entity, $value_path) = @_;
	
	my @keys = split(/\./, $value_path);
	
	my $key_ref = $entity;
	foreach my $key ( @keys ) {
		eval {
			$key_ref = $key_ref->{$key};
		};
		if ($@ || not(defined($key_ref)) ) {
			return '';
		}
	}
	
	return $key_ref;
}

Sample Output:

summary.config.name = vlab-esx-01.vlab.local
summary.managementServerIp = 
summary.bogusProperty = 

That function will at least catch undefined properties (not all properties from the SDK are guaranteed to be set and accessing them can raise an exception). It does this by making it an empty string to avoid perl warnings about undefined concatenations.

Bear in mind if you use properties => named arguments to your find_entity_view calls, you'll need to access the properties as a full key path. For example, if asked for just "summary.config.name" in such a manner, you'd access it from the host object like $_->{"summary.config.name"}.

You could easily enhance the makeshift accessor method above to check for that possibility (have it just eval the full key path, if that raises an exception, go through the key list as usual).

This might help if you're finding the long, nested anonymous hash references a bit frustrating to work with. I know I find it ugly when I have to deal with numerous, nested hash refs and validate each in the chain is not undefined (unset by the SDK returnval). I use similar accessor methods to avoid my code getting ugly for more complicated perl work.