Unhandled Exception when logging into ESXi Host client

Unhandled Execption Error
Ran into this weird error after powering up the C.R.I.B. and logging into the ESXi Host to boot up VMs. This error popped up while using Safari, Chrome, and Firefox.

Unhandled Exception (1)
Cause: Error: [$rootScope:inprog] http://errors.angularjs.org/1.3.2/$rootScope/inprog?p0=%24digest

The error presents itself with two buttons: Reload and Details. The picture displayed shows the details of the error that I got. You can hit reload, attempt to log back in, and rinse and repeat the process. Or you can select Details, where you can only ‘close’ the error and repeat the process.

A quick check with Professor Google finds this is an issue mentioned in the VMware Communities. Luckily, the entry had an answer attached. (Thanks, “rshell”). It’s not a fix, but it is an answer.

I can’t explain why the error occurs, but I can explain what causes it to pop up. This error occurs when you land on the logon page, enter credentials, and then hit on the keyboard instead of clicking on the button. If you click the login button, you have no errors and vSphere loads normally.

ESXi BIOS Power Settings Best Practice

Dell Poweredge R720 Server BIOS Power Settings
Dell Poweredge R720 Server BIOS Power Settings

There is a movement to change the best practice regarding the bios power settings on an ESXi host. In the past, you would set the power settings in the BIOS to max and be done with it. You did this because previous versions of vSphere did not work well with the various C-States of the processor (ie., When the workload on the host would drop, the CPU would drop to a lower power setting. When it would go to wake and draw the CPU back to full power, the host would crap all over itself.).

vSphere 5.5 introduced a new feature that allows VMware to better utilize the C-States of some of the newer processors. Thus allowing the CPUs to change power and speed states without affecting the performance or behavior of the Host. (YEAH!!)

I know we are happy about this, but not so fast…

This link describes the behavior and a couple of performance benefits from the change — however, it should also be noted, that this change is dependent on the type of workloads in your environment. If you have a heavy IO Intense workload or a time sensitive workload, you may still want to have that host on max power, high performance, etc.

http://blogs.vmware.com/vsphere/2014/01/bios-power-policies-affect-performance.html

PernixData – First Impressions

PernixData Dashboard
PernixData Dashboard
As you’ve probably guessed, I got a new toy in the lab at work. I’m talking PernixData v1.0. For my initial review, I will say that the install, setup, and configuration was very simple — just a few steps actually. This was probably the easiest installation that I’ve done in the last year.
Continue reading “PernixData — First Impressions”

Missing NIC

Had an interesting event yesterday. A new application build was underway that wasn’t going very smoothly. Snapshots were being made and reverted rather frequently. After one one snapshot reversion, progress on the install was being made. Approximately three hours went by and a high priority ticket was raised. Something had gone wrong, and no one could access the VM. It was unresponsive to pings, RDP, etc. Eventually, it was discovered that the NIC was missing. Once the NIC was readded, access to the VM was restored and the installation group was off and running.

A forensic investigation was conducted into the root cause of the missing NIC. It was suggested that one of the snapshots were corrupted. The event logs within virtualcenter were vague – they provided the timeline of what had been occurring, but failed to indicate what had transpired with the NIC. I downloaded the vm logs from the datastore and examined them. I wanted to see if there were problems during a snapshot capture, or a snapshot reversion. There were no problems or failures with snapshot creation or any rollbacks of the snapshots. I did however, come across an entry that had me puzzled.

E1000: Syncing with mode 6.

Of course, Professor Google was up for my challenge and provided me with this bit of info within the VMware Communities:
Network card is removed without any user intervention. I struck gold. One of the commentors,”NMNeto”, had hit the nail on the head with this comment:
“The problem is not in VMWARE ESX, it is in the hot plug technology of the network adapter. This device (NIC) can be removed by the user like a usb drive. … When you click to remove the NIC, VMWare ESX removes this device from the virtual machine hardware.”

Removable_NIC
"Safely Remove Hardware Icon"

From here, I had a strong lead. Now that I knew what I was looking for, I opened the Virtual Machine’s Event Viewer and started itemizing each entry – looking for the device removal. After about five minutes, I found the who, when, where, and how. I felt like I was winning a game of “Clue”.

“NMNeto” had also posted an adjoining link within the community for a thread that posted a resolution to prevent the issue going forward. Here’s an image from that link that gives you step by step instructions on how to prevent this on other VMs.

I will take this data and propose a change to add this entry to our VMs so we do not have this event to reoccur.

Script: Merge Multiple Arrays

Each Saturday my company does a refresh of a few different machines. This refresh consists of cloning a couple of production machines into our lab environment for development. It’s a very tedious process that takes the entire day to do. Until recently, this process has been done manually. I’ve been working on a script to automate the process as much as possible. Along the way, I’ve learned a great deal about powershell/powercli – especially from hitting a wall and trying to figure out a way around. This blog entry is about one of those snags along the path of progress.

The refresh consists of two major Acts. Act I is all about cloning the source VMs, stripping them down, and converting them into templates. Act II is about deploying VMs using differing templates. There will be a later entry discussing this entire script in greater detail. This entry focuses on creating merged array to be used in the deployment CSV list for Act II.

Each week, the refresh list changes. One week, the source VMs may be SourceVM01 & SourceVM05. Next week, it may be SourceVM01 & SourceVM03. I created a GUI frontend for this script using PrimalForms 2011. The GUI has a “pick-list” where you can cherry pick what SourceVMs and what DestinationVMs will be needed. Upon your selection, three arrays are built – $a = #VM Names, $b = #Specs, $c = #Template Names.

For example;
If I needed to refresh DEV-VM01, TEST-VM01, and QA-VM01; I’d check their boxes, and the following variables would be added to the three arrays. (You can start to see where if you had multiple Dev and Test VMs how these arrays can get quite complex.)

DEV-VM1 TST-VM1 QA-VM1
$avm = “DEV-VM1” $avm = “TST-VM1” $avm = “QA-VM1”
$bspec = “DEV” $bspec = “TST” $bspec = “QA”
$ctmp = “TMPL-DEV01” $ctmp = “TMPL-TST01” $ctmp = “TMPL-QA01”

So the question was, how do you take this information and merge it – with one array, and all the information within? That’s where I came up with this solution.
I replay each of the arrays using a “counter” ($i) and building a new array with the information from the table above. The counter variable matches each record for that row (ie. $a.record1 with $b.record1 and $c.record1).

The array will continue to loop, until it runs out of entries based on the $a array. Once this fourth array ($d) has been created, I can then use it to build my deployment CSV file (SEE THE DEPLOYMENT CSV LIST BUILD SCRIPT – To come).