WilliamLam.com

Detecting duplicate VM MAC Address using vCenter Server Alarm

by // 6 Comments

Having a duplicate VM MAC Address in your environment can lead to an extremely painful day of troubleshooting and it can also be tough to prevent depending on how and where you provision your VMs.

There are two cases that I can think of where a duplicate MAC Address can potentially occur:

  1. You manually assign a static MAC Address versus using dynamic assignment (includes VM import) and it conflicts with an already assigned MAC Address
  2. You migrate a VM from one vCenter Server to another and the destination vCenter Server has already assigned the MAC Address of the migrated VM

In both of these scenarios, when a duplicate MAC Address occurs, time is of the essence to quickly pin-point the source of the duplicated entry and quickly resolving the conflict. What would be nice is to be able to automatically detect that a MAC Address conflict has occurred and provide the necessary information of the offending VMs.

UPDATE (4/22) - Thanks to Petr, it turns out there is another MAC Address conflict event which I did not know about specifically for detecting duplicate entries for manually assigned MAC Addresses called "VM static MAC conflict". I definitely recommend creating an alarm for both Events for the vCenter Alarm.

While performing some research in my lab environment the other day, I accidentally stumbled onto this little tidbit in vCenter Server. It turns out there is an out of the box event called "VM Mac conflict" which can be triggered using a vCenter Server alarm when a duplicated MAC Address is detected for a VM. I was actually surprised that this was not one of the pre-created default alarms in vCenter Server as I can see this being extremely useful to have out of the box. In any case, it is simple enough to create a new vCenter Server Alarm and in the example below I called it "Dupe VM Mac Address".

duplicate-mac-address-alarm-0
To test our new alarm, I created a new VM called "VM1" which has been configured with static MAC Address that matches "VM2". Once the VM has been created, we can see that the alarm is immediately triggered and by clicking into the alarm details, it provides the details of the MAC Address and the offending VMs.

duplicate-mac-address-alarm-1
In my opinion this is an alarm that everyone should create in their environment to ensure that if this problem ever occurs, you can quickly get notified and resolve the problem. I have also reported this internally and asked if we can have this alarm created by default, so hopefully this will not be necessary in the near future 🙂

Accessing the vSphere Web Client from a Linux desktop?

by // 9 Comments

A common miss-conception about the vSphere Web Client is that it is not accessible from a Linux-based desktop. Contrary to popular belief, this is actually possible at least from a technical standpoint as alluded to in this VMware KB. A recent discussion about this topic had piqued my interest as my own understanding of whether the vSphere Web Client would even work on a Linux desktop is fuzzy at best since it is not a desktop OS I use on a regular basis.

Though this may still comes as a surprise to some folks, Adobe Flash is indeed a requirement to use the vSphere Web Client. There are actually two ways to satisfy this requirement using any modern Linux desktop distribution. In the example below, I am using the latest Ubuntu Desktop 14.04 distribution to demonstrate the two options.

The first option is the most "convenient" by simply using the latest version of Google Chrome browser which actually bundles the Pepper Flash Plugin (more details can be found here from Adobe). Here is the CLI commands to perform the installation of Google Chrome on Ubuntu, you acn easily do a search for the instructions for other Linux distributions.

sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install google-chrome-stable

Here is a screenshot using Google Chrome connecting to a vSphere 6.0 environment as well as accessing the VMRC of a VM:

vsphere-web-client-linux-desktop-1
The second option is slightly less "convenient" since you need to install the Pepper Flash Plugin in addition to the browser that supports this plugin which is Chromium. Here is the CLI commands to perform the installation of Chromium on Ubuntu, you can easily do a search online for instructions for other Linux distributions.

sudo apt-get update
sudo apt-get -y install pepperflashplugin-nonfree
sudo apt-get -y install chromium-browser

Here is a screenshot using Chromium connecting to a vSphere 6.0 environment and you will also be able to access the VMRC of a VM:

vsphere-web-client-linux-desktop-0
This looks pretty good right? I mean you can login to the vSphere Web Client UI to perform basic operations and access the VM Console using the HTML5 based VMRC. Well, almost but there are a couple of caveats to be aware of which may not be obvious at first. In addition to the basic operations and VMRC access, there some other important capabilities the vSphere Web Client offers today:

  • Deploying OVF/OVA
  • Windows Session Authentication
  • Uploading files to a vSphere Datastore
  • Mounting ISO/Floppy Image
  • Connecting Local Devices (e.g. USB/CD-ROM)

The above capabilities are made available through what is known as the Client Integration Plug-in (CIP) which is something that is downloaded from the vSphere Web Client Server and installed locally on your desktop. A Linux CIP installer is currently not available today and the above functionality would not be available in the vSphere Web Client. Having said that, not all is lost and there are some workarounds. If you wish to deploy an OVF/OVA, you can still install OVFTool which is available on Linux and instead of using the UI to drive the deployment, it can be done through the CLI. For uploading files like an ISOs, you can use the vSphere API/CLI as shown here or SCP'ing directly to the ESXi host. Once the ISO is uploaded, you can then mount it to your VM from the vSphere Datastore.

Though this is far from a perfect solution for Linux-based desktop users, it does allow you to access the basic management capabilities of the vSphere Web Client. There is definitely room for improvement and this is an area that PM/Engineering is looking to enhance further in the future. There has also been a ton of general performance and usability improvements in the new vSphere 6.0 Web Client which will benefit all platforms and if you are interested to learn more about those, check out the blog post from the vSphere Web Client PM here.

