stumpr's Accepted Solutions

'Datacenters' is the name of the rootFolder.  The next object type in the tree is the defined Datacenter entities.  Take a look at the ServiceInstance object to see the tree structure in the API documentation. ServiceInstance In the vSphere Client UI, the rootFolder is hidden and they instead show the vCenter name. If you want to emulate the appearance of the vSphere UI, you'll have to hide a few of core folder objects, but they are there in the actual inventory tree in code.

HostSystem.runtime.standbyMode http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.HostSystem.StandbyMode.html Enum Constants NAME DESCRIPTION entering The host is entering standby mode. exiting The host is exiting standby mode. in The host is in standby mode. none The host is not in standy mode. And it is not in the process of entering/exiting standby mode.

There are some methods in the API that have a non-task option, such as UpgradeTools.  In those cases, you can call either, but I'm not sure how offical the non _task() version of the call will be in the future. If you use the Task version, you have to query the task to get the state of the task execution, including error code.  If you use the non-task version, you can probably rely on an eval to catch the SOAP error message.

You just do an eval block on some action, if you get an unauthenticated exception, try a proper login.  I think checking nmap and port availability is a bit extreme unless you're looking to write a tool to monitor the availability of the SDK service. By connection are you testing a particular session?  You could have a non-authenticated session open to the SDK, it won't be able to do much, but it is technically open on the port level.  It might also be possible to have an active session (cookie saved away) that may not have an open TCP socket.  I'm not 100% sure on the later, but I have created multiple web tools on different source systems using the same sessionID for activity.

Give the following a try: $host_view = Vim::find_entity_view( view_type => 'HostSystem', filter => { 'name' => $host_name } ) || die "Failed to get $host_name!"; $vm_view = Vim::find_entity_views (     view_type   =>  'VirtualMachine',     filter           =>  {  'name' => $vm_name },     begin_entity => $host_view,     }, );

You could try one of the following - 1.  if ($vm->{'summary.config.numVirtualDisks'} > 2) { .... } 2.  $diskCnt = grep { $_->isa('VirtualDisk') } @{ $vm->{'config.hardware.device'}}; The above assumes you got your $vm with a property filter like following: $vms = Vim::find_entity_views( view_type => 'VirtualMachine', properties => [ 'summary.config.numVirtualDisks', 'name', 'config.hardware.device' ] ); foreach my $vm ( @{ $vms } ) {      ... }

Your welcome.  It could be made faster, but the added code complexity probably isn't worth it if the runtime you have now is sufficient.  You can probably add additional data to your report without too much slow down. You may also find the script runs faster or slower depending on what's going on in your virtual center system. Thanks for the update on the success!

You should be able to get the information from the 'guest.net[].ipConfig.dhcp.ipv4.enable' property of the virtual machine.  Otherwise, you'll probably have to use some in-guest automation with VIX or GuestOperationsManager to check the networking configuration. The ipConfig property was added in vSphere 4.1, so it probably won't be of use on vCenter 2.5/ESX(i) 3.x.

vCenter has requirements for installation - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003882 vmrun won't get you enough functionality to emulate CloneVM_Task(). You'll have to do something similar to the following: 1. Create a new VM with virtual h/w configurations similar to the source VM 2. Using the VirtualDiskManager, copy all the VMDK files of the source VM to the new VM Datastore folder 3. Add newly copied VMDKs to the new VM 4. Copy the nvram if you wanted to copy the BIOS settings of the source VM 5. Configure any changes required to the VM.  For example, reconfiguring the network backing. 6. If you need guestOS customization, you will either need a source VMDK with sysprep or boot scripts configured to do a firstboot reconfiguration or leverage the VIX/GuestOperationsManager APIs to run in-guest scripts. You can do most of this through the vSphere API.  The VIX operations are rolled into the vSphere 5 API, but you can also download the VIX operations (vmrun is built on these) from the VMware web site.

There is a slightly easier way than traversing the inventory tree. If you just want entities under a datacenter, you can use begin_entity in your find_entity_view* calls. #!/usr/bin/perl -w use strict; use Data::Dumper; use VMware::VIRuntime; my %opts = (   datacenter => {     type      => "=s",     help      => "Please enter the Datacenter name",     required => 1,   } ); Opts::add_options(%opts); Opts::parse(); Opts::validate(); Util::connect(); my $dc = Opts::get_option('datacenter'); my $dc_view = Vim::find_entity_view ( view_type => "Datacenter",   filter => { name => $dc },   properties => [ 'name' ] ); die "No Datacenter named '$dc' found!" unless $dc_view; my $vm_views = Vim::find_entity_views( view_type => 'VirtualMachine', begin_entity => $dc_view ); foreach my $vm (@$vm_views) {   print "vm: " . $vm->name . "\n"; }

