Posted by

Gabe

Posted on

06/21/2013

Posted under

Comments

vCNS 5.1.x SSL VPN-Plus Client Proxy Settings on Mac won’t stick

Anyone out there attempting to run the SSL VPN-Plus Mac client through a proxy will quickly notice that the settings do not seem to stick. You check the box to enable proxy setting, add the configuration and click Ok.

All seems well (until you try to connect). When the settings are applied correctly, the client will reflect that the connection attempt is routed via proxy.

When you open up the proxy settings again, you see the box unchecked and the proxy configuration undefined. This is a known issue caused by a missing directory where the proxy configuration is written does not get added during install. This is slated to be fixed in a future release.

As a workaround, you can add the directory manually. Exit the SSL VPN Mac client, open up the terminal and add the directory: sudo mkdir -m 777 /opt/sslvpn-plus/naclient/users_dat

Problem solved. Open up the client, configure the proxy, and connect.

*Credit for the find to N.Albright for quickly finding the problem with dtruss*.
-Gabe

Leave a comment

vCNS 5.1.x Edge Force Sync 101

vCNS Edge Force Sync The action of synchronizing the Edge appliance to the vCNS Manager by OS reboots.

Any time a Force Sync is initiated, vCNS Manager writes the event to syslog (if enabled) [System Events for Critical Event ID 30100]. This entry is logged per edge VM, so two entries for an HA pair.

The events can be viewed in vCNS UI, under Settings & Reports > System Events:

What are the implications of a Force Sync?

I completed several Force Sync tests using timestamped ICMP requests against Virtual Servers configured on an HA Edge appliance. When the Force Sync action is initiated the job will reset the first appliance and stagger the 2nd reboot requests by ~ 30 seconds.

When Edge-0 (the first Edge VM) is reset the test virtual server VIP became ~ 10 – 11 seconds of impact (ICMP requests to the Virtual server IP fail). At the end of the 10 – 11 seconds, the Standby edge takes over the load balanced services and these become reachable for ~ 24 seconds until the 2nd VM is reset.

Once the Edge-1 (the 2nd Edge VM) is reset, the services once again become unavailable for ~ 60 seconds, until the 1st Edge VM is fully initialized.

Note: A less impactful appliance reset can be acomplished by manually resetting the standby edge, waiting at least 90 seconds for initialization – then resetting the active edge.

Note: Tests conducted using vCNS 5.1.b. As with anything, depending on your environment and configuration, your mileage may vary.

How to initiate a Force Sync from the vCNS UI:

1. Browse to the vCNS Manager
2. View Edges
3. Select Edge Gateways
4. Select a deployed Edge.
5. Click the Actions cog.
6. Select Force Sync

How to initiate a Force Sync from the vCNS REST API:

Force Sync an Edge with its vShield Manager (pg 144 of the REST API guide)
GET https://<vsm-ip>/api/3.0/edges/<edgeId>?action=forcesync

How do I view Force Sync details in the vCNS Manager logs?

1. SSH to the vCNS Manager CLI
2. Execute the command
vsm-name# show manager log follow

