UCS ESX Driver Update and VLAN Config via the Service Console

A recent troubleshooting session helped me dust off the ESX cobwebs from my brain since I have been working exclusively with ESXi since late 2010.  There was an ESX 4.1 U1 installation on a UCS System, and the Cisco-customized ISO had not been used.

Needless to say, the machine was not accessible from the network.  Details on how we resolved the problem are included below…

Let me go ahead and state the obvious: yes, we could have just done a re-install with the Cisco-customized image…but where’s the fun in that?  🙂

Now, before we go into the process, standard disclaimers apply.  Any driver updates should be part of a formal change control after planning with your team and verifying important documents such as Cisco’s Interoperability Matrix

First, verify that you really do have incorrect driver versions installed on your server with the following commands at your ESX Service Console (applicable to DCUI Tech Support Mode as well):

 ~ # vmkload_mod -s enic | grep Version 

NOTE: if you also want to check the HBA driver version, change the enic to fnic

Next, we downloaded the Cisco enic driver ISO for vSphere 4.1 U1 from VMware,  mounted the ISO to the UCS Server via the KVM Console, and mounted the ISO to the Service Console:

 mount /dev/cdrom 

The server was put into Maintenance Mode:

 vimsh -n -e /hostsvc/maintenance_mode_enter 

Then, the enic driver was updated using the esxupdate command (this step requires a reboot!):

 esxupdate --bundle=<driver filename>.zip update 

The server was taken out of Maintenance Mode (*Optional since you can do so from the vSphere Client*):

 vimsh -n -e /hostsvc/maintenance_mode_exit 

However, we still could not ping the gateway… 😕

I immediately checked the first item on my Most Wanted list of VMware connectivity culprits: VLANs

 esxcfg-vswitch -l 

It seems that whomever performed the install did a good job of setting the IP and the gateway, but NOT the VLAN.  After verifying the VLAN in use by a functioning server’s Service Console portgroup, we manually set the VLAN at the CLI (*At this point, I actually missed the good ol’ ESXi DCUI 😉 *)

 esxcfg-vswitch -v <VLAN> -p “Service Console” vSwitch0 

After confirming the change on the Service Console and pinging the gateway, the remaining configurations were performed in the vSphere Client.

Even though the VM Network was still using the wrong VLAN, it would be easier to configure the remaining network settings from the VI Client, or, even better, we could just add the hosts to the Nexus 1000V for centralized network management 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *