Prerequisites

Last published : Jul 06, 2026
Note: For Infoscale, DMP is the default multipathing driver. Any other multipath driver must be disabled for DMP/Infoscale to function properly.
  1. Be ready with the following information -
    • Names of all the nodes. Deploying Infoscale for Kubernetes on OCP master nodes is not recommended as it may cause conflict with kube-controller port.
      Note: Run oc get nodes -o wideon the bastion node to obtain Names and IP addresses of the nodes.
      Use NAME and INTERNAL-IP from the output similar to the following -
      NAME                STATUS ROLES  AGE VERSION         INTERNAL-IP
      ocp-cp-1.lab.ocp.lan Ready master 54d v1.22.1+d8c4430 192.168.22.201
      77.rhaos4.9.gitd745cab.el8
      ocp-cp-2.lab.ocp.lan Ready master 54d v1.22.1+d8c4430 192.168.22.202
      77.rhaos4.9.gitd745cab.el8
      ocp-cp-3.lab.ocp.lan Ready master 54d v1.22.1+d8c4430 192.168.22.203
      77.rhaos4.9.gitd745cab.el8
      ocp-w-1.lab.ocp.lan Ready worker  54d v1.22.1+d8c4430 192.168.22.211
      77.rhaos4.9.gitd745cab.el8
      ocp-w-2.lab.ocp.lan Ready worker  54d v1.22.1+d8c4430 192.168.22.212
      77.rhaos4.9.gitd745cab.el8
      ocp-w-3.lab.ocp.lan Ready worker  54d v1.22.1+d8c4430 192.168.22.213
      77.rhaos4.9.gitd745cab.el8
      ocp-w-4.lab.ocp.lan Ready worker  54d v1.22.1+d8c4430 192.168.22.214
      77.rhaos4.9.gitd745cab.el8
    • Operating system hardware path of the disks which are being managed by other storage vendors that need to be excluded from InfoScale disk group.
    • Optionally if you want to exclude boot disks, device path to the boot disks.
      Note: InfoScale recommends excluding boot disks.
    • If you have internet connectivity and download is allowed, you must be logged in to Red Hat registry.
    • For air gapped systems, Custom Registry address to set up registry where InfoScale images are pushed.
    • Fencing controller and fencing enabler pods require access to an external repository. Allow access to the following registry:
      Fencing registry - "ghcr.io/kvaps"
  2. Ensure that all nodes are synchronized with the NTP Server.
  3. Reserve network ports for exclusive use of InfoScale as under -
    Component Port
    LLT over UDP Serially onwards 50000 (as many as configured LLT links)
    VVR (Needed only if you want to configure DR) 4145 (UDP), 8199 (TCP), 8989 (TCP)
  4. Add local or shared storage to all the worker nodes before you proceed with the deployment.
  5. Ensure that stale InfoScale kernel modules (vxio,vxdmp,veki,vxspec,vxfs,odm,glm,gms) from previous installation do not exist on any of the worker nodes.
    Note: You can reboot a worker node to unload all stale InfoScale kernel modules.
  6. Hostnames of the InfoScale nodes must exactly match with the fully qualified domain names(FQDN) of the OpenShift nodes.
  7. OpenShift cluster must be configured by using IPv4 only.
  8. Cert Manager v1.18x or latest based on the OCP version should be installed.

Configuring kubelet shutdown hook

Note: It is not recommended for users to have master schdulable config because there is a known issue where kube-controller port conflicts with the InfoScale REST port.
Before fresh installation of InfoScale 9.2.0, ensure kubelet shutdown grace settings are configured and rolled out.
To enable kubelet’s graceful shutdown inhibitor on nodes, users must apply two configurations in the following order:
  1. Systemd change with machine config Extends InhibitDelayMaxSec so systemd honors kubelet’s shutdown inhibitor for the full grace period.
  2. Kubelet Configuration shutdown grace periods Defines how long kubelet will wait for regular and critical pods during shutdown.
Both configurations trigger MCP updates and node reboots,so they should be applied deliberately.
Verify KubeletConfig
oc get kubeletconfigs.machineconfiguration.openshift.iooc get kubeletconfigs.machineconfiguration.openshift.io -oyaml | grep -i grace
Required values:
  • shutdownGracePeriod: 15m
  • shutdownGracePeriodCriticalPods: 5m
If missing, apply configuration using the matching flow below.
If above kubeletconfig exists, verify rollout on nodes
ssh core@<worker-node> sudo systemd-inhibit
WHO            UID USER PID  COMM           WHAT     WHY                                        MODE
NetworkManager 0   root 3339 NetworkManager sleep    NetworkManager needs to turn off networks  delay
kubelet        0   root 5476 kubelet        shutdown Kubelet needs time to handle node shutdown delay
Expected kubelet line:
  • COMM: kubelet
  • WHAT: shutdown
  • MODE: delay If kubelet inhibitor is present, config is already effective then below process can be skipped.
Config: Only Worker is schedulable
If above configuration is missing then configure it using following steps.
oc label mcp worker machineconfiguration.openshift.io/role=worker
oc patch mcp worker --type=merge -p '{"spec":{"paused":true}}'
oc get mcp worker -oyaml | grep pause
oc apply -f https://raw.githubusercontent.com/Arctera/infoscale-kubernetes-enterprise/main/config/sysd/99-worker-sysd.yaml
oc apply -f https://raw.githubusercontent.com/Arctera/infoscale-kubernetes-enterprise/main/config/kubelet/kubelet-config.yaml
Unpause MCPs paused in this flow: oc patch mcp worker --type=merge -p '{"spec":{"paused":false}}'
Final validation (before install check this on all the nodes)
oc get kubeletconfigs.machineconfiguration.openshift.io -oyaml | grep -i 'shutdownGracePeriod\|shutdownGracePeriodCriticalPods'
oc get mcp
ssh core@<worker-node> sudo systemd-inhibit
WHO            UID USER PID  COMM           WHAT     WHY                                        MODE
NetworkManager 0   root 3339 NetworkManager sleep    NetworkManager needs to turn off networks  delay
kubelet        0   root 5476 kubelet        shutdown Kubelet needs time to handle node shutdown delay
Re-check: oc get mcp
Note: Do not unpause out of order; it triggers immediate rollout.