Raw Device Mapping (RDM) passthrough for InfoScale application VMs

Last published : Jul 13, 2026

Overview

InfoScale for Kubernetes (IKE) can present existing raw SAN LUNs from an on-premise InfoScale cluster directly into virtual machines running on OpenShift Virtualization (OCP-V) as passthrough—raw device mapped (RDM)—devices. The InfoScale application VMs run as OCP-V virtual machines on the IKE cluster nodes, and each VM consumes the same physical SAN LUNs the source cluster used.
This is the OCP-V equivalent of VMware physical-mode Raw Device Mapping (pass-through RDM): the guest OS gets near-direct SCSI access to the LUN, so the in-guest InfoScale/VCS stack can perform its own multipathing, SCSI-3 persistent reservations, and I/O fencing.
You can use this to re-host an existing VMware RDM-based InfoScale cluster by reusing its LUNs in place without copying data—meaning the source cluster is re-hosted, not migrated—or to build a new InfoScale application cluster that needs raw, shared-LUN access (for example, in-guest VCS/SF clustering with SCSI-3 PR).

How it works (at a glance)

You create a static PersistentVolume that carries the LUN's WWID; the InfoScale CSI driver resolves that WWID to a VxVM DMP device on the node; the device is passed into the VM as a KubeVirt lun disk; the guest sees a raw, multipathed SAN LUN.

Terminology

|Term|Meaning| |--|--| |RDM (pass-through)|Presenting a raw SAN LUN to a VM so the guest issues SCSI commands directly to it (VMware physical compatibility mode equivalent).| |WWID / WWN|World Wide Identifier — the unique, path-independent SCSI identifier of a LUN (SCSI VPD page 0x83). WWN and WWID are the same thing.| |NAA-6|The required format of that WWID: Network Address Authority Type 6 (e.g. 600a0980...). NAA-6 compliant means the array exposes a Type-6 WWID.| |DMP|InfoScale Dynamic Multi-Pathing — one pseudo-device (/dev/vx/dmp/<dev>) for all physical paths to a LUN.| |SCSI-3 PR|SCSI-3 Persistent Reservations — keys that let clustered nodes coordinate shared-disk ownership and fence a failed node (prevents split-brain).| |SG_IO|The Linux SCSI pass-through ioctl the guest uses to send raw SCSI commands (including PR) to the LUN.|

Prerequisites

  • IKE prerequisites met; the IKE cluster is Running and Healthy.
  • InfoScale block storage class is configured, reflecting the correct topology mapping when multiple InfoScaleClusters exist.
  • SCSI-3 PR enabled in the OpenShift Virtualization configuration — it deploys the privileged qemu-pr-helper daemon that performs SCSI-3 reservations for the VM. Without it, reservation: true has no effect.
  • SG_IO works with the VxVM-backed volumes — the in-guest InfoScale stack issues raw SCSI commands (including PR) through SG_IO; the DMP device must pass these through.
  • The array is NAA-6 compliant — the CSI driver identifies each LUN by its Type-6 WWID; a non-compliant identifier cannot be resolved reliably.
  • A dedicated secondary network for the InfoScale application VMs — in addition to the default pod network, for the in-guest cluster's private interconnect/heartbeat. It is wired to a physical interface using a NodeNetworkConfigurationPolicy (NNCP) and exposed to VMs via a NetworkAttachmentDefinition (NAD).
  • Disk-based I/O fencing host placement — VMs of the same cluster that share RDM disks must run on separate physical hypervisor hosts (co-located VMs cannot arbitrate SCSI reservations against each other).
  • Note that NetApp luns are not supported.

Procedure

Step 1: Compile the passthrough LUN list

Build the list of LUNs to pass through, each with its WWID. Obtain WWIDs from the storage array console or standard OS utilities (for example, sg_inq -p 0x83 <device>).
Note: Ensure each RDM WWID is not already part of any active InfoScale cluster, data (vrts_kube_dg-*) or coordinator (vrts_coord_dg-*) disk group — the driver does not enforce this by default.

Step 2: Create a static PV and PVC for each LUN

Create one PersistentVolume and PersistentVolumeClaim pair per WWID:
# Static PV consuming an RDM LUN
apiVersion: v1
kind: PersistentVolume
metadata:
  name: rdm-disk-1
spec:
  accessModes:
  - ReadWriteMany                 # RWX: same LUN is read-write on every node whose VM uses it
  capacity:
    storage: 40Gi
  csi:
    driver: org.veritas.infoscale # routes this PV to the InfoScale CSI driver
    volumeAttributes:
      wwid: 600A098038314F36612B587549484D59        # NAA-6 WWID of the LUN
    volumeHandle: clust_21432/wwid-600A098038314F36612B587549484D59  # <IKE cluster id>/wwid-<WWID>
  persistentVolumeReclaimPolicy: Retain   # never reclaim/erase a pre-existing SAN LUN on PVC delete
  storageClassName: csi-infoscale-sc-block
  volumeMode: Block               # raw block device (no filesystem) - required for LUN passthrough