Inspect the logs for the following entries, related to the force sync (bold # = comment line)

# Force Sync is scheduled, assigned ID “jobdata-1831”

2013-06-16 10:53:05.058 GMT INFO http-443-exec-677 EdgeServiceImpl:744 – Successfully created forceSync job jobdata-1831 for edge ‘edge-16’
2013-06-16 10:53:05.111 GMT INFO http-443-exec-677 Publisher:509 – Scheduled job Id jobdata-1831
2013-06-16 10:53:05.165 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Force sync : Rebooting appliances for edge-16.

# Edge-0 Reset request is sent, wait for edge Init
2013-06-16 10:53:05.352 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:349 – Reset the edge appliance : ‘vm-12780’
2013-06-16 10:53:11.955 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:367 – Reboot the edge appliance : ‘vm-12780’
2013-06-16 10:53:11.958 GMT INFO pool-55442-thread-1 AbstractEdgeApplianceManager:226 – Attempt # ‘1’ to reboot the edge VM ‘vm-12780’
2013-06-16 10:53:12.027 GMT INFO pool-55442-thread-1 VirtulMachineVcOperationsImpl:99 – Rebooting VM ‘d0p1v4mgmt-vse-pub-0’
2013-06-16 10:53:12.150 GMT INFO pool-55442-thread-1 VirtulMachineVcOperationsImpl:101 – Successfully rebooted VM ‘d0p1v4mgmt-vse-pub-0’
2013-06-16 10:53:12.150 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:371 – Wait for Vse Init : ‘vm-12780’

# 30 seconds later Edge-1 Reset request is sent, wait for edge Init
2013-06-16 10:54:26.410 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:349 – Reset the edge appliance : ‘vm-12784’
2013-06-16 10:54:33.003 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:367 – Reboot the edge appliance : ‘vm-12784’
2013-06-16 10:54:33.009 GMT INFO pool-55442-thread-1 AbstractEdgeApplianceManager:226 – Attempt # ‘1’ to reboot the edge VM ‘vm-12784’
2013-06-16 10:54:33.034 GMT INFO pool-55442-thread-1 VirtulMachineVcOperationsImpl:99 – Rebooting VM ‘d0p1v4mgmt-vse-pub-1’
2013-06-16 10:54:33.185 GMT INFO pool-55442-thread-1 VirtulMachineVcOperationsImpl:101 – Successfully rebooted VM ‘d0p1v4mgmt-vse-pub-1’
2013-06-16 10:54:33.185 GMT INFO pool-55442-thread-1 EdgeApplianceServiceImpl:371 – Wait for Vse Init : ‘vm-12784’

# Synch latest config version. Publish configurations to both edges.
2013-06-16 10:56:02.551 GMT INFO pool-55442-thread-1 ForceSyncTask:98 – Synching configuration for edge edge-16, config version 14.
2013-06-16 10:56:02.552 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Force sync : Synching configuration for vShield Edge edge-16, config version 14.
2013-06-16 10:56:02.699 GMT INFO pool-55444-thread-1 AbstractEdgeApplianceManager:537 – Downloading file ‘/var/log/events.old’ from VSE ‘vm-12825’ to location ‘/tmp/events.edge-38’ on VSM
2013-06-16 10:56:02.751 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Preparing configuration changes to be applied on vShield Edge (edge-16) d0p1v4mgmt-vse-pub-0
2013-06-16 10:56:02.789 GMT INFO pool-55444-thread-1 AbstractEdgeApplianceManager:537 – Downloading file ‘/var/log/events.old’ from VSE ‘vm-12837’ to location ‘/tmp/events.edge-38’ on VSM
2013-06-16 10:56:02.828 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Preparing configuration changes to be applied on vShield Edge (edge-16) d0p1v4mgmt-vse-pub-1
2013-06-16 10:56:02.945 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Publishing configurations on vShield Edge Virtual Machine vm-12780
2013-06-16 10:56:02.947 GMT INFO pool-55442-thread-1 AbstractEdgeApplianceManager:613 – The vse command is being sent to ‘vm-12780’
2013-06-16 10:56:02.956 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Publishing configurations on vShield Edge Virtual Machine vm-12784
2013-06-16 10:56:02.958 GMT INFO pool-55442-thread-1 AbstractEdgeApplianceManager:613 – The vse command is being sent to ‘vm-12784’

# Confirmation of completion Force Sync “jobdata-1831” Total time elapsed 3 Min 5 sec
2013-06-16 10:56:10.251 GMT INFO pool-55442-thread-1 PublishUtils:174 – Job ‘jobdata-1831’ progress – Force sync : Completed configuration of version 14 on appliances for edge-16.

Posted by

Gabe

Posted on

06/10/2013

Posted under

vCloud Networking and Security

Comments

2 Comments

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.

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.

Posted by

Gabe

Posted on

06/05/2013

Posted under

Uncategorized

Comments

Leave a comment

vCNS 5.1.x SSLVPN Gateway IP Change – How to update the IP existing naclient connection profile.

When your SSL VPN-Plus Gateway Interface has its IP changed all new client attempts to connect will be greeted with this error:

From the client side you have two options. The first is to connect to the gateway on its new IP, download and run installer from the gateway. I’ve had mixed results with this method on Mac OS X 10.8.2. I’ve had the best results (non-failed installations) if I’ve freshly rebooted my laptop and have erased all previously downloaded mac_phat client files.

The second option is to update the existing client configurations. On Windows clients – you can update the windows naclient IPs via the Registry Editor by editing the GatewayList registry key. Location can slightly change depending on your OS installation.

HKLM\SOFTWARE\VMware, Inc.\SSL VPN-Plus Client\Connection#
HKLM\SOFTWARE\Wow6432Node\VMware,Inc.\SSL VPN-Plus Client\Connection #

As a bonus you can give your name your connections to suit your needs by modifying the ConnectionAlias key (this will change the connection name in the naclient Network dropdown).

If you need to make the update to a Mac OS X, open Terminal, change your directory to /opt/sslvpn-plus/naclient/

Modify naclient.conf

The format is
ClientAlias GatewayIP 256

Just make the update to your GatewayIP (and ClientAlias if desired). Make sure the 256 doesn’t get erased. Write & Quit, then you are set.

– Gabe

Posted by

Gabe

Posted on

02/11/2013

Posted under

Virtualization

Comments

Leave a comment

vSphere Web Client – How to Enable CDP / LLDP

A quick few steps will enable the vSphere Distributed Switch to participate in LLDP conversations.

Configuration:

vSphere Web Client > Networking. Drill down and select the DVS. Click Manage. Click the Edit distributed switch settings icon.

In the Edit Settings window, Click Advanced.

Discovery protocol options are (disabled), CDP and Link Layer Discovery Protocol.

Screen Shot 2013-02-11 at 12.54.50 AM

Operation options:

Listen – This mode gives the vSphere admin access switch details (assuming the discovery protocol is enabled at the switch port). The switch does not show LLDP information about the host. Once the host successfully receives discovery protocol information from the switch, the information will populate under Manage > Settings > Topology > DVUplinks “show details” (the blue circles with the i)… the vSphere admin is treated to the following details:

Advertise – The vSphere admin does not see any switch details. This mode treats the switch administrator to see host details. Here is an example of what is seen on the switch:

Switch#show lldp nei eth 1 det

Interface Ethernet1 detected 1 LLDP neighbors:

Neighbor vmnic0/0050.5612.3456, age 58 seconds
Discovered 0:10:58 ago; Last changed 0:10:58 ago
– Chassis ID type: Interface name (6)
Chassis ID : “vmnic0”
– Port ID type: MAC address (3)
Port ID : 0050.5612.3456
– Time To Live: 180 seconds
– Port Description: “port 6684 on dvSwitch lab-dVS (etherswitch)”
– System Name: “lab-esx0.home.lab”
– System Description: “VMware ESX Releasebuild-123456”
– System Capabilities : Bridge
Enabled Capabilities: Bridge

Both – My favorite mode. Switch admin sees host details. vSphere admin sees switch details. Everyone has a beer and is happy.

Posted by

Gabe

Posted on

11/27/2012

Posted under

Uncategorized

Comments

3 Comments

Troubleshooting Invalid Virtual Machines

##Troubleshooting Invalid Virtual Machines##

Virtual machines can show up as invalid if the datastore UUID changed due to resignaturing

*) Try to remove/re-add the VM to vCenter inventory, VM needs to be powered off

