This project is read-only.
1

Closed

Stuck "Waiting for machines to start up" when 2 versions of SQL in the lab

description

I'm looking to set up a lab for migrating from SQL 2008 R2 plus an associated application to SQL 2014, and I was noticing that if I put 2 SQL servers in the lab with their appropriate roles, the Install-Lab script gets hung at "Waiting for machines to start up".

I'm using a local hyper-v instance on my Windows 10 workstation and everything seems to be good with the DC startup and domain configuration. Then when the worker turns to the SQL servers and starts up the VMs, I can see the VMs start in the HyperV manager, but even 15 minutes later the Install-Lab script never acknowledges the VMs are started. If I go down to just one VM or use two or more VMs that are all the same version of SQL, the script seems to complete successfully. I'm happy to help troubleshoot and will keep digging to see if I can figure out what's going on, but I figured that I would log it since and I can reproduce the issue on a test 2012 R2 server as well.

file attachments

Closed Feb 18, 2016 at 11:08 PM by raandree

comments

raandree wrote Feb 5, 2016 at 11:15 AM

Can you please attach the script that you are using?

Also we have done a lot of updates and published AutomatedLab 3.7 Refresh 2 today.

wrote Feb 5, 2016 at 2:53 PM

nfields03 wrote Feb 5, 2016 at 2:53 PM

Sure thing, here's the attached script. From some further testing, the issue seems to be primarily with the SQL 2008 role, and I'll try the refresh version to see if anything changes.

perped wrote Feb 5, 2016 at 5:00 PM

I stumpled upon the exact same thing as you describe.

Please add following line to AutomatedLabVirtualMachines.psm1 line 692:
netsh.exe interface ip delete arpcache | Out-Null

Code excerpt should now look like this:
    foreach ($vm in $vms)
    {
        $session = $null

    netsh.exe interface ip delete arpcache | Out-Null

        $session = New-LabPSSession -ComputerName $vm -UseLocalCredential.......

        if ($session)

perped wrote Feb 7, 2016 at 2:48 PM

Also add line to AutomatedLab.psm1 line 2730:
netsh.exe interface ip delete arpcache | Out-Null

Code excerpt would then look like this:

while (-not $session -and $machineRetries -gt 0)
        {
            netsh.exe interface ip delete arpcache | Out-Null

            Write-Verbose "Testing port $($param.Port) on computer '$($param.ComputerName)'"
            $portTest = Test-Port -ComputerName $param.ComputerName -Port $param.Port -TCP

raandree wrote Feb 7, 2016 at 7:06 PM

The arpcache change suggested for AutomatedLab.psm1 is already in the latest sources and also in the 3.7 Refresh 2 MSI download. I have just added the arpcache change for AutomatedLabVirtualMachines.psm1.

nfields03 wrote Feb 8, 2016 at 5:34 PM

It looks like the arpcache change in 3.7 Refresh 2 fixed the issue, thanks guys! I've got one more follow up question regarding how AutomatedLab determines what Software/OS an ISO represents but I'll log that in another thread to keep things clean.

wrote Feb 18, 2016 at 11:08 PM

wrote Feb 18, 2016 at 11:08 PM