---
# Linked PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-rdm-disk-1
  namespace: openshift-virtualization-os-images   # set to the InfoScale VM's namespace
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 40Gi
  storageClassName: csi-infoscale-sc-block
  volumeMode: Block
  volumeName: rdm-disk-1           # must match the static PV name above

Step 3: Configure the secondary network

Create the NodeNetworkConfigurationPolicy (to bind the physical interface into a bridge on the nodes) and the NetworkAttachmentDefinition (to expose that bridge to VMs). See the Red Hat OpenShift Virtualization documentation for creating these resources.

Step 4: Define the InfoScale VM with the RDM LUN

Attach each RDM PVC to the VM as a lun device (not a disk), and connect the VM to the secondary network before starting the InfoScale workload:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: infoscale-vcs-sample-vm
  namespace: openshift-virtualization-os-images   # must match the PVC namespace
spec:
  runStrategy: Running
  template:
    spec:
      domain:
        devices:
          disks:
          - name: rootdisk               # OS disk - ordinary virtualized disk
            bootOrder: 1
            disk:
              bus: virtio
          - name: rdm-disk-1-mapping     # InfoScale RDM LUN
            lun:                         # expose as a LUN -> SCSI commands pass through to the guest
              bus: scsi                  # LUN passthrough requires a virtual SCSI bus
              reservation: true          # enable SCSI-3 PR (in-guest fencing / shared-disk arbitration)
            shareable: true              # same LUN used by multiple VMs; no hypervisor write-lock
            errorPolicy: report          # report I/O errors into the guest (InfoScale handles them)
      volumes:
      - name: rootdisk
        containerDisk:
          image: quay.io/kubevirt/rhel9-container-disk-demo:latest
      - name: rdm-disk-1-mapping
        persistentVolumeClaim:
          claimName: pvc-rdm-disk-1

Step 5: Start the VM and bring up the cluster

Start the VM(s) and configure the in-guest InfoScale/VCS cluster on the passthrough LUNs.

Why these VM settings are mandatory

|Setting|Why is it required| |--|--| |lun: (not disk:)|Exposes the volume as a real LUN so the guest can issue raw SCSI commands - the pass-through-RDM behaviour InfoScale needs. A plain disk virtualizes the device and blocks this.| |bus: scsi|LUN passthrough must sit on a virtual SCSI bus.| |reservation: true|Enables SCSI-3 Persistent Reservations (via qemu-pr-helper) so the in-guest cluster can register keys, reserve the shared LUN, and fence a failed node.| |shareable: true|Tells QEMU the LUN is accessed by multiple VMs and not to take an exclusive write lock - coordination is done by the in-guest cluster and SCSI-3 PR, not the hypervisor.| |errorPolicy: report|On an I/O error, surface it into the guest so InfoScale (DMP path failover, cluster failover) handles it. The KubeVirt default would instead stop the VM.| |accessModes: ReadWriteMany|The same LUN must be read-write concurrently from every node running a cluster VM.| |volumeMode: Block|The guest must receive the raw block device; a filesystem-mode volume cannot be passed through as a LUN.| |persistentVolumeReclaimPolicy: Retain|The LUN holds pre-existing customer data - it must never be erased or reclaimed when the PVC is deleted.| |volumeHandle|Tells the driver which IKE cluster owns the mapping and which LUN (by WWID) to resolve to a DMP device.|

Limitations (IKE 9.2)

For InfoScale VMs consuming RDM disks with SCSI-3 PR enabled:
  • CSI operations — RDM disks are static PVs backed by a DMP device, so CSI resize, snapshot, and clone are not supported. Consequently, VM snapshot and VM clone do not apply. Back up the underlying LUNs using array snapshots or in-guest tools.
  • Cold migration only — VMs with SCSI-3 PR disks are not LiveMigratable (the reservation is bound to the node's initiator and cannot migrate). Only cold migration is possible.
  • Upgrade — During IKE or OpenShift upgrade these VMs must be restarted on another node; IKE upgrade pauses while such a VM is running and prompts you to move the workload.
  • Hot plugging — Persistent Reservation disks cannot be hot-plugged into a running VM (virtctl addvolume, UI, or VM patching are unsupported). Add RDM disks before first boot, or stop, patch, then start.
  • Unplanned node restarts — An unplanned reboot can leave failed VMIs needing cleanup; if VMI deletion is stuck behind the application-protection gate, remove the PVC finalizer.
  • Do not attach a LUN already in use by InfoScale — Ensure a LUN is not already part of an InfoScale cluster or fencing disk group before attaching it. Attaching an in-use LUN fails the mount with “VolumeID mapping failed” / “Requested URL not found.”
  • Fencing recovery after node failure — When a fenced VM is rescheduled to another host after a node failure, stale SCSI-3 PR keys can remain registered from the old node with no automatic re-registration; verify and clear keys as part of recovery.