I've used Ansible with raw commands vs ESXi (many of the core modules will not work as some of the python libs are not there). That worked well for doing bulk operations and retrieving command r...
See more...
I've used Ansible with raw commands vs ESXi (many of the core modules will not work as some of the python libs are not there). That worked well for doing bulk operations and retrieving command results from many ESXi hosts. The other option is to talk to the vCenter API with one of the SDKs. Since you mentioned Python, PyVmomi would be your best bet (vmware/pyvmomi · GitHub). You may have some gaps in information you want (need to know more specifics). But the PCI and device info is basically available for storage and network adapters. Just have to dig and pull it out as a report that is useful for your requirements.
You may need to use url encoding to match the string in the API fields. They'll be converted to their %## values (depends on the character). This is documented (somewhat) in the API documentati...
See more...
You may need to use url encoding to match the string in the API fields. They'll be converted to their %## values (depends on the character). This is documented (somewhat) in the API documentation:
Name of this entity, unique relative to its parent.
Any / (slash), \ (backslash), character used in this name element will be escaped. Similarly, any % (percent) character used in this name element will be escaped, unless it is used to start an escape sequence. A slash is escaped as %2F or %2f. A backslash is escaped as %5C or %5c, and a percent is escaped as %25.
I usually pass the strings through a URL encoding library for comparison. Some of the SDK kits will do the URL encode and decode for you automatically. You can also look at the MOB, see if this provides better detail on the actual display name content.
Yes, you'll need one of the automation kits (Perl, Python, PowerCLI, VIPerl CLI, etc). You'll also need appropriate credentials with rights to modify the portgroup backing the VLAN.
If you use get_view() and just need it to call a method, I recommend you use properties => ['name'] to minimize the SDK overhead: $thisDatastore = Vim::get_view(mo_ref => $dsRef, properties =>...
See more...
If you use get_view() and just need it to call a method, I recommend you use properties => ['name'] to minimize the SDK overhead: $thisDatastore = Vim::get_view(mo_ref => $dsRef, properties => ['name']); You can also 'hack' out an entity object view as well, if you really wanted to avoid another SDK call to the API (though I'd recommend the get_view() process):
$thisDatastore = new Datastore();
$thisDatastore->{'mo_ref'} = $dsRef;
Yes, if a DB maintenance job runs it'll clean up old events from the database. So it's not really a PyVmomi or SDK issue, but just the fact the actual event is cleaned from the DB. The disk c...
See more...
Yes, if a DB maintenance job runs it'll clean up old events from the database. So it's not really a PyVmomi or SDK issue, but just the fact the actual event is cleaned from the DB. The disk creation time stamp isn't a bad idea, that's creative. I guess the negative there is you won't be able to get who created the VM, just the creation time. If you have control of your VM creation process, you can add some CustomValue tags in vSphere to the VM for the creation date. I had a few customers who used a daily script or vCO workflow to get the VMCreated events, turn those into CustomValues (so they don't get pruned on a DB maintenance job) and that works well (since it's rare that you'll have VM events wiped in the 24 hr period of the script/workflow task).
Yes, you can set those key-value pairs in the extraConfig section of the VM (it's the same as the VMX settings). In your clone spec, you'd set an array of extraConfig options you want adde...
See more...
Yes, you can set those key-value pairs in the extraConfig section of the VM (it's the same as the VMX settings). In your clone spec, you'd set an array of extraConfig options you want added to the VM.
In your url, you're missing the host portion of the URI. Looks like something isn't being passed into the script parameters (or your ENV vars are not set properly). https://:443/sdk/vimServic...
See more...
In your url, you're missing the host portion of the URI. Looks like something isn't being passed into the script parameters (or your ENV vars are not set properly). https://:443/sdk/vimService.wsdl Maybe double check you have the right host information set in nagios.
You won't need the property collector, but you'd get the EventManager object from the ServiceContent. It has a few methods you can then use to query. The hard part will be pinning down which ev...
See more...
You won't need the property collector, but you'd get the EventManager object from the ServiceContent. It has a few methods you can then use to query. The hard part will be pinning down which events you care about.
You can query for Tasks, match them up with the VirtualMachine(s). For the username who created the snapshot, it's usually in the 'reason' property: myTask.reason.userName You can match up...
See more...
You can query for Tasks, match them up with the VirtualMachine(s). For the username who created the snapshot, it's usually in the 'reason' property: myTask.reason.userName You can match up the task with VirtualMachines through 'entity' property" myTask.entity Then you can compare the ManagedObjectReference. You can also filter on entity in the TaskCollector if that works for you use case as well.
You figured it out, but because you asked for 'config.dateTimeInfo', it was stored as that hash key. You could use the get_property() method in the SDK, which will sort of try both forms: ...
See more...
You figured it out, but because you asked for 'config.dateTimeInfo', it was stored as that hash key. You could use the get_property() method in the SDK, which will sort of try both forms: $host->get_property('config.dateTimeInfo')->ntpConfig->server; Should also work: $host->get_property('config.dateTimeInfo.ntpConfig.server'); I don't use it much personally, I sort of fall back on the usual Perl hash syntax.
I never tried Retrieve* & WaitFor* in the same thread. Definitely you will have problems with WaitFor* in the same thread, but Retrieve may work since it's not really tracking updates, just a on...
See more...
I never tried Retrieve* & WaitFor* in the same thread. Definitely you will have problems with WaitFor* in the same thread, but Retrieve may work since it's not really tracking updates, just a one time pull. I'd probably just play it safe though, generate a property collector per thread (fairly simple operation).
You'll need to tap the API twice to get what you want when working with DVPGs. You can get the backing.port (which is the DVPG key), then look that up in the DVPG list to get the network name. ...
See more...
You'll need to tap the API twice to get what you want when working with DVPGs. You can get the backing.port (which is the DVPG key), then look that up in the DVPG list to get the network name. Basically you need logic to check the backing type: VirtualEthernetCardNetworkBackingInfo = standard switch portgroup VirtualEthernetCardDistributedVirtualPortBackingInfo = distributed virtual portgroup If it's a DVPG backing, then you need to cross-reference it with the DVPG object based on the key property. I usually pre-load all the DVPGs into a dictionary or hash, get the backing.port key value (if it's a DVPG) and then loop through the DVPG dictionary until the key matches. From there you can get the DVPG display name (as seen in the vCenter UI). If your tooling is using the deviceInfo (Description) field as a way to track VM->networking mapping, then that tooling will need to be updated.
Don't think so, that ties into the device label in vSphere. What's your ultimate goal? There are other places you can store arbitrary values if you need to provide some custom strings.
Unfortunately, the modules aren't versioned, every version uses the same name 'VIM25Stub.pm' in this case. The likely problem here is an older VIM25Stub.pm (from <5.5, since 5.5 introduced that ...
See more...
Unfortunately, the modules aren't versioned, every version uses the same name 'VIM25Stub.pm' in this case. The likely problem here is an older VIM25Stub.pm (from <5.5, since 5.5 introduced that object type). Might want to double check to see how many VIM25Stub.pm files are on the system, and if they are the same (simple md5sum would work). From my vSphere 6.0 VIPerl SDK install system:
$ sudo find / -name VIM25Stub.pm -type f -exec md5 {} \; 2>/dev/null
MD5 (/System/Library/Perl/5.18/VMware/VIM25Stub.pm) = 6740555623a9613b4f9a50b29b457eaf
You can just check if the package name is in the file (make sure you're getting the one that Perl is picking up in it's @INC).
$ egrep -r "HostSriovInfo" ./*
./VIM25Stub.pm:package HostSriovInfo;
./VIM25Stub.pm:VIMRuntime::make_get_set('HostSriovInfo', 'sriovEnabled', 'sriovCapable', 'sriovActive', 'numVirtualFunctionRequested', 'numVirtualFunction', 'maxVirtualFunctionSupported');
Any chance you're loading the older vSphere 5.0 API modules (VIM25Stub.pm)? If it's 5.5, should be there, if it's 5.0, might not be. Maybe check the perl path and see which module is loading by...
See more...
Any chance you're loading the older vSphere 5.0 API modules (VIM25Stub.pm)? If it's 5.5, should be there, if it's 5.0, might not be. Maybe check the perl path and see which module is loading by default?
Do you mean the new vAPI methods (content library, tagging, etc)... I'm not sure those are in the Perl SDK yet. They are REST and easy to invoke using RestClient or just LWP. If you just mean...
See more...
Do you mean the new vAPI methods (content library, tagging, etc)... I'm not sure those are in the Perl SDK yet. They are REST and easy to invoke using RestClient or just LWP. If you just mean the vSphere API 6.0 methods (old SOAP API), you can just do a source install or use the Perl SDK installer. Sorry if I misunderstood the question.