Identify VM Host from VM Summary info in vCenter.

Note the path/datastore location using the following commands:

– esxi 4.1 ~# vmware-cmd -l !–gets the full path to vms
– esxi 5.x ~# vim-cmd vmsvc/getallvms !– Note [VMID] / Datastore Volume Name
OR
~# esxcli vm process list !– Note the full path

Identifying vm disk (mapping the full path above to a datastore volume name)

– esxi 4.1 ~# esxcfg-scsidevs -m
– esxi 5.x ~# esxcli storage filesystem list [map path to datastore volume name]

To Remove the VM from Inventory:
– Rick click VM, Remove from Inventory (DO NOT CHOOSE DELETE FROM DISK)
– Browse the datasore Identified above, to the VM directory, right click the .vmx file,
choose Add to Inventory.

*) Determine the sate of the VM

esxi 4.1
~# vmware-cmd <path.vmx> getstate
esxi 5.x
~# vim-cmd vmsvc/power.getstate [VMID]

Interpreting Output

if state is on !– vCenter may not be communicating with the host properly
if state is off !– the ESXi host may be unaware it is still running the virtual machine.

*) If you want to get VM world ID and turn off while debugging

~# vm-support -x ! — get world ID for affected VM.
~# vm-support -X <WorldID> !– Can take several minutes (up to 30 minutes)