Why is my VSAN Component maximum showing less than 3000?

by // Leave a Comment

This is a question that I have seen come up on several occasions in both the VMTN Community forums as well as in our internal Socialcast group. I have not seen anyone blog about this topic yet and figure I would share the answer since this was a question I had asked myself when I had initially setup VSAN. If you are not familiar with VSAN Components, I highly recommend you check out Cormac Hogan's blog article VSAN Part 4: Understanding Objects and Components.

In vSphere 5.5 Update 1, the maximum number of supported components for VSAN is 3000 which is a per ESXi host maximum. What some folks are noticing when they run the RVC vsan.check_limits command on their VSAN Cluster, they are finding out that the maximum is coming up much lower as seen in the example below.

/localhost/VSAN-Datacenter/computers> vsan.check_limits VSAN-Cluster/
2015-01-28 15:34:25 +0000: Gathering stats from all hosts ...
2015-01-28 15:34:27 +0000: Gathering disks info ...
+--------------------------------+-------------------+-------------------------------------------+
| Host                           | RDT               | Disks                                     |
+--------------------------------+-------------------+-------------------------------------------+
| vesxi55-3.primp-industries.com | Assocs: 30/20000  | Components: 8/750                         |
|                                | Sockets: 17/10000 | naa.6000c2932c3f51f04e4cd395f4a11752: 8%  |
|                                | Clients: 3        | naa.6000c294f6496a99ad756857b9b06f01: 0%  |
|                                | Owners: 5         |                                           |
| vesxi55-2.primp-industries.com | Assocs: 10/20000  | Components: 8/750                         |
|                                | Sockets: 13/10000 | naa.6000c294bde5987d60398e0305978b00: 9%  |
|                                | Clients: 0        | naa.6000c292a964255b82410099360a9b27: 0%  |
|                                | Owners: 0         |                                           |
| vesxi55-1.primp-industries.com | Assocs: 24/20000  | Components: 8/750                         |
|                                | Sockets: 15/10000 | naa.6000c298b69006b820e367b5fde97cbf: 11% |
|                                | Clients: 3        | naa.6000c29db3f272cfb7fb4d08bffad3ab: 0%  |
|                                | Owners: 3         |                                           |
+--------------------------------+-------------------+-------------------------------------------+

The reason for this is actually due to the amount of physical memory available to each ESXi host. If you are running VSAN in a Nested ESXi environment like I am in the example above, I only have 8GB of memory configured for each ESXi host. The number of supported VSAN Components will definitely differ from an actual physical host with more memory and the nice thing about vsan.check_limits command is that it is dynamic in nature based on the actual available resources. Funny enough, the majority of the questions actually came from folks who ran VSAN in a Nested Environment, so this would explain why this question keeps popping up.

If I run the same RVC command on an environment where VSAN was running on real hardware with a decent amount of memory which most modern systems these days have, then I can see the VSAN Component maximum is properly displaying the 3000 limit as expected in the example below.

/localhost/datacenter01/computers> vsan.check_limits vsan-cluster01/
2015-01-28 15:28:47 +0000: Querying limit stats from all hosts ...
2015-01-28 15:28:49 +0000: Fetching VSAN disk info from esx021.vmwcs.com (may take a moment) ...
2015-01-28 15:28:49 +0000: Fetching VSAN disk info from esx022.vmwcs.com (may take a moment) ...
2015-01-28 15:28:49 +0000: Fetching VSAN disk info from esx024.vmwcs.com (may take a moment) ...
2015-01-28 15:28:51 +0000: Done fetching VSAN disk infos
+---------------------------+--------------------+---------------------------------------------------------------------------------+
| Host                      | RDT                | Disks                                                                           |
+---------------------------+--------------------+---------------------------------------------------------------------------------+
| esx021.vmwcs.com          | Assocs: 223/45000  | Components: 97/3000                                                             |
|                           | Sockets: 132/10000 | t10.ATA_____WDC_WD1002FAEX2D00Z3A0________________________WD2DWCATRC061926: 18% |
|                           | Clients: 14        | t10.ATA_____KINGSTON_SH103S3480G__________________00_50026B7226017C69____: 0%   |
|                           | Owners: 29         |                                                                                 |
| esx022.vmwcs.com          | Assocs: 252/45000  | Components: 96/3000                                                             |
|                           | Sockets: 143/10000 | t10.ATA_____KINGSTON_SH103S3480G__________________00_50026B7226017CA2____: 0%   |
|                           | Clients: 14        | t10.ATA_____WDC_WD1002FAEX2D00Z3A0________________________WD2DWCATRC050466: 19% |
|                           | Owners: 38         |                                                                                 |
| esx024.vmwcs.com          | Assocs: 197/45000  | Components: 96/3000                                                             |
|                           | Sockets: 122/10000 | t10.ATA_____ST2000DL0032D9VT166__________________________________5YD73PRP: 8%   |
|                           | Clients: 17        | t10.ATA_____KINGSTON_SH103S3480G__________________00_50026B7226017C5B____: 0%   |
|                           | Owners: 22         |                                                                                 |
+---------------------------+--------------------+---------------------------------------------------------------------------------+

The lesson here is that even though I am a huge supporter of using Nested ESXi to learn about new products, features and how they work from a functional perspective, there is no amount of Nested ESXi testing that can ever replace actual testing of real hardware.