stumpr's Accepted Solutions

Yes, in the HostStorageSystem (of an ESXi host), you can get the status of the adapter.... vSphere 5.5 Documentation Center $HostStorageSystem->{'storageDeviceInfo'}->{'hostBusAdapter'}->[$i]->{'status'} The hostBusAdapter is an array of devices, so you'll have to enumerate them.

use strict; use warnings; use VMware::VIRuntime; Opts::parse(); Opts::validate(); Util::connect(); my ($sc, $datastoreNS, $ds, $path, $supported); $sc = Vim::get_service_content(); $ds = Vim::find_entity_view(view_type => "Datastore", filter => { 'name' => 'ds-nfs-01' }); $datastoreNS = Vim::get_view(mo_ref => $sc->datastoreNamespaceManager); $supported = $ds->{'capability'}->{'topLevelDirectoryCreateSupported'}; die "datastoreNamespaceManager is not supported on this datastore (topLevelDirectoryCreateSupported=1)" if $supported; $path = $datastoreNS->CreateDirectory(datastore => $ds, displayName => "TestDir/"); print "New directory created: $path\n"; But bear in mind this call is only for datastores that DO NOT support topLevelDirectoryCreateSupported capabilities (vSphere 5.5 Documentation Center ) You'll need to use FileManager otherwise: use strict; use warnings; use VMware::VIRuntime; Opts::parse(); Opts::validate(); Util::connect(); my ($sc, $fm, $dc, $path); $sc = Vim::get_service_content(); $fm = Vim::get_view(mo_ref => $sc->fileManager); $dc = Vim::find_entity_view(view_type => "Datacenter", filter => { 'name' => 'DC01' }); $path = "[ds-nfs-01] TestDir"; $fm->MakeDirectory(name => $path, datacenter => $dc, createParentDirectories => 1); print "Directory successfully created\n";

You'll have to enumerate all the devices in config.hardware.device, then look for the raw disk backing type (to select the RDM).  Then, look at the disk unit number.  Then use it's controllerKey value to get the controllers in config.hardware.device with the matching key, and then get it's busNumber value.  Then it's busNumber:UnitNumber for the SCSI ID.  You'll probably want to get all SCSI IDs in use (use a hash such as BusNumber:UnitNumber => 1).  Then you can quickly lookup the first available bus number.  This is what I typically do for finding a free SCSI ID for adding a new disk (including RDMs).

It's COW with fork.  So if your child calls into the API, it will impact the parent's API session. You want to be sure you clear the VIM global.  You might want to initialize a new VIM session using the same session id from the parent in the child.  So two sockets.  Just be sure one doesn't disconnect before you're done with it.  You can change the behavior on VIM going out of scope (undef) with "unset_logout_on_disconnect()" on the VIM object so it will not close the session if a child or parent is destroyed.  Then be sure you call logout on your own.

The resourceConfig.entity is a ManagedObjectReference, to get the name you'll have to Vim::get_view() against that moref. But you could also do this a different way, such as using begin_entity in your find_entity_views() call. use strict; use warnings; use VMware::VIRuntime; $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; my %opts = (   pool => {   type => "=s",   variable => "pool",   required => 1,   }, ); Opts::add_options(%opts); Opts::parse(); Opts::validate(); Util::connect(); my $pool_name = Opts::get_option("pool"); my $pool_view = Vim::find_entity_view(view_type => "ResourcePool",   properties => ['name'],   filter => {'name' => $pool_name}); die "Failed to locate resource pool '$pool_name' in the vcenter inventory" unless $pool_view; # Obtain all inventory objects of the specified type my $e_vm = Vim::find_entity_views(view_type => 'VirtualMachine',   properties => ['name'],   begin_entity => $pool_view); my $count = 0; foreach (@$e_vm) {         my $vmName = $_->{'name'};         if (!($vmName =~ m/EdgeGW/i) && !($vmName =~ m/^vse/i)){                 $count++;         } else {                 print "Checking... VMName: ".$vmName."\n";         } } printf("TotalVMs:%d \n",$count); Util::disconnect();

