Wireless Access

Just deployed a pair of VMMs on a Hyper-V 2016 host. The host has the processors identified int the ArubaOS 8.3.0.0-Virtual Appliance-Installation Guide, and local SSDs. The VMMs were built to the specs in the deployment guide (attached), and even created te vNICs using PowerShell and outlined. After the initial boot up and configuration, all subsequent boots take ~1 hour and 20 minutes. At first we thought it was because of FIPS, since the hang up points seem to be FIPS related, however when dployed on a VMWare host, they boot in 2 minutes. I even built the VMM from scratch using the ISO, and not the OVA, on my laptop running Workstation, boots in 2 minutes. Rebuilt a new VMM pain on Hyper-V 2012R2, same result over an hour to boot. CPU, Memory, and Disk show very low utilization during the boot process. Tested with and without anti-virus, no change.

Here are the times from a stop watch. These are the points where it hangs and the time is the time it adavenced to the nest step;

Hyper-V 2012 R2

*Start at boot 0:00:00

*Generating SSH Keys 0:01:09

*Generating SSH Public Key Cert 0:17:05

*Initializing certificates 0:38:01

*Starting FIPS Aruba Cryptographic KAT services: Starting FIPS Aruba Cryptographic KAT test successfully 0:51:49

*Initializing FPAPPs 1:10:15

*Starting OpenSSL FIPS KAT Test 1:12:50

* Time it gets to User: 1:12:56

We have opened an case with Support and they seem to be stumped. 

Any thoughts or ideas would be greatly appreciated.

Thanks!

Attachment(s)

ArubaOS 8.3.0.0_Virtual Appliance Installation Guide.pdf   5.71 MB 1 version

Did you find a root cause and solution or workaround? Please escalate the ticket with support if you believe you need another engineer to have a look at it.

Ticket has been escalated inside TAC, and the local SE, CSE, and SE Manager are engaged. Was hoping someone else was having the same issue, but I know Hyper-V support is new, so it may not be widely adopted yet. 

The bigger isue is the database sync failure, which sounds like multiple people are having.

Their recommended workarond right now is deploy an ESXi server. My customer is not excited about that option.

I will post the resolution for both once we figure it out.

So TAC was able to reproduce and find the root cause of the issue. Apparently ESXi uses tsc as its clocksourve nad Hyper-V doesn't. TAC logged in and changed the clocksource on the VMMs to use tsc. 

Here is the process fprovided to us from TAC;

We need to login to shell mode and run below command,

Run:       echo 'echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource' >> /flash/.startupscript

Run:       chmod +x /flash/.startupscript

Reload

Not only did this resolve our boot time issues, it also resolved our database syncronization issues.

The VMMs boot within a few mintes now and database sync has has zero failures.