Unable to Schedule Reports in vROPs 6.3 using AD Users

If you are like most of my customers, when deploying vRealize Operations Manager the automatic user integration that happens when registering a vCenter adapter is totally sufficient to provide sys admins with access to the solution.

As you may be aware, vROPs Roles such as ContentAdmin map to individual vCenter SSO Role Privileges (All -> Global -> … vRealize Operations …).

Unfortunately, there is one caveat in the documentation to be aware of – scheduling reports in vROPs is not possible by vCenter Server users.  This is despite the fact that ContentAdmin has the vROPs permission Content -> Reports Management -> Schedule (!).

Generating Reports
vCenter Server users cannot create or schedule reports in vRealize Operations Manager.

http://pubs.vmware.com/vrealizeoperationsmanager-63/topic/com.vmware.vcom.core.doc/GUID-1200D430-CFE6-416B-8AC8-FE9FADF52BCF.html

So, the options are 1) use a local vROPs account to schedule reports, 2) setup an authentication source in vROPs to use Active Directory directly.  Assuming that your scheduled reports do not change too often, solution 1 is probably sufficient for most small or medium sized environments.

 

ESXi 6.0+ and 3PAR, PDL issue causing host to hang

With certain versions of HPE 3PAR and ESXi 6.0, hosts can hang, crash, or fail to install. If this occurs, you will see many PDL errors in the ESXi logs against LUN 256.

This can be resolved by setting an ESXi limit to prevent visibility of LUN 256, or by applying a patch on the 3PAR.

From the HPE release notes:

“Addresses an issue in which some VMware versions may send unsupported commands to the PE LUN (LUN 256). Such commands are currently returned with sense data 0x5 0x25 0x0. This response causes VMware to encounter an unexpected PDL alert on the LUN. The response is now changed to 0x5 0x20 0x0 to avoid this issue.”

This problem is exposed in ESXi 6.0, when the SCSI device limit was increased to 1024 devices – range LUN 0 to LUN 1023.  In ESXi 5.5, the limit was 256 devices, LUN 0 to LUN 255 – as a result the ESXi 5.5 hosts are not able to see the PE LUN and do not query it.

 

Resources and Reference

  • https://www.virtual-allan.com/esxi-6-update-2-pdl-errors-on-vvol-pe-device/
  • https://communities.vmware.com/thread/533806?start=0&tstart=0
  • https://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf
  • https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf
  • https://kb.vmware.com/kb/2144657
  • https://kb.vmware.com/kb/2004684

Checking firmware version of NIC driver on ESXi 6.0

To check for a problem firmware version on HP blades, I used the following snippet.  It leverages a small hashtable as a parameter to get-esxcli newish “V2” format for calling esxcli commands remotely.

Thought it was kind of fun.

vSphere 6.5 GA Available for Download!

The vSphere 6.5 bits are available for download now!  Very exciting… especially the new VCSA Migration Tool!  I think this will be great for a lot of customers looking to migrate from existing Windows vCenter environment to the fully supported, easy to use VCSA vCenter Server Appliance, which has been essentially feature parity since 6.0.

If you haven’t already, read the October announcement blog entry for more information:

Set Edge Default Route / Default Gateway using vRealize Orchestrator

Scenario

As part of some workflow I am building for a customer, I need to automate assigning the default route (default gateway) for an vCNS Edge appliance, using vRealize Orchestrator.

Problem

The provided NSXDefaultRoute, which can be used with NSXEdgeManager.setDefaultRoute() per the documentation, has read-only properties and the NSX Orchestrator Plugin 1.0.4 provides no further documentation to my knowledge on how to use this scripting object:

Solution

There are two accessors available as part of the NSXDefaultRoute scripting object.  To my knowledge, these are not documented.

  • NSXDefaultRoute.setvNicIndex(string vnicindex)
  • NSXDefaultRoute.setGatewayIpAddress(string ip)

Note, there is no accessor for MTU, although as shown below that is an option in the default gateway config.

This example code works with vRealize Automation 7.1 and the embedded Orchestrator service.

Setup a new workflow with these variables as input, and the below code in a scripting task, and it should work for you too.

Input Parameters

  • Variable nsx is a NSX:Connection object specifying my vCNS Manager in vRO inventory
  • Variable edgeId is a string object specifying the edge objectId, such as edge-28

Here’s the results after running this code