The add/edit operations are for the groups, but the group contents will just be low level array edits. Take a look at the attached sample script, I tested it and it's working.  Basically the logic is the same, the difference is you edit the group, but just add the vm moref of the vm you want to add to the group by just sending in an updated array of vm morefs. perl addVm2DrsGroup.pl --server=172.16.254.50 --username=administrator@vlab --password=* --cluster=CLU01 --drsgroup=group1 --vm=recovery-03

It's tucked away in the ClusterConfigInfoEx data. So you get your cluster(s) and then look at the following - $cluster->{configurationEx}->{group} There are two types of groups, Host and Vm.  You can then check the type for VM groups and get the list of members.  You may also have to look at $cluster->{configurationEx}->{rule} if you want to see if its an affine or disaffine rule group.

One simple way could be to use Vim::get_service_url().  This will return the full URL which you can parse.  I'm not sure if there is a simple host portion, but you could instantiate a URI object from the service_url and extract the host part.

The SDK logs you out by default when the VIM global (or instance scalar) goes out of scope (it's in the deconstructor).  Try calling unset_logout_on_disconnect(). $vim->unset_logout_on_disconnect(); And make sure you aren't calling out logout().

There's a built in function that does that for you.  It recursively walks up the path to the root.  It's not the best in terms of performance, but if you're not doing large environments in bulk for a large number of managed entities, it will work just fine - #!/usr/bin/perl use strict; use warnings; use VMware::VIRuntime; use Data::Dumper; my %opts = (      vmname => {      type => "=s",      variable => "VMNAME",      help => "Display name of virtual machine",      required => 1,      }, ); Opts::add_options(%opts); Opts::parse(); Opts::validate(); Util::connect(); my ($vm, $name, $path); $name = Opts::get_option('vmname'); $vm = Vim::find_entity_view(view_type => "VirtualMachine", filter => { name => $name }); die "Failed to find virtual machine with name '$name'" unless $vm; $path = Util::get_inventory_path($vm ,Vim::get_vim()); print "VirtualMachine '$name': $path\n"; BEGIN {      $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0; } perl vm-path.pl --username=administrator@vlab --password=VMware1! --server=172.16.254.81 --vmname=DC2_C4_RP3_VM36 VirtualMachine 'DC2_C4_RP3_VM36': DC2/vm/DC2_C4_RP3_VM36 You could also look at some scripts floating around in the samples, this one does it's own recursive function to walk up the tree to get datacenter names. http://communities.vmware.com/docs/DOC-9614 You could modify that script to get similar results. If you had to get paths for a lot of entities in a large environment, you might want to pre-fetch and generate a hash map of all the parent and name properties,then walk that yourself instead of calling back to vCenter each time.

config.memoryReservationLockedToMax is probably what you are looking for - Vim::find_entity_views(      view_type => 'VirtualMachine',      begin_entity => $datacenter_view,      properties => ['name','config.guestFullName','config.memoryReservationLockedToMax'],      filter => {           'config.guestFullName' => qr/Windows/,           'runtime.powerState' => 'poweredOn',           'config.memoryReservationLockedToMax' => qr/false/,      } ); That should do the trick.

I had no idea what WHMCS was, had to look it up. Yes, the vSphere (and ESXi) VIM API is available by default.  If you don't license ESXi, however, it will be read only after evaluation has ended. I'm guessing you want to use Perl, in which case you can install the VI Perl SDK.  There are sample programs and a ton of example scripts on the forums (look at the VMware Perl Developer forums for more relevant information).

You definitely can do it in Perl.  I don't have a working example, but maybe William will when he catches this thread If I get some free time tomorrow, I'll try to put something together to get you started, but you can also just map out the logic from LucD's script. Basically Get-View is equivalent to Vim::get_view() and the New-Object calls would need to be mapped to the object type in Perl  For example, instead of New-Object VMware.Vim.DVSConfigSpec, it would be $spec = DVSConfigSpec->new( );

The pattern (the same in any language kit, but some may abstract some of the lower-level details) is the following - gom_mor = RetrieveServiceContent().guestOperationsManager // Some language kits require you instantiate a GuestOperationsManager object using the managed object reference provided by ServiceContent (gom) gomfm = gom.fileManager // This returns another moref, again some language kits handle it differently and you may not need to instantiate the object (fetch it's properties) auth = new NamePasswordAuthentication() // subclass of GuestAuth object auth.username = "username" auth.password = "password" auth.interactiveSession = false // usually false, basically should it initialize a user environment for the process gomfm.auth = auth moref = virtualmachineMoRef // have to get this by querying the vCenter inventory guestFilePath = "c:/coolfile.txt" fileAttributes = new GuestFileAttributes() // use default or set appropriately fileSize = coolfile_bytes // important, this determines the buffer when you submit the PUT request later for the transfer overwrite = false // who would ever want to overwite coolfile? put_url = InitiateFileTransferToGuest(gomfm, moref, guestFilePath, fileAttributes, fileSize, overwrite) // most language kits add this function to the gomfm itself so -- put_url = gomfm.InitiateFileTransferToGuest(moref, guestFilePath, fileAttributes, fileSize, overwrite) Then you have to do an HTTP PUT request to that put_url, set your content-length header to the bytes you set in fileSize.  Similarly with the content-type.  Your language may have a simple PUT library that does it all for you of course, William used Perl's LWP to do the PUT. You probably are having issues b/c you technically need to get contents of GuestOperationsManager to get the GuestFileManager, AuthManager, etc.  You can't just jump to GuestFileManager, you need the MOREF value you get from the GuestOperationsManager.guestFileManager for the InitiateFileTransferToGuest().  What language kit are you using for your project?

That's actually pretty simple.  Here's an example that does it with good performance. #!/usr/bin/perl -w # by Reuben Stump (http://www.virtuin.com) use strict; use warnings; use VMware::VIRuntime; Opts::parse(); Opts::validate(); Util::connect(); my ($vms, $hosts, %vm_map, %host_map); $vms = Vim::find_entity_views(view_type => "VirtualMachine",      properties => ['name']); $hosts = Vim::find_entity_views(view_type => "HostSystem",      properties => ['name', 'vm']); %host_map     = map { $_->{mo_ref}->{value} => $_ } @$hosts; %vm_map       = map { $_->{mo_ref}->{value} => $_ } @$vms; foreach my $host (@$hosts) {      print $host->{name} . "\n";      foreach my $vm ( @{$host->{'vm'} || []} ) {           print "   " . $vm_map{$vm->value}->{name} . "\n";      } } Util::disconnect(); BEGIN {      $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; } Sample run: $ perl ListFolders.pl --username=administrator@vlab --password=VMware1! --server=172.16.254.51 vlab-esx-01.vlab.local    TestVM1 vlab-esx-02.vlab.local    TestVM2 You can add more values to the properties named argument in the find_entity_views() method.  If you don't mind a big performance hit, you can remove the properties => [ ] argument and it will retrieve all properties (but this can be very slow in large environments). If you're curious about performance of the Perl SDK scripts against vCenter, take a look here: http://www.virtuin.com/2012/11/best-practices-for-faster-vsphere-sdk.html You can also look at the VI SDK for Perl documentation, which covers the *_view() methods in more detail.

It's because you wrapped the 'die' handler - $SIG{__DIE__} = sub { Util::disconnect(); }; The check_fault() method of the Util package uses Carp::confess, which is another version of the die signal.  You're basically masking the die signal. The VI Perl SDK will logout on disconnect by default, so you shouldn't need the signal handler for die to call disconnect.  Comment out your signal handler and it will work as expected.  There are functions in the VICommon.pm module to control the logout on disconnect behavior if you want to change the logout on disconnect behavior.

It actually returns the new VM ManagedObjectReference, you'll have to call get_view() on it to get the actual VM and it's properties. Take a look at the quick sample I attached.  It shows how to get and convert the ManagedObjectReference result with both CloneVM_Task() and CloneVM() into a VirtualMachine entity. $ perl CloneVMExample.pl --username=administrator@vlab --server=172.16.254.50 --password=VMware1! --vmname=SourceVM --dcname=DC01 New VM 'CloneVM()-Test' cloned successfully with CloneVM(). CloneVM_Task() completed successfully. New VM 'CloneVM_Task()-Test' cloned successfully with CloneVM_Task().