VM-Aware » Service Console

ESX With Nortel Switch VLANs

Paul Shannon — Mon, 21 Jul 2008 16:01:09 +0000

For all of you out there that have recently started buying the Nortel layer 2-7 Switch Modules for your IBM BladeCenter H because they can be cheaper than there Cisco counterpart with more functionality, check out this article.

It points out how to resolve some of the issues that you may be having with VLANs and ESX. The crux being that by default the Nortel Switch will tag the default VLAN so unless the Service Console is configured with the same VLAN tag, then things get messy. A simple checkbox is all that is required to fix this problem, but check out the article for more information.

Enable SSH For ESXi

Paul Shannon — Thu, 17 Jul 2008 09:32:33 +0000

A great article on how to enable SSH for ESXi, which if you didn’t already know does not have a Service Console to speak of, but is built on the BusyBox distribution. However, it is still possible to remote manage it using SSH with a tweak here and there.

Here’s the great video that shows you how to do it step by step, but check out the rest of the article for more detail:

Rescan SAN Extremely Slow

Paul Shannon — Tue, 15 Jul 2008 07:56:43 +0000

I recently came across a problem whereby a Rescan SAN was taking an absolute age, like 15 minutes from the VI Client. Now I love the VI Client, but sometimes it just doesn’t give you enough information when it is doing things. To be fair most of the time the verbose information is simply not needed, but when things go wrong it is a god send.

In comes the Service Console command line, more specifically the esxcfg-rescan and esxcfg-mpath commands.

Firstly I ran esxcfg-mpath -l, which will list all the LUNs and the paths associated with each LUN. After running this I noticed that some of the LUNs had dead paths listed for LUNs that had been deleted from both the Storage Processor (DataCore) and the VI Client.

I had previously read somewhere (I can’t remember where) that Brocade switches can sometimes cause ESX to remember LUN locations even if they have been removed from the Storage Processor. So this meant that I had to routes to take 1 – Add the LUN back with the original paths and try and remove again gracefully or 2 -reboot the ESX host.

The second option was not really desirable as far as the customer was concerned so I had to go and add the LUNs back. This wasn’t such a big deal, but here’s what I did:

Create the LUN in DataCore
Set up mirroring to create the original 4 paths
Present the storage to both the affected ESX hosts
Run esxcfg-rescan vmhba?? on both HBAs
Use esxcfg-mpath -l to check that the original paths are now showing as either Active or On and that there are no Dead paths
Open the VI Client and add the LUNs using the Add Storage wizard
Now remove the LUNs from the VI Client
Run esxcfg-mpath -l to make sure that all the paths are still happy
Go back to the Storage Processor and remove the LUNs presented to the ESX hosts
finally run esxcfg-rescan vmhba?? on both HBAs again and check that the LUNs have been removed and that there are no Dead paths to any of the LUNs

I know all this seems a little long winded, but it was at the time not desirable to reboot the ESX hosts.

Here is a good Tech Note from VMware to help with the use of esxcfg-mpath.