Skip to content

Prepare OpenShift

For seamless integration of the OpenShift platform with the HyWorks Controller, follow the guidance below:

Supported HyWorks Versions

  • HyWorks v4.1 or later.

Supported Versions

Provider Supported Versions
OpenShift Cluster v4.21.2, v4.20.15

Supported Feature Matrix

Feature Sub Feature Details OpenShift Support
VM Details OS Information - Yes
Network Adapters / IP Addresses - Yes
Hostname - Yes
Desktop pool with existing VMs Using Non-provisioned VMs - Yes
Desktop VM Provisioning Clone Type Linked / Full / Shadow Full Clone
Automatic Distribution of VMs Best Host Selection No
Multi-Datastore & Best Storage Selection No
Clone from Snapshot / Checkpoint Feature Support Yes
Create Snapshot from Management Console Yes
Disk Persistence Persistent Yes
Non-persistent (Create/Delete restore point on user logoff) Yes
VM Profile (v3.6+) Deployment Location & Hardware Specs No
Recompose Preserve Network / MAC Address Yes
Graceful / Selective Recompose Yes
Override server defaults No
SHD Provisioning Automatic Deployment of Session Teams Yes
Capacity Planning Multi-session / Shared Hosted Desktops Yes
Dedicated / Single-session Desktop Yes
Schedule Action Support Yes
Desktop Power Operations - - Yes
Desktop Access Remote Desktop - Yes
Console Connect - No
HyLabs Support Scheduled Provisioning - No
HyLabs Features Resource Pool Management - No
SHD Virtual IP
(Session host IP virtualization)		 Add IP to NIC - Yes
vTPM Support Feature Support (Cloning the vTPM Enabled Machines) - No
vTPM Aware Cloning (Selecting best host based on vTPM support) - No

OS Support on Providers

OS Support on Providers:

Feature Sub Feature Supported on providers
OS Support on Provider Windows Desktops: Windows 11,10 All connectors
Windows Server 2025/2022/2019/2016 All connectors
Linux Desktops: Ubuntu / xUbuntu 24/22 All connectors except
HPE VM Essentials (Having issues)
Linux Desktops: RHEL 9.4 All connectors except
HPE VM Essentials (Having issues)

Feature Comparison - Provider

Click here to view the feature comparison across supported hypervisors.

Prerequisites

Important Ports

  • 6443 is used to connect to OpenShift Cluster.

VirtIO Drivers

Please install of vitIO drivers and tools on all the desktops, it is required for reflecting the IPs on the console and inside the VM.

Additional Configurations with OpenShift Connector

In standard HyWorks deployments, the following basic network requirements are expected:

  • HyWorks Controller must have reachability to the connector (OpenShift in this case) and to the VMs deployed through the connector.

  • VMs must correctly identify their internal IP addresses, and these IPs must match the addresses captured from the connector by HyWorks.

By default, OpenShift uses pod networking in masquerade mode, which may cause network communication issues as explained below:

  • Internally, VMs fetch IP addresses in the range 10.0.2.x.

    • Possible problems:

      • HyWorks Controller nodes detect their own IP addresses for high-availability checks. Incorrect IP detection may cause failures.

      • Similarly, VMs detect their IP addresses and report them via VM Scale Booster. HyWorks may receive incorrect IP addresses, causing connection failures.

    • Additional limitations:

      • No direct VM-to-VM communication.

      • Isolated networking per VM.

Therefore, HyWorks Controller with the OpenShift cluster requires additional network configuration. This section of the document provides example configurations.

Important

These are example configurations only. Production deployments may use newer or more appropriate configurations.

Example Solution Network Configurations

By default, OpenShift uses pod networking in masquerade mode, which does not allow direct VM-to-VM or external network communication. To enable communication between HyWorks Controller and other VMs must have network added in all the VMs.

This can be achieved using the following example network models:

  1. Multus Bridge > When External LAN available.

  2. OVN Layer2 > When Lab/ isolated environments.

1. Multus Bridge Network (External Network Available)

This setup enables VMs to connect directly to an external Layer-2 network.

Reference Documentation

  • OpenShift NMState Documentation: https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/kubernetes_nmstate/k8s-nmstate-updating-node-network-config

  • OpenShift Virtualization Networking: https://docs.openshift.com/container-platform/latest/virt/vm_networking/virt-networking-overview.html

  • KubeVirt Networking: https://kubevirt.io/user-guide/network/interfaces_and_networks/

  • Multus CNI: https://github.com/k8snetworkplumbingwg/multus-cni

Architecture Flow

VM > Multus Interface > br-external > ens35 > External Network

OpenShift Worker Node Configuration

Configure worker nodes to create a Linux bridge attached to physical NIC.

Step 1.1: Identify Network Interface

