win_reboot: failed to get host boot time info about ansible.windows

[jborean93]

Potentially but let's leave this one open for now and you can just reference it. I still want to try and play around with it a bit more to figure out if that's really the case.

[MaartenMol]

When running a simple reboot all task with win_reboot, same results: (Also on Windows 10)

Playbook:

---
- name: Reboot Windows machines
  hosts: all
  gather_facts: yes
  tasks:
    - name: Reboot the machine with all defaults
      when: ansible_facts['os_family'] == "Windows"
      win_reboot:

Result:

{
    "reboot": false,
    "msg": "win_reboot: failed to get host boot time info, rc: 1, stdout: , stderr: ",
    "_ansible_no_log": false,
    "changed": false
}

Running it on a basic CentOS 8 host with Ansbile V2.9.5:

ansible-playbook -i inventory_chocoladebol base_reboot.yml -vvvvv
ansible-playbook 2.9.5
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible-playbook
  python version = 3.6.8 (default, Nov 21 2019, 19:31:34) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)]
Using /etc/ansible/ansible.cfg as config file
setting up inventory plugins
host_list declined parsing /root/base_vm/inventory_chocoladebol as it did not pass its verify_file() method
script declined parsing /root/base_vm/inventory_chocoladebol as it did not pass its verify_file() method
auto declined parsing /root/base_vm/inventory_chocoladebol as it did not pass its verify_file() method
Parsed /root/base_vm/inventory_chocoladebol inventory source with yaml plugin
Loading callback plugin default of type stdout, v2.0 from /usr/lib/python3.6/site-packages/ansible/plugins/callback/default.py

PLAYBOOK: base_reboot.yml ********************************************************************************************************************************************************************************************************************************************************************
Positional arguments: base_reboot.yml
verbosity: 5
connection: smart
timeout: 10
become_method: sudo
tags: ('all',)
inventory: ('/root/base_vm/inventory_chocoladebol',)
forks: 5
1 plays in base_reboot.yml

PLAY [Reboot Windows machines] ***************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************************************************************************************************************************************************
task path: /root/base_vm/base_reboot.yml:2
Using module file /usr/lib/python3.6/site-packages/ansible/modules/windows/setup.ps1
ok: [dc-01]
META: ran handlers

TASK [Reboot the machine with all defaults] **************************************************************************************************************************************************************************************************************************************************
task path: /root/base_vm/base_reboot.yml:6
fatal: [dc-01]: FAILED! => {
    "changed": false,
    "msg": "win_reboot: failed to get host boot time info, rc: 1, stdout: , stderr: ",
    "reboot": false
}

PLAY RECAP ***********************************************************************************************************************************************************************************************************************************************************************************
dc-01                      : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

[MaartenMol]

This does not seem to be a module issue but a ansible_connection issue. As I am using the same module win_reboot and win_domain both using WinRM in a new test setup they work without issues. When using ansible_connection: psrp with a socks5h proxy in the middle both modules work without issue.

Is this a bug report for the connection plugin vmware_tools?

[jborean93]

It sounds like a problem with vmware_tools and how we send the command to be executed. Does it work on this host just through the he winrm connection plugin.

[MaartenMol]

It sounds like a problem with vmware_tools and how we send the command to be executed. Does it work on this host just through the he winrm connection plugin.

It does, the win_domain module does also have an issue when using the vmware_tools plugin. While with WinRM plugin and PSRP plugin they work without any issue.

[jborean93]

Ok, this is going to be hard for me to test as I don't have a VMWare host for me to test against. My guess is that because we are running a direct PowerShell cmd https://github.com/ansible-collections/ansible.windows/blob/master/plugins/action/win_reboot.py#L29 against the host for the reboot check it is failing because the shell on the VMWare tools connection plugin is cmd. It's the same for winrm but the actual connection plugin there encodes the script in a powershell command itself so it's not a problem there.

[MaartenMol]

Ok, this is going to be hard for me to test as I don't have a VMWare host for me to test against. My guess is that because we are running a direct PowerShell cmd https://github.com/ansible-collections/ansible.windows/blob/master/plugins/action/win_reboot.py#L29 against the host for the reboot check it is failing because the shell on the VMWare tools connection plugin is cmd. It's the same for winrm but the actual connection plugin there encodes the script in a powershell command itself so it's not a problem there.

Weird because when using VMware Tools as connection plugin, I also let it know that I use Powershell. Example:

fs-01:
      vm_template: Windows2019-Template
      deploy_vsphere_datastore: datastore-01
      guest_custom_ip: 172.27.72.72
      ansible_connection: vmware_tools
      ansible_shell_type: powershell

What can we do to fix or troubleshoot this?

[jborean93]

You tell it to use Ansible's powershell shell plugin but in reality if you were to open a new shell with the VMWare tool it will be in the context of cmd so if you were to run a command it needs to be valid in cmd. The same is also true to the winrm connection plugin but it just makes sure that any commands it executes is wrapped in a powershell command so the default shell of the actual API does not matter.

Ultimately if I am correct here the fix is 1 of 2 choices

1. Change the vmware_tools connection plugin to act the same as winrm and make sure each Windows script that is run is encoded as a powershell command
2. Fix up win_reboot to just always call the command with powershell.exe

The 2nd is definitely easier to do but I'm not sure if that's the right way to go. It opens up the possibility of connection plugins expecting things to always be a valid cmd command when that's not how things are today.

[MaartenMol]

You tell it to use Ansible's powershell shell plugin but in reality if you were to open a new shell with the VMWare tool it will be in the context of cmd so if you were to run a command it needs to be valid in cmd. The same is also true to the winrm connection plugin but it just makes sure that any commands it executes is wrapped in a powershell command so the default shell of the actual API does not matter.

Ultimately if I am correct here the fix is 1 of 2 choices

1. Change the vmware_tools connection plugin to act the same as winrm and make sure each Windows script that is run is encoded as a powershell command
2. Fix up win_reboot to just always call the command with powershell.exe

The 2nd is definitely easier to do but I'm not sure if that's the right way to go. It opens up the possibility of connection plugins expecting things to always be a valid cmd command when that's not how things are today.

I Agree, option 2 seems easy but not the way to go. I think this makes the only option to open up a request over at the vmware_tools plugin repo?

[VentGrey]

Still happening when connection type is NTLM:

[gdlkk]

Anyone got resolved that?

[VentGrey]

@gdlkk Check your Powershell permissions. I had to do that over a year ago. Try looking for the default permissions in a Windows installation and check for your ping / rw permissions.

I went through hell to figure that out 😅, not easy to traceback, try asking on an IRC channel or a LUG, or try asking on a more specific place, not the no-one-knows-anything places 🙃