Install-WindowsFeature : Win32 internal error "Access is denied" 0x5 occurred while reading the console output buffer
The following release notes are for previous versions of the Windows Machine Config Operator (WMCO).
For the current version, see Windows Machine Config Operator release notes.
This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OKD cluster. The components of the WMCO 9.0.2 were released in RHBA-2024:2830.
Previously, the kubelet was unable to authenticate with private ECR registries. Beacuse of this error, the kubelet was not able to pull images from these registries. With this fix, the kubelet is able to pull images from these registries as expected. (OCPBUGS-32136)
This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OKD cluster. The components of the WMCO 9.0.1 were released in RHSA-2024:1203.
Previously, because of a lack of synchronization between Windows machine set nodes and Bring-Your-Own-Host (BYOH) instances, during an update the machine set nodes and the BYOH instances could update simultaneously. This could impact running workloads. This fix introduces a locking mechanism so that machine set nodes and BYOH instances update individually. (OCPBUGS-22984)
Previously, because of a missing secret, the WMCO could not configure proper credentials for the WICD on Nutanix clusters. As a consequence, the WMCO could not create Windows nodes. With this fix, the WMCO creates long-lived credentials for the WICD service account. As a result, the WMCO is able to configure a Windows node on Nutanix clusters. (OCPBUGS-24748)
Previously, because of bad logic in the networking configuration script, the WICD was incorrectly reading carriage returns in the CNI configuration file as changes, and identified the file as modified. This caused the CNI configuration to be unnecessarily reloaded, potentially resulting in container restarts and brief network outages. With this fix, the WICD now reloads the CNI configuration only when the CNI configuration is actually modified. (OCPBUGS-27046)
Previously, because the WMCO performed an erroneous sanitization step that replaced commas with semicolons in the cluster-wide proxy configuration, Windows would ignore the endpoints specified in the noProxy
parameter. As a consequence, traffic was being incorrectly sent through those proxies. With this fix, the sanitization step was removed. As a result, a web request from a Windows node to a cluster-internal endpoint or an endpoint that exists in the noProxy
parameter does not go through the proxy. (OCPBUGS-27240)
Previously, because of routing issues present in Windows Server 2019, under certain conditions and after more than one hour of running time, workloads on Windows Server 2019 could have experienced packet loss when communicating with other containers in the cluster. This fix enables Direct Server Return (DSR) routing within kube-proxy. As a result, DSR now causes request and response traffic to use a different network path, circumventing the bug within Windows Server 2019. (OCPBUGS-28226)
This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OKD cluster. The components of the WMCO 9.0.0 were released in RHSA-2023:1372.
Clusters that use a cluster-wide proxy now support WMCO. Starting with OKD version 4.14, WMCO can consume and use a global egress proxy configuration when making external requests outside the cluster’s internal network. For more information, see Configuring the cluster-wide proxy.
Clusters installed on Nutanix now support Windows Server 2022 nodes. You can create a Windows machine set on Nutanix to host Windows Server 2022 compute nodes. For more information, see Creating a Windows machine set on Nutanix.
WMCO now supports the windows-priorityclass
kubelet parameter, which ensures that running pods do not deplete the kubelet of CPU cycles. By default, the windows-priorityclass
parameter is set to ABOVE_NORMAL_PRIORITY_CLASS
. It is not recommended to change this setting. For more information on this parameter, see CPU management in the Kubernetes documentation.
WMCO now supports the use of persistent storage for Windows workloads, without the use of in-tree storage drivers, by running the CSI Proxy service on each Windows node. Windows pods on each node now have access to storage through persistent volume claims.
With CSI proxy running on a cluster’s Windows nodes, you can deploy the Container Storage Interface (CSI) storage drivers of your choice as a Windows daemon set. For more information on CSI Proxy, see CSI Windows Support (with CSI Proxy) in the Kubernetes documentation. For information on CSI, see Configuring CSI volumes in the OKD documentation.
Previously, on an Azure Windows Server 2019 platform that does not have the Azure container service installed, WMCO would fail to deploy Windows instances and would display the following error message:
Install-WindowsFeature : Win32 internal error "Access is denied" 0x5 occurred while reading the console output buffer
The failure occurred because the Microsoft Install-WindowsFeature
cmdlet displays a progress bar that cannot be sent over an SSH connection. This fix hides the progress bar. As a result, Windows instances can be deployed as nodes. (OCPBUGS-13244)