Run following command to check all of the network interfaces on the node:

ip a

Step 1.2: Create NodeNetworkConfigurationPolicy

An example YAML file is provided below with:

  • Name as br-external-policy.

  • Worker node interface used: ens35 (The interface identified in previous step.)

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br-external-policy
spec:
  desiredState:


interfaces:
  - name: br-external
    type: linux-bridge
    state: up
    ipv4:
      dhcp: true
      enabled: true
    bridge:
      options:
        stp:
          enabled: false
      port:
        - name: ens35

  - name: ens35
    type: ethernet
    state: up
    ipv4:
      enabled: false
    ipv6:
      enabled: false

  nodeSelector:


node-role.kubernetes.io/worker: ''
Step 1.3: Apply Configuration

Execute following command via OpenShift-CLI:

oc apply -f br-external-policy.yaml

Step 1.4: Verification

Execute following command via OpenShift-CLI:

oc get nncp: Shows Network Policies status.

oc get nnce: Shows execution status on nodes.

ip a | grep br-external: Confirms bridge exists on node.

Step 1.5: Multus Configuration

Define a network that VMs can attach to:

  • It uses the bridge created in previous steps.
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: external-lan
  namespace: default
spec:
  config: |


{
  "cniVersion": "0.3.1",
  "type": "bridge",
  "bridge": "br-external",
  "ipam": {}
}
Step 1.6: Attach Network Interface to the VMs

Make sure the virtual machine or Gold master is in shutdown mode. In virtual machine configurations, modify to attach network to VM.

Now the VM should be

Note

This configuration enables OpenShift VMs to connect to an external network using a bridge attached to a physical NIC. It requires external DHCP and proper network configuration.

2. OVN Layer 2 Multus Network (External Network Not Available)

Configure an internal Layer-2 network for Virtual Machines (VMs) in OpenShift using a NetworkAttachmentDefinition (NAD) with OVN-Kubernetes.

This approach is used when an external network is not available and VM-to-VM communication is required.

Reference Documentation

  • OpenShift Networking (OVN-Kubernetes): https://docs.openshift.com/container-platform/latest/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.html

  • Multus CNI: https://github.com/k8snetworkplumbingwg/multus-cni

  • KubeVirt Networking: https://kubevirt.io/user-guide/network/interfaces_and_networks/

After Configurations

Once the successful configurations are done, following points can be observed:

  • VMs share same subnet.

  • Direct VM-to-VM communication enabled

  • No dependency on external network

  • Ideal for lab / isolated environments

Architecture Flow

VM > Multus Interface > OVN Layer2 Network > Other VMs

All VMs are connected to the same logical switch.

Configurations
Step 2.1: Create NetworkAttachmentDefinition

Create a YAML with following example content:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: default-ovn-net2
  namespace: default
  annotations:
    k8s.ovn.org/network-name: default-ovn-net2
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "default-ovn-net2",
      "type": "ovn-k8s-cni-overlay",
      "topology": "layer2",
      "subnets": "10.20.0.0/24",
      "gateway": "10.20.0.1"
    }

Explanation

  • type: ovn-k8s-cni-overlay: Uses OVN-Kubernetes SDN for networking.

  • topology: layer2: Creates a Layer 2 network (same broadcast domain).

  • subnets: 10.20.0.0/24: Defines IP range for VMs.

  • gateway: 10.20.0.1: Default gateway inside overlay network.

  • annotations: Required for OVN to identify the network.

Step 2.2: How to Apply

  • Step 2.2.1: Create NAD

    oc apply -f ovn-net.yaml

  • Step 2: Verify

    oc get network-attachment-definitions -n default

Step 2.3: VM Configurations

Make sure the virtual machine or Gold master is in shutdown mode. In virtual machine configurations, modify to attach network to VM:

interfaces:
- name: net1
  bridge: {}

networks:
- name: net1
  multus:
    networkName: default/default-ovn-net2
Behavior
  • VMs receive IP from 10.20.0.0/24
  • VMs can communicate directly
  • No external dependency
  • Works across nodes
Validations

  • IP Address Verifications: Assuming example of a Linux VM, run the following command to check the networks and IP address assigned:

    ip a

  • Connectivity Test

    ping <other-vm-ip>

Note

This configuration creates an internal Layer 2 network using OVN-Kubernetes. It enables direct VM communication without requiring external networking and is ideal for isolated or lab environments.

Common Network Issues

While working with OpenShift, following issues may be observed with some workarounds suggested:

Issue Cause Resolution
No IP assigned DHCP delay Wait or restart VM
Cannot ping from VM to other. VM level Firewall Disable or add exceptions in firewall
Wrong subnet Misconfiguration Verify NAD
Network not attached
VM not starting post YAML change		 VM config issue Check YAML for any configurations mistakes.