*) Powering off the VM gracefully !– works if the VM process is running

esxi 4.1
~# vmware-cmd <path.vmx> stop
~# vmware-cmd <path.vmx> getstate
esxi 5.x
~# vim-vmd vmsvc/power.shutdown [VMID]
~# vim-cmd vmsvc/power.getstate [VMID]

*) Hard Powering off the VM

esxi 4.1
~# vmware-cmd <path.vmx> stop hard !– ungraceful hard shut down of the virtual machine
~# vmware-cmd <path.vmx> getstate

esxi 5.x
~# vim-vmd vmsvc/power.off [VMID]

*) To kill a virtual machine (works in 4.1 and 5.x)
esxtop
c , for CPU
f , to display fields
c , to add the column for the Leader World ID (LWID)
Identify VM by it’s LWID
k , to bring up the “World to Kill” prompt
type the LWID, press Enter,

Posted by

Gabe

Posted on

10/05/2012

Posted under

Technology Fundamentals

Comments

4 Comments

Technology Fundamentals – RFC 5424 The Syslog Protocol

SOME HISTORY

The protocol is originally defined in RFC 3164 “The BSD syslog Protocol” written by Eric Allman August 2001. RFC 3164 is now superceded by RFC 5424,

Rainer Gerhards – RFC 5424

written by Rainer Gerhards twitter|@rgerhards, March 20009.

SYSLOG ARCHITECTURE

Definitions: A machine that generates a message is called a device.
A machine that can receive the message and forward it to another machine is called a relay.
A machine that receives a message and does not relay it is called a collector. A collector is what we know as the syslog server.
Any device or relay is knows as sender when it sends a message.
Any relay or collector is known as receiver when it receives the message.

Valid Architectures:

         +------+         +---------+
         |Device|---->----|Collector|
         +------+         +---------+

         +------+         +-----+         +---------+
         |Device|---->----|Relay|---->----|Collector|
         +------+         +-----+         +---------+

         +------+     +-----+            +-----+     +---------+
         |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
         +------+     +-----+            +-----+     +---------+

         +------+         +-----+         +---------+
         |Device|---->----|Relay|---->----|Collector|
         |      |-\       +-----+         +---------+
         +------+  \
                    \      +-----+         +---------+
                     \-->--|Relay|---->----|Collector|
                           +-----+         +---------+

         +------+         +---------+
         |Device|---->----|Collector|
         |      |-\       +---------+
         +------+  \
                    \      +-----+         +---------+
                     \-->--|Relay|---->----|Collector|
                           +-----+         +---------+

         +------+         +-----+            +---------+
         |Device|---->----|Relay|---->-------|Collector|
         |      |-\       +-----+         /--|         |
         +------+  \                     /   +---------+
                    \      +-----+      /
                     \-->--|Relay|-->--/
                           +-----+

