New-vm hangs in powershell jobs.

[invalidusernam2]

I have everything complete, the vm is built and the nic is configured but it hangs after the task is complete. If I don't use the pipes the script will hang before start-vm.

new-vm -resourcepool $buildspecs.vmresourcepool -template $buildspecs.ostemplate -name $hostname -datastore $buildspecs.datastore -location $location -oscustomizationspec $spec | start-vm |

  Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $netaddress.vmnetwork -StartConnected $true -Confirm:$false

  #does not continue

$vm = get-vm $hostname

any help would be appreciated.

Dan

[LucD]

The actions and configuration settings that you define in the OSCustomizationSpec will only happen when the VM is powered on the first time.

But you can change the virtual HW (like the Set-NetworkAdapter) before you power on the VM.

[invalidusernam2]

Got it with wait-task ..

$newvm = new-vm -resourcepool $buildspecs.vmresourcepool -template $buildspecs.ostemplate -name $hostname -datastore $buildspecs.datastore -location $location -oscustomizationspec $spec | start-vm |

  Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $netaddress.vmnetwork -StartConnected $true -Confirm:$false

  Wait-Task -Task $newvmStrange, I thought it was always waiting on the task to complete if you don't specify runasync.

[LucD]

Not sure what Wait-Task has to do with it?
You're not using RunAsync.

[invalidusernam2]

You're not understanding the question, I said in the op that I had completed the vm build, networking and such. It was just getting the job to complete, after the vm was built it would just sit in a running status.

In a job it appears the actual process of building a vm without the async does not actually wait before running the next command, you have to specifically tell it to do so. Just shell without jobs you'll get the cheerios.

[LucD]

I'm afraid you are misinterpreting what is happening.

• the New-VM cmdlet will create a VM and wait till the VM is created (since you don't use the RunAsync switch)
• When the Start-VM cmdlet is executed, it will wait till the VM shows a status of powered on, then the script continues
• Since you use OSCustomizationSpec, the configuration, by the sysprep utility, will happen inside the guest OS after the first Start-VM. If this is hanging or if this does not connect the NIC to the network, there is something wrong in the OSCustomizationSpec or the NIC configuration.

My answer just mentioned that you would better configure the NIC's connectionstate before the Start-VM.

Your statement "building a vm without the async does not actually wait before running the next command" is incorrect.

The New-VM cmdlet will wait till the VM is created.

This is not the same as configuring the guest OS inside the VM, that's what the OSCustomizationSpec will do after the Start-VM.

[invalidusernam2]

Quoting myself " I have everything complete, the vm is built and the nic is configured but it hangs after the task is complete."

I'm not having an issue building a VM. It's built either way with the nic settings correct and joined to the domain.

####This works..

$newvm = new-vm -resourcepool $buildspecs.vmresourcepool -template $buildspecs.ostemplate -name $hostname -datastore $buildspecs.datastore -location $location -oscustomizationspec $spec | start-vm |

Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $netaddress.vmnetwork -StartConnected $true -Confirm:$false

Wait-Task -Task $newvm

$vm = Get-VM -Name $hostname -ea SilentlyContinue

if($vm){

'continue configuration of vm'

}

####This does not.. The job will run indefinitely even after the vm is built.

$newvm = new-vm -resourcepool $buildspecs.vmresourcepool -template $buildspecs.ostemplate -name $hostname -datastore $buildspecs.datastore -location $location -oscustomizationspec $spec

###breakpoint

$vm = Get-VM -Name $hostname -ea SilentlyContinue

if($vm){

'continue configuration of vm'

}

Two guesses.. It either hangs after the task or it actually runs the remainder of the script before the task is complete. A similar script against hyperv does not behave this way. Anyhow, the problem is solved with the wait-task.