I spent a lot of time on this a few years ago, but I haven't spent much time on it recently...I may be rusty.  If I recall, however, the session not authenticated (assuming your code pattern is correct) was typically a failure to include the WITH_COOKIES macro in the build process. Bear in mind, all the gSOAP compile products as well as your program executeable had to include WITH_COOKIES. You'll need -DWITH_OPENSSL -DWITH_COOKIES.  I used to also include -DWITH_GZIP, but I never tested the GZIP support (should be automatic for compression). I ended up creating some Makefiles to generate static and dynamic libraries, particularly with the long compile times you get with the huge vSphere SDK WSDL.

As William points out, it won't be supported, but you can use the VMware Perl SDK easily enough on any Perl platform (I've done it this way with Window as well).  I've done this specifically on Ubuntu and OS X over the years. Install the module requirements as indicated in the "vSphere SDK for Perl Source Code Installation on Linux".  In the source package, copy the VMware folder in vmware-vsphere-cli-distrib/lib/VMware/share from the Linux Perl SDK download tarball to your Perl path.  For the required modules, you can use PPM, CPAN or apt to get the packages. I've run this way for years with no issues, but that is obviously not an official support statement You should be able to just avoid setting a proxy during the installer.  It's there in case it's required for downloading module dependencies.

You'll want to use RetrievePropertiesEx.  There's a whole section of the developer guide on how to build TraversalSpecs for property retrieval.  It's a bit complex, but it does give a lot of micro-management of what objects and properties you want from the inventory.

It's done when you call Util::connect() (which calls the login function). Once you have successfully logged in, you can get the ServiceContent object by calling Vim::get_service_content().  If you were to enable HTTP mode and capture the SOAP envelopes, you'd see the RetrieveServiceContent call.  In a non-script SDK, such as Java, C++, raw SOAP, etc, you'd have to make this call, establish a sessionId cookie, and perform a login within that sessionId cookie to perform most functions against the VIM SDK. In the Perl SDK you can do the following if you want the ServiceContent (and references to many of the management objects in the inventory): $sc = Vim::get_service_content(); print $sc->about->fullName . "\n"; my $rootFolderMOR = $sc->rootFolder; Also, if I recall correctly, object views will have the Vim & ServiceContent as a property in their object data. print $vm_view->{'vim'}->{'service_content'}->{'about'}->{'fullName'} . "\n"; Since the ServiceInstance has the same MOREF value regardless, usually you'll just create a ManagedObjectReference directly and use it as a parameter to RetrieveServiceContent. my $ServiceInstance = ManagedObjectReference->new( type => 'ServiceInstance', value => 'ServiceInstance' ); my $ServiceContent = Vim::RetrieveServiceContent( _this => $ServiceInstance); # ... Login called next ... $ServiceContent->Login( _this => $ServiceContent->sessionManager, userName => $username, password => $password); In fact, if you look at the Login() function in VICommon.pm in the Perl SDK, you'll see that it does exactly the same process (with some other code to handle SDK versions and such).

layoutEx isn't something you'll have to get_view on (it's not a ManagedEntity, just a property of a VirtualMachine).  You'll only want to call get_view on a ManagedObjectReference property. #!/usr/bin/perl use strict; use warnings; use VMware::VIRuntime; Opts::parse(); Opts::validate(); Util::connect(); my $vm_views = Vim::find_entity_views( view_type => 'VirtualMachine', properties => ['name', 'layoutEx', 'summary', 'storage'] ); foreach my $vm ( @$vm_views ) {    print $vm->{'name'} . ":\n";    my $files = eval { $vm->{'layoutEx'}->{'file'} } || [ ];       foreach my $file ( @$files ) {          print "   File name: " . $file->{'name'} . "\n";       } } Util::disconnect();

You should call RetrieveServiceContent, then you can call Login.  If the credentials are incorrect, you'll get an invalid login fault.  If you can then get the SessionManager and call SessionIsActive on the current session if you want to validate if a session connection through cookies is still valid (if you were say storing and reconnecting to the VIM instance at a later period). Once you're logged in, the cookie session id is the actual "credential" used for all SOAP communication.  If you don't send that cookie, then you won't be "logged" in.  You can terminate the session with Logoff or by killing it through the vSphere UI (it will eventually time out as well). Take a look at Project Onyx: http://labs.vmware.com/flings/onyx.  It provides a way to capture SDK calls, you can use it to formulate the soap envelopes by running it through the vsphere client or script first.