test-kitchen/kitchen-hyperv

Failing to set IP on Windows VM

Closed this issue · 11 comments

rschiefer commented

This is likely my ignorance with HyperV and Kitchen but hoping to learn something and provide help to others with the same issues.

In trying two different Windows Server 2008 R2 VHDs, kitchen create fails to set the IP address on the VM which causes the process to timeout trying to connect to the newly created VM. I tried the following VHDs:

I pulled the vhd out of the vagrant box. I am not using the vagrant driver.

I traced the issue to the SetGuestNetworkAdapterConfiguration method call in the Set-VMNetworkConfiguration function throwing an error:

__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 2
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
Error : 104The operation
failed.<PROPERTY.ARRAY NAME="MessageArguments"
TYPE="string"><VALUE.ARRAY></VALUE.ARRAY></PROPERTY.ARRAY>16010Microsoft-Windows-Hyper-V-VMMS50<PROPERTY.ARRAY NAME="RecommendedActions"
TYPE="string"></PROPERTY.ARRAY>
ReturnValue : 0
PSComputerName :

This error was very helpful, at least for me.

I ended up opening the VM window from the HyperV management interface. The OS automatically installed some driver and then requested a reboot as soon as I logged in. After reboot the IP address was set as expected. Calling kitchen create then completed successfully. This was with the VHD from the Vagrant box.

So I'm assuming my VHDs are not configured correctly for Kitchen but not sure how to fix them or create an appropriate VHD. Any help is greatly appreciated.

Here is the driver section from my Kitchen.yml:

driver:
name: hyperv
parent_vhd_folder: D:\vhds
parent_vhd_name: packer-virtualbox-iso-1458688988.vhd
vm_switch: DefaultHyperVNAT
ip_address: 1.1.1.10
username: vagrant
password: vagrant

Version info:

Chef Development Kit Version: 1.2.22
chef-client version: 12.18.31
delivery version: master (0b746cafed65a9ea1a79de3cc546e7922de9187c)
berks version: 2017-03-05T07:27:13.998968 13076] 2017-03-05T07:27:13.998968 13076] 2017-03-05T07:27:13.999451 13076] 2017-03-05T07:27:13.999451 13076] 2017-03-05T07:27:14.078969 13076] 2017-03-05T07:27:14.078969 13076] 5.6.0
kitchen version: 1.15.0

*** LOCAL GEMS ***

kitchen-dokken (2.1.2, 1.1.0)
kitchen-ec2 (1.3.2, 1.2.0)
kitchen-hyperv (0.3.0)
kitchen-inspec (0.17.0)
kitchen-pester (0.7.1)
kitchen-vagrant (1.0.2, 1.0.0)
test-kitchen (1.15.0)

Microsoft Windows [Version 10.0.14393]

smurawski commented

Thanks for digging in @rschiefer. What I think is going on is that the 2008r2 image you are using does not have the minimum level of hyperv integration components (I think at least 2012 server's ICs are required to get the ability to set the guest IP). I haven't bumped into it because I've built all my base images on hyperv which would have updated the ICs. I'll look at clarifying the docs and errors.

robbAtEBSCO commented

I installed the Hyper-V Integration Components in my base VM and was able to get Kitchen Create working but had to run it twice with a manual reboot of the VM in the middle. After the first create run the configured IP isn't set but rather an auto configured (169.254..) address instead. The WinRM connection fails against this IP address.

If I logon to the VM manually it has a reboot request window pending. After reboot the IP is set to the static IP configured in my kitchen.yml file. Then a second create run is able to find the VM, connect over WinRM and complete successfully.

Not sure why the reboot is required but guessing the static IP configuration or network switch change is forcing it.

Is there a way to force a reboot during create? Or is there some other workaround?

smurawski commented

@robbAtEBSCO I've never had to reboot once the integration components were installed. How are you installing the ICs? Are you rebooting after that before making that your base image?

rschiefer commented

Confirmed! That fixed it on my personal laptop first time. Then tried on the work laptop and still got at 169 IP. After throwing a tantrum I remembered what @mwrock had said about having to recreate switches routinely with Win10. Tried that and now it works consistently.

THANKS!

smurawski commented

That may not solve it. 2008 R2 just seems to want to be finicky

mwrock commented

I usually throw a tantrum too prior to recreating the switches. That might be a required step...not sure.

smurawski commented

it was my mistake, after making sure the base image (not the ephermal test image) had the win 10 ICs, things are much more consistent.

rschiefer commented

@mwrock is there an open issue for the switch issue with Windows 10?

mwrock commented

@rschiefer I recently gave some feedback to Ben Armstrong and team that included this issue, but there must be a connect or user voice place I can publicly file at. I'll look.