vCNS 5.1.x Tasks Not Displayed

There is a condition in the current releases vCNS Manager that causes the tasks tab to not display tasks at all.  This condition will be fixed in an upcoming release.   This article provides a workaround for an environment where an upgrade is not feasible for whatever reason.Image

If there are any tasks initiated by a user that no longer exists, the VSM tasks tab will display an error in the UI. The logs will also display a warning.

  vsm#show manager log follow

Look for the following warning message:

2013-05-23 21:27:35.806 GMT  WARN http-443-exec-315 DefaultExceptionLogger:35 – The following exception occurred during request processing by the BlazeDS MessageBroker and will be serialized back to the client:
flex.messaging.MessageException: Internal server error has occurred.

Caused by: javax.persistence.EntityNotFoundException: Unable to find com.vmware.vshield.vsm.usermgmt.model.UserInfo with id userinfo-40

The following work-around requires linux console access – in most cases it should be completed by VMware Global Support Services.

Run the psql client:
psql -U secureall

Execute :
update task set user_info=null;

Refresh the tab.  Tasks should now be displayed.

Image

Advertisements

vSphere 5.1 Networking Improvements – Network Health Check Improvements

In my previous post I mentioned the welcome additions to the esxcli.

Also very much welcomed are operational improvements  to the VDS and to the troubleshooting toolset.

In this release, the VDS gets the following improvements

Network health check

VDS config backup and restore

Management network rollback and recovery

Distributed port – auto expand

MAC address management

LACP support 

BPDU filter

I want to focus on the details surrounding the Network health check improvements 

Per the 5.1 – What’s new – Networking whitepaper  “With Network health check in vSphere 5.1, the VLAN, MTU and Adapter teaming are monitored at 1 minute intervals using proving packets (sent and received via the physical uplink interfaces of the vDS.  Depending on the config on the connected network device, REQ and ACK packets will be received or dropped, indicating a config issue, and displaying a warning in the vSphere client.”

When we open up the vSphere 5.1 client – these new alarms can be found at the Datacenter object (not the DVS object):

vSphere Distributed Switch MTU matched status

vSphere Distributed Switch MTU supported status

vSphere Distributed Switch teaming matched status

vSphere Distributed Switch VLAN trunked status

These new alarms have their trigger details hidden from viewing or editing from within the vSphere client.  The tab displays this message:

Image

Here’s the alarm detail from the PowerCLI commandlet:

PS C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-AlarmDefinition -Name “*Switch*”| Format-List

Entity : Datacenters
Description : Default alarm to monitor changes in vSphere Distributed Switch vlan trunked status.
Enabled : True
Name : vSphere Distributed Switch vlan trunked status
ExtensionData : VMware.Vim.Alarm
ActionRepeatMinutes : 0
Id : Alarm-alarm-57
Uid : /VIServer=networkdojo\grosas@localhost:443/Alarm=Alarm-alarm-57/

Entity : Datacenters
Description : Default alarm to monitor changes in vSphere Distributed Switch MTU matched status.
Enabled : True
Name : vSphere Distributed Switch MTU matched status
ExtensionData : VMware.Vim.Alarm
ActionRepeatMinutes : 0
Id : Alarm-alarm-58
Uid : /VIServer=networkdojo\grosas@localhost:443/Alarm=Alarm-alarm-58/

Entity : Datacenters
Description : Default alarm to monitor changes in vSphere Distributed Switch MTU supported status.
Enabled : True
Name : vSphere Distributed Switch MTU supported status
ExtensionData : VMware.Vim.Alarm
ActionRepeatMinutes : 0
Id : Alarm-alarm-59
Uid : /VIServer=networkdojo\grosas@localhost:443/Alarm=Alarm-alarm-59/

Entity : Datacenters
Description : Default alarm to monitor changes in vSphere Distributed Switch teaming matched status.
Enabled : True
Name : vSphere Distributed Switch teaming matched status
ExtensionData : VMware.Vim.Alarm
ActionRepeatMinutes : 0
Id : Alarm-alarm-60
Uid : /VIServer=networkdojo\grosas@localhost:443/Alarm=Alarm-alarm-60/

Not quite satisfied, I took a peek at the VMware vSPhere 5.1 Documentation Center; there I found the new objects satisfactorily documented.  🙂

On that note – I need to throw in the towel and call it a night.  Happy learning to any and all.

– Gabe

 

Exciting additions to esxcli with 5.1 plus found an oddity with esxicli maintenanceMode.

In esxi4.1 – you can catch the beginnings of esxcli

The name space is greatly expanded en esxi5.0 showing true commitment by VMware to its standardization going forward.

The update in esxi 5.1 is magnificent.  There are 82 commands added; to my joy 47 of them are in the *network* namespace.  We are even greeted with a brand new primary namespace:

esxcli network 5.0 on the left / esxcli network 5.1 on the right:

With the latest update – maintenance mode operations have also been added to esxcli.

esxcli system maintenanceMode get gives you the maintenance status of the host (Enabled or Disabled)

esxcli system maintenanceMode set provides two command options :

esxcli system maintenanceMode set -e -t 30 should theoretically set our host into maintenance mode, and sets the timeout to enter maintenance to 30 seconds.  Oddly enough it doesn’t work.

The command errors stating that the -e option requires a value…

Ran it again with some common sense applied were directions lacking

esxcli system maintenanceMode set -e yes -t 30

And voila! success!

To close the loop, I confirmed the following command removes maintenance mode:

esxcli system maintenanceMode set -e no

On that note – I need to go; more command exploration when I come into some free time.

– Gabe