Nested VM Performance is Slow

This is taking forever!

That’s what I was thinking when deploying nested virtual machines on vSphere 6.5 in my lab (OK, it’s my laptop). The configuration was simple enough; the latest version of VMware Workstation, an ESXi host VM, & a Windows Server 2012 R2 VM nested in ESXi. Simple enough, right?

Watching the console of the nested VM I notice it seemed…slow. When the VMware logo on the POST screen finally appeared I could see the screen painting making it look like an 80’s arcade game.

As you can see that took way too long. So with Process Monitor running on the laptop I power on the VM again. After it runs for about a minute the fun task of sifting through the ProcMon log begins. If you’ve ever used ProcMon you know it’s more of an art than a science. The first thing I always do is use the analysis tools from the menu.

Honestly, I just go through each of them & see if something jumps out at me. Real technical, I know. In all the sifting & sorting one thing that kept jumping out was the Anti-Virus software.

This wouldn’t be the first time an Anti-Virus product interfered with an application working properly so I started digging through the AV interface. After clicking around for a bit I come across some very interesting settings.

“Enable hardware-assisted virtualization” & “Use nested virtualization where available”. Those look promising. I uncheck both of those settings & give the laptop a reboot. This time when the nested VM boots it POPS!

According to Avast’s website, the software is supposed to detect that virtualization applications like VMware Workstation or Microsoft Hyper-V are installed & automatically disable these settings.

Cheers!

Backlog: ODBC Connection Failed

So you’ve got a Microsoft Access database with linked tables to a SQL server that looks something like this.

When opening one of the linked table you get an error that says, “ODBC–connection to ‘DP’ failed”.

When you click OK you get a message that says, “Microsoft Access can’t open the table in Datasheet view”.

Hmm, what up with the ODBC connection called “DP”? What say you Procmon?

Result = NAME NOT FOUND. Oh, the ODBC connection doesn’t exist. Create the ODBC connection & you are good to go.

I admit that you could have also just gone & looked at the ODBC connections in the Control Panel to figure out it doesn’t exist but it was really just an excuse to use Procmon.

Printer Keeps Going Offline

A user reported that they had printed some documents but that they were not printing. Looking at the print server I saw that the printer was showing as Offline.

I was able to ping it as well as bring up the web interface. As a test I disabled SNMP checking for the printer’s port by doing the following:

• Right click the printer & select Properties.
• Select the Ports tab.
• Select the printer’s port & click Configure Port.
• Uncheck SNMP Status Enabled.
• Click OK.

The moment I did that the printer went to a Ready status & the documents printed. I have two printer server that both have this printer configured. They were both experiencing the issue so I believe the issue to be with the print servers.

OK, perhaps the SNMP string got changed on the device. I ran an SNMP test (Paessler has a good free one http://www.paessler.com/tools/snmptester) but it check out good using the SNMP string configured on the printer’s port.

So when in doubt use ProcMon. First, I set the printer’s port back to using SNMP checking then fired off ProcMon on the printer server. Within a minute the printer switched from Ready to Offline. I stopped ProcMon & begun the artful task of sifting through the capture. I noticed a section where the print server starting sending SNMP requests to all the printers. I saw a response for all the other printers but none for the one in question. Note below all I saw were UDP Send.

So for some reason the printer is not responding (or not responding timely. I didn’t feel like doing a full on packet capture). So like everything else if it’s not working, reboot. Once the printer came back up it I started another ProcMon capture. This time I saw the SNMP requests & responses (UDP Send & UDP Receive).

Sure I could have just left SNMP unchecked on the printer port but that wouldn’t have really resolved the issue; just masked it. Now if it continues to happen I may have to see if there is a newer firmware for the printer that resolves SNMP issues (or contact HP, ugh), but for now a printer reboot will do the trick. I also got to see a little more under-the-hood thanks to ProcMon.