Known Issues
The following issues are observed during testing in an internal test environment. The issues have remained unresolved and you might encounter these issues. The issue is described and if a workaround exists to resolve the issue, it is mentioned.
Note: Workaround is a temporary solution to the issue. InfoScale is working towards fixing the issue.
Related information
Table: Issue description and workaround
| Description | Workaround |
|---|---|
| Deployment fails because of issues related to kernel module load/unload. (VIKE-4603) | Reboot the worker node on which the SDS pod fails to come up. |
| Licensing Operator does not upgrade as part of the install plan during OLM upgrade from version 8.0.310 to 8.0.320 due to different channels for operators. (VIKE-4570) | Upgrade the Licensing Operator separately. |
Deleting InfoScale pods by using oc delete pods or kubectl delete pods command might result in Configuration failure. (4045599) |
To undeploy InfoScale, delete by using InfoScale CR procedure. |
| On a VMware Virtual Machine, deployment of InfoScale on OpenShift or Kubernetes fails if Disk UUID is not enabled. (4046388) | Enable Disk UUID before deployment. See Enabling disk UUID on virtual machines . |
| For space-optimized snapshots, if writes on volume are more than size of cache object size, a write error is observed. This leads to snapshot volume getting marked as INVALID after detaching the mirror. (4043239) | Use space-optimized snapshots only in cases where expected rate of data change is much smaller than actual data volume size. |
| When a file system is 100% full, and PVC resize is attempted, allocating space for the metadata or the config files that are required for file system resize might fail, causing PVC resize failure. (4045020) | Contact InfoScale support for system recovery. |
| Deployment of pods with PVC which are restored from a snapshot or are cloned from another PVC and is initiated in ReadOnlyMany(ROM) access mode fails. Deployment goes into CreateContainerError state. (4040975) | Set the following deployment parameters to True - Pod.spec.volumes.persistentVolumeClaim.readOnly and Pod.spec.containers.volumeMounts\[x\].readOnly . |
Disk initialization performed by using the vxdisksetup command fails with the following error message - VxVM vxdisksetup ERROR V-5-2-1120 node002_vmdk0_0: Disk is tagged as imported to a shared disk group. Can not proceed. . (4045033) |
Ensure that the disk does not belong to any other diskgroup. If it does not belong to any other diskgroup, the disk might have some stale metadata. Run vxdiskunsetup on the disk and try disk initialization again. |
| A message 'File missing or empty: /boot/grub/menu.lst' is displayed even after a successful disk initialization. (4039351) | Ignore the message. |
| When majority of the nodes in a cluster go in a 'NotReady' state, fast failover (kube-fencing) panics nodes. InfoScale fencing panics rest of the nodes. Even after the cluster is back with majority of the nodes in a 'Ready' state, unfinished kube-fencing jobs continue to panic nodes. (4044408) | Manually delete the kube-fencing jobs till the cluster is up. |
| With a heavy workload, node goes in a 'NotReady' state and InfoScale pods are getting killed. (4044963) | OpenShift Container Platform (OCP) runs extra system pods which consume memory. With heavy workloads, pods are killed to clear memory. Try the following -
|
| When a back enclosure is disabled and enabled in a cvm-slave node, disk fails to attach back to the disk group. (4046928) | Login to the InfoScale SDS pod and run /etc/vx/bin/vxreattach . |
| After faulting a slave node, one or more volumes do not get mounted or existing volumes get unmounted inside application pod. (4044533) | Reschedule/restart the pod to mount the volume. |
| If a worker node is powered off or rebooted, the node goes into emergency shell and enters NotReady state, thus becoming inaccessible. (4053892) | Reinstall or reconfigure the control plane on the worker node. See OpenShift documentation. |
| After creating PVC in RWX mode, data written on an application pod running on one node is not accessible from an application pod scheduled on another node. (4046460) | See https://access.redhat.com/solutions/6153272 for the recommended solution. |
In container form factor if public/private NICs to be used for LLT are bonded and the underlying bonded NICs have been configured on the same switch,then the worker nodes on which InfoScale is configured might panic randomly with a message - kernel BUG at mm/slub.c:305! . (4048786) |
If NIC bonding is required for the LLT links, ensure that the underlying NICs are configured on different switches to avoid the kernel node panic, even though the crash has no functional impact. If private links are connected to the same switch, the bond mode must be Active-Backup |
Disks from a node of the InfoScale cluster do not get added to the disk group - vrts_kube_dg . The following error message V-5-1-18986 sal_map_devices: da_online failed with error 142 for SAL disk is logged in syslog on the master node. On running kubectl describe infoscalecluster -n infoscale-vtas , Output indicates disk addition failure. (4055278) |
Add these disks to the disk group manually from the InfoScale SDS pod. |
| During InfoScale deployment, InfoScale configuration is not complete on one of the nodes and the node remains in a 'Not ready' state (4047598) | Remove cr.yaml and deploy InfoScale again by using cr.yaml . |
| If InfoScale is undeployed on all nodes while retaining the disk groups, re-creating InfoScale cluster on some nodes and adding nodes to the cluster fails. (4047205) | Undeploy and re-create InfoScale cluster on identical number of nodes. To undeploy InfoScale on all nodes and re-create InfoScale clusters on some nodes, contact InfoScale support. |
| After restoring space-optimized snapshot to new PVC, mount on restored PVC may fail if the source snapshot volume is detached (4012858) | Try one of the following -
|
| CSI controller pod remains in 'Terminating' state in case of graceful node shutdown or power-off (4011482) | Try one of the following -
|
| CSI node pods does not get rescheduled on other worker nodes when its parent node is drained (4011384) | None |
| While restoring a snapshot, PVC goes into pending state after rebooting all nodes except the master node in the cluster (4014525, 4048825) | Delete the snapshot volume by using the vxedit command. Kubernetes automatically reattempts to create a volume snapshot again. |
| In case of storage failure, application IOs to the mountpoint inside container fails and pod goes into CreateContainerConfigError or Error state (4011219, 4014758, 4015259) | Manually restart the application pod after the storage failure is resolved. |
| Current application on the primary must not be deleted until it is clear that DR is possible. In some cases, DR fails and application gets deleted on the primary.(4047475) | Ensure that the peer clusters are connected and Data Replication is in a healthy state. |
| If all worker nodes go down at the same time, InfoScale availability configuration is lost (4050355) | After recovery, InfoScale configuration is re-created. It might take up to 20 minutes. |
| If applications on a cluster with Load Balancer configuration are migrated, Load balancer service appears in 'Pending' state if the target cluster's Load balancer IP addresses are different. (4051429) | If you are using Load Balancer service, use DNS custom resources to manage DNS endpoint mapping. |
| Delete datarep operation goes in an unresponsive state and force delete in CR fails. (4050857) Delete datarep operation fails if secondary site is not available. (VIKE-3885) | Complete the following steps to clean up:
|
In case DR migrate fails to complete and running the command kubectl describe datareplication.infoscale.veritas.com/ returns a message vradmin migrate command failed . (4053632) |
Complete the following steps:
|
| Kube-fencing is not functional when REST service and InfoScale operator pod is not running. (4054545) | None |
In VVR environment, vradmin migrate might fail with the following error message VxVM VVR vxrvg ERROR V-5-1-1617 giving up: utility fields must be cleared by executing: vxedit -f set tutil0="" <rvg> (4057713) |
Run the following command - vxedit -f set tutil0="" to clear tutil on the RVG and retry the 'vradmin migrate' operation. |
During cluster configuration or while adding new nodes on OpenShift or Kubernetes, node join might fail if the disks in the cluster have old disk group records from previous deployments. Output similar to the following indicates old disk group records. vxvm:vxconfigd[238047]: V-5-1-11092cleanup_client: (Disk in use by another cluster) 223esxd05vm06 kernel: VxVM vxio V-5-0-164 Failed to join cluster infoscale_22670, aborting : (4057178) |
Reset the cluster ID on the disks of joiner node, in order to allow the node to join.
|
| Stale InfoScale kernel modules might be left over after undeploying InfoScale cluster on OpenShift or Kubernetes.(4042642) | Before deploying InfoScale on OpenShift or Kubernetes, check if any stale InfoScale kernel modules ( vxio/vxdmp/veki/vxspec/vxfs/odm/glm/gms ) are loaded. If stale modules from old deployments are still loaded, reboot all worker nodes and then proceed with the InfoScale deployment. |
| LLT tools is unable to detect duplicate InfoScale cluster id on OpenShift.(4057800) | Re-deploy InfoScale CR to avoid duplicate cluster id match. |
| RLINK detach is observed while replication autosync is in progress between the primary and secondary clusters. (VIKE-1290) | Run kubectl describe datarep datareplicationName to check datareplication status. If ReplicationStatus is stopped, Edit datareplication and set attributes force: true and replicationState: stop in remoteClusterDetails. Again, edit datareplication and set attributes force: false and replicationState: start in remoteClusterDetails. |
| On a Kubernetes cluster, tcp traffic reaches the node but does not get forwarded to the pod. (VIKE-1108) | Disable tx and rx offload on all nodes for calico tunnel device. |
| Migration or takeover fails if the namespace being backed up pre-exists on the target cluster with different SCC (Security context constraints)- related annotations like uid-range, supplemental-groups, and seLinuxOptions.(VIKE-1277) | User should delete the namespace in the target cluster. Make sure to mark the PV as Retain to not accidentally delete the underlying volumes. |
| Takeover operation fails if it is initiated when 'Disaster Recovery plan' is configured before 'Data replication configuration' is complete on the primary cluster. (VIKE-1294) | Wait for the following error in Disaster Recovery Plan CR status to go away before attempting takeover - metadataSyncStatus: Metadata backup transfer failed for all peer clusters or Wait for data replication CR status to be consistent up-to-date before applying Disaster Recovery plan CR as mentioned in 'Configuring Data Replication'. |
| If multiple Data Replication plans for Disaster Recovery are created in parallel, the initial VVR synchronization is slow due to the locking that needs to be acquired in VVR for each of the Data Replication plan. (VIKE-1505) | To create multiple Data Replication plans, create the subsequent plans after the current Data Replication plan's initial synchronization is complete and status is consistent-up-to-date. |
| When UEFI secure boot is enabled, only the signed kernel modules that are authenticated by using a key on the system key ring can be successfully loaded. Hence InfoScale kernel modules might fail to load with UEFI secure boot. (VIKE-1578) | Disable UEFI secure boot. See the relevant documentation for details. |
In the following conditions, addition of disks to a disk group in an already configured InfoScale cluster fails with the error message VxVM vxdg ERROR V-5-1-559 Disk node000_vmdk0_1: Name is already used
|
None |
| If thin-provisioned LUNs are configured, a mismatch in the total size and free size of the Disk Group might be observed. (VIKE-2497) | None |
| After DR takeover is completed and the old primary is up, VVR failback synchronization of the data is initiated from the new primary site to the new secondary site. This data synchronization might be slow or the system might be unresponsive resulting in the VVR failback to be incomplete. (VIKE-2634) | 1. Pause all data replications on the primary site by setting the replicationState to pause in the data replication custom resources. Perform a sequential VVR failback synchronization operation then by setting the replicationState to resume on only one of the data replication custom resources, that is the active data replication. 2. After the VVR failback synchronization is complete on the only active data replication, resume VVR failback synchronization on the next paused data replication. Complete VVR failback synchronization on all the configured data replications. |
| Sometimes after a cluster fault, InfoScale nodes join the cluster back, infoscale-sds pods go in running state but the InfoScale disk group remains in a deported state.(VIKE-2666) | Login to any of the InfoScale-sds pods.
|
| After InfoScale is deployed, cluster phase does not get updated and state is 'Degraded', even when it is Healthy. (VIKE-2586) | Restart InfoScale operator by deleting the pod. |
| If stale Volumes are present on the system, undeploying InfoScale is unresponsive with SDS pods in a terminating state (VIKE-2635) | Reboot all worker nodes. You can reboot sequentially, if applications in the cluster might be impacted due to a simultaneous reboot of all nodes. |
Sometimes a primary cluster fault event might occur after a PVC resize operation on the primary cluster, followed by a takeover operation carried out from secondary cluster. In that case, when the old primary joins back the cluster membership, some Volumes on the old primary are in a NEEDSYNC state. The NEEDSYNC state is indicated by running vxprint on the old primary infoscale-sds pod. (VIKE-2917) |
Run vxrecover -s from an infoscale-sds pod. The state changes to Active . |
| During upgrade, sometimes InfoScale sds pod remains in a terminating state. (VIKE-3003) | Reboot the node where the pod is stuck in a terminating state. |
Error observed in Persistent Volume Claim addition in an application namespace if one of the worker nodes is down with the following error message in data replication status.VxVM vxassist ERROR V-5-1-2127 Plex srl_4x0g2eewpu3b6m30ay71-02 should be enabled (VIKE-4193) |
Data replication status returns to normal state after the worker node restarts. |
When all the worker nodes are down, kubectl / oc get shows the incorrect InfoScale cluster status.(VIKE-4149) |
Whenever any worker pod is 'Ready', InfoScale status is updated. |
When an old primary cluster rejoins after a takeover operation, Volume number mismatch data replication config error is observed as under - Output of kubectl/oc describe datarep <datarep name>Replication Config Errors:<IP address>: volume-number mismatch, Primary-Primary configuration (VIKE-4151) |
Run the following steps:
|
| Data replication is stuck in an inconsistent state while logging to DCM (VIKE-4369) | Run kubectl/oc get datarep -o wide . If the output indicates inconsistent \| logging to DCM (needs dcm resynchronization) for a data replication plan, edit the corresponding datarep cr to stop replication. Wait for the replication to stop. Restart replication by editing the same datarep cr. The repstatus subsequently is replicating (connected) . |
| While adding or removing disks to Storage Arrays without AVID support, applications might not come up after a node reboot. (VIKE-4139) | Contact InfoScale support. |
| After a node reboot, the toolset pod does not come online if the Volumes are in a 'Sync' state. (VIKE-4434) | Run the following command to change the state of the Volume from 'Sync' to 'Active '. vxvol -g <disk group name> -f resync <name of the Volume> |
| In a DR setup after a node reboot, if the InfoScale SDS pod on that node is not in a 'Ready' state and the cluster CR status is 'Degraded' on either primary or secondary, applications running on that node might face issues in performing IO operations. (VIKE-4428) | Reboot that node again and check the IO operations. If IO operations issues persist, reboot all nodes in the cluster together. |
PVC creation on a cluster with cri-o container engine fails with the following error message - VxVM vxassist ERROR V-5-1-1401 Your license does not include support for mirroring. Cannot create volume with requested attributes (VIKE-4367) |
Run crictl images on the worker nodes of the cluster to verify if InfoScale images are present. If NOT present, see https://access.redhat.com/solutions/5350721 without the 'node reboot' section for the resolution. |
| If cluster nodes reboot or get powered off in a cascaded manner, application pods might not failover to a running node. (VIKE-4375) | This issue might be due to Storage connectivity. If Storage is connected and this issue is observed - 1. Identify the node where application pod is scheduled after failover.2. Login to InfoScale SDS pod running on that node and run vxprint -uH \| grep LDISABLED to identify the Volume which has a LDISABLED attribute.3. Run vxvol -g -f enable to remove that attribute. |
| Deleting application pod operation may get stuck, when the file system provisioned through Persistent Volume Claims (PVC) consumed by the application pod is in a disabled state. (VIKE-4514) | Login to the node where the application pod is scheduled and manually unmount all the mount points that has file system disabled. |
| While upgrading InfoScale Stack from 8.0.300 to 8.0.310, the SDS driver pod is stuck or does not boot for longer duration than expected. (VIKE-4523) | Check cluster start logs using the below command: oc -n infoscale-vtas exec -it infoscale-sds-62453-a8d04dbf0095f7bc-wmgtx -- tail -f /var/VRTSvss/vss.logIf you see error messages or abnormal number of re-attempts for starting cluster, then reboot the corresponding worker node where SDS pods resides. |
| While upgrading OCP/orchestrator platform, the process may not progress and there is a mismatch between the version of worker node operating system and that of the selector. (VIKE-4522) | Ensure that the NFD label sync on the nodes is complete. Restart the InfoScale Operator pod. |
Application pod is stuck in init/ContainerCreating state. Check error in CSI node log of the node where the application pod is scheduled using the command: oc logs -n infoscale-vtas -c infoscale-csi.Following error is displayed."Run: Error occurred while calling method" method=/csi.v1.Node/NodePublishVolume error="rpc error: code = Internal desc = Error occurred node staging is not done"" (VIKE 4532) |
Delete the application pod. When the new pod is scheduled, it calls NodeStage and NodePublish. |
| The diskinfo field is missing from the InfoScaleCluster status. (VIKE-5119) | To obtain the disk group details, including diskinfo, use infoscale-storage-usage.yaml as specified in the "Using InfoScale toolset" section. See Using InfoScale toolset . |
| OLM certificate is expired. (VIKE-5415) | If you come across any instances of expired OLM certificates, restart the InfoScale operator. |
| InfoScale workloads on OpenShift can fail to read/write to shared RWX volumes because OpenShift assigns unique SELinux MCS labels to each pod. When replicas mount the same volume with different labels, SELinux denies access. This issue is well-documented in Red Hat and IBM storage guidance, where mismatched SELinux contexts are a common cause of RWX mount failures. (VIKE-5347) | Set a fixed SELinux label in the pod or container securityContext.seLinuxOptions so all replicas use the same SELinux context. This prevents MCS mismatches and restores proper RWX access.securityContext:seLinuxOptions:level: "s0:c447,c946" Refer to:SELinux optionsSecurity context constraintsAssign SELinux labels to a ContainerConsiderations for mounting read-write many (RWX) volumes |
| Clone volumes in the DiskGroup require serialized splitting before DataRep can move forward. This process depends on storage performance and may take several minutes. Allow the included script to complete the split operations before applying DataRep. (VIKE-5455) | This script performs continuous background monitoring of the DG and triggers clone splitting when sync is complete.
|
| When upgrading from InfoScale 8.0.400 to 9.1.2, the preflight check may fail if it detects volumes in a DETACHED state. | In the SDS container pod, check if any volume is in a DETACHED state by running: vxprint -ht \| grep -i detach. If a volume is detached, manually start it using the following command: vxvol -g <diskgroup_name> start <vol_name> |
| When using RDM, disks that are in an "online" state at the IKE cluster level automatically inherit the host ID. When these same disks are mapped inside guest virtual machines, InfoScale detects them as being in use by the host.Consequently, attempts to initialize a new disk group (vxdg init) or unsetup the disks (vxdiskunsetup) from within the guest fail with "Disk is in use by another host" or "Disk is tagged as imported" errors. | Use vxdiskunsetup with -f option and then retry Diskgroup creation.Example:# /etc/vx/bin/vxdiskunsetup -Cf emc1_0496 |
| After rebooting the OCP host on which an RDM-backed VM is running, the host rejoins the cluster and the underlying VxVM volumes come back online, but the VM stays Stopped (READY False) and is not auto-restarted.OCP-V / KubeVirt platform behavior. VMs with RDM passthrough disks are non-migratable (disks are lun + shareable + reservation: true), so KubeVirt does not reschedule or auto-restart them when their host goes down and comes back. The VM's storage is healthy after host recovery, but the VM lifecycle is not driven back to Running by the platform. (VIKE-5943) | VMs with RDM disks must be manually started after a host reboot. Plan for this in operational procedures; do not rely on automatic VM recovery for RDM-backed VMs. |
| RDM disks are exposed as static PVs linked to DMP devices. Not all CSI operations are supported on such PVs — resize, snapshot, and clone of these resources are prohibited at the CSI layer. Since KubeVirt VirtualMachineSnapshot and VM clone are built on top of CSI snapshot/restore, VM-level snapshot and clone are therefore not applicable to any VM that has RDM disks. (VIKE-5948) | VM snapshot and VM clone are not supported for VMs with RDM passthrough disks. Use storage-array snapshots or in-guest tools for backup/clone of the underlying LUNs. |
KubeVirt limitation, three compounding causes (upstream status verified 2026-06-08):
|
Add all shared SCSI-3 PR LUNs to the VM spec before first boot. To add post-boot: stop VM → patch → start. As of 2026-06-08, no KubeVirt fix exists for declarative hotplug of SCSI-3 PR disks; the tracking issue (kubevirt#13075) is closed without resolution. |
| Co-located VMs (same physical host) cannot use SCSI-3 PR reservations against each other — same behavior as VMware. Disk-based fencing therefore fails for same-host cluster members. (VIKE-5967) | VMs in the same cluster using disk-based fencing must run on different OCP hosts (enforce via anti-affinity). Co-located VMs must not rely on SCSI reservation. |
| During RDM attachment, the CSI driver performed a cluster-wide safety check to verify that the resolved DMP device was not already in use by a VIKE-managed disk group. On clusters with a large number of disks, this check generated a heavy volume of REST and vxdisk calls, overloading the REST server and exceeding the kubelet attach deadline, which caused bulk attachments to fail. (VIKE-5970) | The per-attach cluster-wide validation has been removed to ensure RDM attachments complete within the kubelet deadline.Important: You must manually ensure that disks being attached as RDM to a VM are not part of any active VIKE cluster disk group or fencing disk group (e.g., vrts_kube_dg-* or vrts_coord_dg-*). Attaching a disk already consumed by VIKE can corrupt the cluster state, as the CSI driver no longer prevents this combination. |
| When an InfoScale license expires and is subsequently renewed, the licensing operator processes the new license and the core stack services (cvm, RestSG) come online successfully. However, the DISK_GROUP service group fails to transition to ONLINE state because the underlying disk group remains in a deported (not imported) state at the VxVM layer.The VCS OnlineRetryLimit = 5 is exhausted because each online attempt fails — VCS cannot bring the DISK_GROUP resource online when the disk group itself is not imported. There is no existing mechanism to detect the deported disk group condition and trigger a manual import or force-online as a corrective action. This results in a cascading failure: without the disk group, the CSI controller cannot mount volumes (enters CrashLoopBackOff), and the DR manager cannot initialize (stuck in PodInitializing). (VIKE-6006) | Manually perform the following steps on one of the worker nodes:Clear any faulted state on the DISK_GROUP service group:hagrp -clear DISK_GROUP -sys <system_name>Repeat for each node, or use:hagrp -clear DISK_GROUP -anyForce-online the DISK_GROUP service group:hagrp -online -force DISK_GROUP -anyIf the disk group is still not imported (disks still show parenthesized group name in vxdisk list), manually import it:vxdg -s import vrts_kube_dg-<clusterid> Then retry the service group online:hagrp -online DISK_GROUP -anyVerify recovery:vxdg list # DG should show as 'enabled'hastatus -sum # DISK_GROUP should be ONLINE on all nodesoc get po -n infoscale-vtas # CSI controller and DR |
| Initiating SDS pod deletion as part of the license renewal recovery workflow results in pods becoming permanently stuck in 'Terminating' state. (VIKE-5929) | Reboot the nodes running the SDS pods. As they come back online, VCS starts automatically and volumes re-enable — no further manual intervention required.(This is already part of recovery process). |
Sometimes the VVR replication status is consistent, up-to-date from the InfoScale/VVR core side, but the DataReplication CR status at the OpenShift level shows a stale/outdated state when checked via: oc describe datareplication <datarep> -n <namespace>The CR does not automatically reflect the current VVR replication state until reconciliation is triggered. (VIKE-6272) |
Patch refreshStatus to true to force the DataReplication CR to reconcile and refresh its status from the VVR layer:oc patch datareplication <datarep> -n <namespace> --type=merge -p '{"spec":{"refreshStatus":true}}'Example:oc patch datareplication datareplication-virtualmachine-1 -n infoscale-vtas --type=merge -p '{"spec":{"refreshStatus":true}}'After patching, the DR operator reconciles the CR and the status reflects the actual replication state. |