Ahoy there! This is my personal blog which I use as my memory extension and a medium to share stuff that could be useful to others.

Earlier today, an application owner wanted his Windows Server 2003 SP2 VM restarted. So, I opened a Remote Desktop Connection (RDC) session to the VM and restarted it. After the VM started, I received the following exception when I tried to open an RDC session to the VM:

 

Win2003_RDC

Since I could no longer login via an RDC, I used the VMware vCenter to open a Console session to the VM and did the following:

  • Checked if Remote connections were enabled (had to be enabled as I logged in earlier to restart the VM). This feature was enabled. So, (1) in the above exception message was ruled out.
  • Checked Network Level Authentication (NLA). It was not supported. So, (2) in the above exception message was ruled out.
  • I could telnet from my laptop to port 3389 on the VM. So, (3) in the above exception message was ruled out.
  • Finally, I just restarted the VM again and I was surprised to find that I could then open an RDC session to the VM.

So, restarting the Windows Server 2003 SP2 VM via the console fixed the problem. I later searched the www and observed that many users experienced the same problem and the “console operation” was used to fix the problem.

I haven’t found the root cause yet (not happy), but don’t have the time to look into it now …

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS CSR

While configuring certificates in UCSM 2.1(1f), I observed that the UCSM does not permit you to create a Certificate Signing Request (CSR) for certificates with more than one Subject Alternative Name (SAN).

However, you can create a certificate with 1 SAN as shown in the image below. The certificate’s SAN is requested using the DNS field (cybergav.com) and the CN is requested using the Subject field (cybergav.in).

 

UCS_CSR

If UCSM permitted users to create CSRs outside UCSM and just use the private key and certificate, then there would not have been any constraint on the certificates used. On the other hand, the current setup enhances security (private key generated and stored only in UCSM) and facilitates certificate configuration for cert newbies.

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS MAC Nomenclature

Given below is a nomenclature for Cisco UCS MAC Addresses:

 

CiscoUCS_MAC_Nomenclature

 

Example:

00:25:B5:02:0B:02 => The second MAC address (OP=02) in a MAC Pool in UCS Domain 2 (KL=02) for an ESXi Host (M=0) in Fabric B (N=B)

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS WWN Nomenclature

Given below is a nomenclature for Cisco UCS WWPNs and WWNNs:

 

CiscoUCS_WWxN_Nomenclature

 

Examples:

(1) 20:00:00:25:B5:01:0A:01  => The first WWPN (OP=01) in a WWPN pool in UCS Domain 1 (KL=01) which is used by an ESXi host (M=0) in Fabric A (N=A).

(2) 20:00:00:25:B5:03:2F:03  => The third WWNN (OP=03 and N=F) in a WWNN pool in UCS Domain 3 (KL=03) which is used by a Linux host (M=2).

VN:F [1.9.22_1171]
Rating: -1 (from 1 vote)

VMware HA Agent Failure

Problem:

When trying to enable HA on an ESXi 4.1 cluster, the following error is displayed:

HAFailure_Mgmt

Also, the Summary tab for the ESXi host on which the HA agent fails shows the following:

HAFailure_Summary

Background & Analysis:

  • The HA agents on ESXi hosts in a cluster use the Management VMkernel ports for communication.
  • If an ESXi host in a cluster has more than one Management VMkernel port, then the HA agent on that host does not know which VMkernel port to use and hence the HA agent fails to work on that host.
  • In some cases, extra Management VMkernel ports are used in different VLANs for more efficient P2V conversions.

 

Solution:

For the ESXi Cluster:

STEP 1: Configure das.allowNetwork0=<Management VMkernel port> in the Advanced Options for VMware HA,

where  <Management VMkernel port> = Name of the VMkernel port used for ESXi Management (default value is “Management Network”

STEP 2: Disable and enable HA

 

Refer this VMware KB Article for more details.

NOTE: With the above solution implemented, ensure that you do not rename the Management VMkernel Port later.

Root Cause:

More than one VMkernel port for ESXi Management caused the HA agent to fail.

 

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
 Page 2 of 33 « 1  2  3  4  5 » ...  Last »