Failing to test WinRM availability when creating vm

[gaelcolas]

Versions:

• Version of Chef-Provisioning: 2.2.1
• Version of Chef-Provisioning-vSphere: 2.0.2
• Version of Chefdk: 1.3.40
• Version of Chef-client: 12.19.36
• Version of kitchen: 1.16.0

Platform Details

• Version of vSphere/vCenter: 6.0
• Version of ESXi: 6.0

Scenario:

Trying to create/converge windows VM from custom template via Test-Kitchen.

Steps to Reproduce:

With a very raw template (vanilla Win2012R2 + updates + wmf5 + vmtools) we did not encounter this problem, but adding a few configuration (proxy for SYSTEM account + certificate) and deriving a template from this the problem started to appear.
I haven't found the root cause, but I suspect it takes slightly longer for the vmtools to kick in.

Expected Result:

New machine with template started, nodes/ folder containing the created VM details, and ability to destroy created vm.

Actual Result:

The process errors just before it should Wait for available IPs, without (re)attempting to connect.

Power on VM [Build Automation/AfterBootstrap-2012r2-WMF5-a2f53cf8]
waiting for AfterBootstrap-2012r2-WMF5-a2f53cf8 (503a128d-c7ac-7893-d65a-549eb690e9d4 on vsphere://vsphere/sdk?use_ssl=true&insecure=true) to be ready ...
........AfterBootstrap-2012r2-WMF5-a2f53cf8 is now ready
waiting up to 90 seconds for customization
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #create action: [The requested address is not valid in its context. - The requested address is not valid in its context. - connect(2) for "0.0.0.0" port 5985 (0.0.0.0:5985)] on AfterBootstrap-2012r2-WMF5 >>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

The error log shows the winrm is raising that exception, and some debugging pointed me to this line: vm_ip ||= ip_to_bootstrap(boostrap_options,vm)

As I could see that vm_ip was nil and being passed to transport_for and then to create_winrm_transport, I changed the problematic line like so:
vm_ip = vm.guest.ipAddress || ip_to_bootstrap(bootstrap_options, vm)

That did the trick (we only rely on DHCP provided addresses), although I'm not sure that's a fix, as I'm not familiar with driver, let alone ruby.

Here's our kitchen.yml (sanitized):

driver:
  name: vsphere
  driver_options:
    host: 'vsphere'
    user: 'domain\user'
    password: <%= ENV['vspherePassword'] %>
    insecure: true
  machine_options:
    start_timeout: 700
    create_timeout: 800
    ready_timeout: 90
    bootstrap_options:
      use_linked_clone: true
      datacenter: 'DC'
      template_name: 'windows2012R2'
      template_folder: 'folder/subfolder'
      datastore: datastore
      vm_folder: 'folder/subfolder'
      memory_mb: 4096
      resource_pool: 'Cluster/Pool'
      ssh:
        user: 'Administrator'
        password: <%= ENV['vmpassword'] %>
        port: 5985
      customization_spec:
        win_time_zone: 55
        domain: local  
        winrm_transport: negotiate
        org_name: 'BLAH'
        product_id: ''

transport:
  name: winrm
  username: Administrator
  password: <%= ENV['vmpassword'] %>

provisioner:
    name: dsc
    dsc_local_configuration_manager_version: wmf5
    dsc_local_configuration_manager:
      reboot_if_needed: true
    configuration_script_folder: examples
    configuration_script: dsc_configuration.ps1

verifier:
  name: pester
  test_folder: tests/integration

platforms:
  - name: 2012r2_WMF5
    os_type: windows
    shell: powershell
    transport:
      name: winrm

suites:
  - name: AfterBootstrap

Does that makes sense?
Happy to do more testing for a better fix.

[juanxhos]

I see your problem, @jjasghar I can do a fast fix.
I can added on #32

[gaelcolas]

[edited line: 349 and 465]
Hi,

I found that the patched version did not fix the issue.
To hack a fix in, I inserted the following code in two places, just before this line and just before that one:

if vm_ip.eql? ''
  vm_ip = vm.guest.ipAddress
end

Hope that helps.

[jjasghar]

Is this resolved? If so please close it 🤘 .

[gaelcolas]

I'm afraid I still had the issue with 2.0.4.
Please bear with me as I am trying to reproduce and get the logs out from a secure environment...
Hopefully tomorrow!

[Belogix]

@gaelcolas My PR that was merged should contain the fix but hasn't been released yet. If you look at #38 and make changes on your instance this will hopefully fix. Next release should contain my code and solve your issue.

[gaelcolas]

Indeed @Belogix, #38 seems to have fixed it.
I'll run a few more tests, but so far it works!

Thank you and @jcalonsoh for the help. I'll also test when it gets released, and close the issue then.

[jjasghar]

As soon as #41 is completed I'm going to release the gem.

[gaelcolas]

Tested 2.0.5 this morning and it works like charm!
Thanks for the fix!

Closing.