Syslog Message Parts:

         +------+---------+------------+
         |  PRI |  HEADER |  MESSAGE   |
         +------+---------+------------+

*The total length of the packet MUST be 1024 bytes or less.

* The PRI MUST have 3-5 characters <XXY > XX is the Facility, Y is the Severity.

Syslog uses UDP 514; The packets are 1024 bytes and carry the following information:

Facility – A code between 0 and 24 describing
Severity– = “<” PRIVAL “>”
Hostname = The order of preference for the contents of the HOSTNAME field is as follows:

   1.  FQDN

   2.  Static IP address

   3.  hostname

   4.  Dynamic IP address

   5.  the NILVALUE

Timestamp = See RFC3339, T and Z must be uppercase, T is required. Leaps seconds must NOT be used.

  Example 1

        1985-04-12T23:20:50.52Z

   This represents 20 minutes and 50.52 seconds after the 23rd hour of
   12 April 1985 in UTC.

   Example 2

        1985-04-12T19:20:50.52-04:00

   This represents the same time as in example 1, but expressed in US
   Eastern Standard Time (observing daylight savings time).

Message

Free-form message, UNICODE, encoded using UTF-8

Facility

Numerical             Facility
          Code

           0             kernel messages
           1             user-level messages
           2             mail system
           3             system daemons
           4             security/authorization messages (note 1)
           5             messages generated internally by syslogd
           6             line printer subsystem
           7             network news subsystem
           8             UUCP subsystem
           9             clock daemon (note 2)
          10             security/authorization messages (note 1)
          11             FTP daemon
          12             NTP subsystem
          13             log audit (note 1)
          14             log alert (note 1)
          15             clock daemon (note 2)
          16             local use 0  (local0)
          17             local use 1  (local1)
          18             local use 2  (local2)
          19             local use 3  (local3)
          20             local use 4  (local4)
          21             local use 5  (local5)
          22             local use 6  (local6)
          23             local use 7  (local7)
Severity Levels - Use this to remember these:  " Do I Notice When Evenings Come Around Early "
        Numerical         Severity
          Code

           0       Emergency: system is unusable
           1       Alert: action must be taken immediately
           2       Critical: critical conditions
           3       Error: error conditions
           4       Warning: warning conditions
           5       Notice: normal but significant condition
           6       Informational: informational messages
           7       Debug: debug-level messages

And that’s all I got to say about that…

Posted by

Gabe

Posted on

10/03/2012

Posted under

Storage Networking

Comments

Leave a comment

ICSNS – MDS Product Family Overview

Cisco MDS 9100, 9200 Series Multilayer Switches

MDS 9148 Gen-3, 48 2-,4-,8-Gb/s ports. Lic 8 port increments; 16 VSAN, VOQ, 4 port group -128 BB credit; 32 BB credit per port (125 can be allocated); 16 port-portchannel. FSPF;QOS; FC-SP;QCW;Fabric Manager;

MDS 9134 Gen-2, 32 1-,2-,4-Gb/s ports, plus 2 10Gb/s ports. Can be stacked for 480-, or 64- port 4-Gb/s support. Up to 16port- port-channel.

MDS 9124 Gen-2, 24 4-Gb/s ports; 4 ports per group, 64 BB credits per port group (61 BB credits max for 1 port for long ISL)

MDS 9222i Gen-2, Uses the 18/4 architecture of the (DS-9304-18K9); Advanced services fabric switch – supports QCW, FCIP, SME, IOA, SANTap, DMM, FICON, IPv6, IOS ISSU

MDS 9216

MDS 9216i

Cisco MDS 9500 Series Multilayer Directors

MDS 9513 – Gen 2, supports only Sup-2; slot 7 and slot 8 for supervisor modules.

