Enable Day 2 MTU Migration for  Hosted Clusters on Kubevirt.

When the MTU of a hosting (management) cluster is changed, the Hosted Control Planes (HCPs) running on it do not automatically detect or adapt to this change. The hosted cluster's network operator continues to use the old MTU value, causing a configuration mismatch with the underlying node network. This leads to network-related components failing and the entire hosted cluster entering a degraded state.
The request is to implement a mechanism where a hosted cluster can automatically reconcile its network configuration to match the new MTU of its hosting cluster, ensuring it remains healthy and operational without requiring manual intervention or a complete cluster recreation.

The customer needs this functionality to ensure operational stability and flexibility in their production environments. The key business requirements are:
Maintain Operational Parity: Customers expect to perform standard network maintenance, such as MTU changes, on their infrastructure without causing catastrophic failure to the services running on it. This feature would bring HyperShift's capabilities closer to that of a standard OpenShift deployment.
Avoid Disruptive Workarounds: The current solution of deleting and recreating an entire hosted cluster to update its MTU is operationally unacceptable. It introduces significant downtime, increases administrative overhead, and poses a risk to business continuity.
Increase Platform Reliability and Trust: A predictable, supported process for common Day 2 operations is essential for enterprise adoption. This feature would make the HyperShift platform more robust and trustworthy for environments with evolving network infrastructure.
Reduce Total Cost of Ownership (TCO): By eliminating the need for lengthy and risky cluster rebuilds for a routine network change, this feature reduces the operational hours and potential downtime costs associated with managing a HyperShift environment.

Cluster Network Operator (CNO): The operator within the hosted cluster responsible for managing its network configuration.
OVN-Kubernetes: The underlying CNI (Container Network Interface) whose configuration (including MTU) needs to be updated.
OpenShift Virtualization (KubeVirt): As the context often involves VMs running on the hosting cluster.
OpenShift Console: The UI components for both HyperShift and Virtualization need to accurately reflect the status and not enter a broken state.