Closed ader1990 closed 5 years ago
Looks like deleting iSCSI targets (root/cimv2:WT_Host) is one of the cases in which that error can show up: http://paste.openstack.org/raw/770134/
One idea would be to switch the protocol only as a fallback for WBEM_E_PROVIDER_NOT_CAPABLE errors. The alternative is to have the caller do this, but it's much more convenient to handle it at the pymi level, especially since we don't know how many other classes are affected by this.
For what is worth, I used a WS 2016 host.
@petrutlucian94 I have done some tests and the fix works on my setup.
If PyMi protocol is set to WMIDCOM and WinRM is not enabled in the Windows instance, all the deleteinstance calls (.Delete) will fail.
This issue appears because, on delete_instance calls, the protocol is hardcoded to WINRM for apparent issues with DCOM protocol.
This issue has been introduced by: https://github.com/cloudbase/PyMI/commit/2170d5c0520db1b045dc9e166c743b9e8b1fb950
I tested the behaviour without the offending commit and the issue for which the commit was made did not appear. Windows version tested: Windows Server 2012R2, 2016 and 2019 WMI classes tested: MSFT_NetRoute, MSFT_NetIPAddress
Error log when using PyMI master, Windows Server 2016/2019 with WinRM disabled when trying to remove MSFT_NetIPAddress instances :
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". (-2144108526)