MDS 9509 – Gen 1, supports Sup-1 or Sup-2; slot 5 & 6 for supervisor modules

MDS 9506 – Gen 1, supports Sup-1 or Sup-2; slot 3 & 4 for supervisor modules

Cisco MDS 9000 Series line card modules

Gen-1 (2Gb/s)

16-Port FC Switch Module; Optimized for use as ISL; default FX ports w/16 BB credits. E & TE ports default to 255 BB. 4000+ VOQ per ASIC and Cos 2,3,F

32-Port FC Switch Module; Optimized for host, tape and midrange disk connections.

MDS 9000 18/4 MSM (DS-9304-18K9) – has 18 1-,2-4-Gb/s FC ports, with 4 GigE ports

Gen-2 (4Gb/s)

12-Port 1-,2-,4-Gb/s full rate on every port.

24-Port 1-,2-,4-Gb/s at 2:1 oversubscription and full-rate bw on each port at 1-,2-Gb/s

48-port 1-,2-,4-Gb/s at 4:1 oversubscription at 4Gb/s, 2:1 at 2Gg/s, full line rate at 1-Gb/s

4-Port 10-Gb/s full rate on every port; 6000 shared BB credits; 250 BB credit per port by default.

Gen-3 (8Gb/s)

24-Port 1-,2-,4-,8-Gb/s at 2:1 oversbscription; full line rate at 1-,2-,4-Gb/s

48-Port 1-,2-,4-,8-Gb/s at 4:1 oversubscription; 2:1 at 4-Gb/s; full line at 1-,2-Gb/s; 6000 BB credits

4/44-Port 8-Gb/s host optimized; 4 ports at 8bs/s, 44 ports at 4Gb/s

SSN-16

-16xGigE ports for FCIP WAN

-4 IOA engines supporting: FCIP HW compress;FCIP HW encrypt,FCIP acceleration, Storage Media Encryption (SME), Cisco Secure Erase

Cisco MDS 9500 Series fabric modules

MDS 9513 Crossbar Switch Fabric Module – total bandwidth 2.2Tb/s

MDS 9513 Switch Fabric 2 Module – Required for 24-, 48- port 8-Gb/s FC modules.

Cisco MDS 9500 Series Supervisor modules

Provide the control plane within the MDS 9500 Series Directors; Console port, Mgmt port, COM1 port, CompactFlash slot, USB ports (2)

Gen-1 (2Gb)

Gen-1 supports 256 Indexes (destination ports), Max density is 240 ports using the 9509

Supervisor-1 (EOL)

MDS 9506 and 9509

MDS 9216 & MDS 9216i (EOL)

IPS-8 (EOL)

FC-16 (EOL)

FC-32 (EOL)

SSM (EOL)

MPS 14/2 (EOL)

Gen-2 (4Gb) Gen-2 supports 1024 indexes; max planned density is 528 ports using the MDS 9513 Director chassis.

Supervisor-2

MDS 9513

MDS 9222i

Gen-3 (8Gb) Gen-3 modules require NX-OS 4.x and Supervisor 2 ( on director switches)

MDS 9148

Fabric-2

SSN-16

24/48 8-Gb FC

44/4 8-Gb FC

Posted by

Gabe

Posted on

09/30/2012

Posted under

Virtualization

Comments

Leave a comment

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:

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

nsx tech

For NSX Operators by NSX Operators

vCNS 5.1.x SSL VPN-Plus Client Proxy Settings on Mac won’t stick

vCNS 5.1.x Edge Force Sync 101

vCNS 5.1.x Tasks Not Displayed

vCNS 5.1.x SSLVPN Gateway IP Change – How to update the IP existing naclient connection profile.

vSphere Web Client – How to Enable CDP / LLDP

Troubleshooting Invalid Virtual Machines

Technology Fundamentals – RFC 5424 The Syslog Protocol

ICSNS – MDS Product Family Overview

vSphere 5.1 Networking Improvements – Network Health Check Improvements

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: