Implementing EnsureDR with NetApp 9.x and VMware in On-Premise Environments
After the job has started, the Failover step is marked as 'bad' in the report. In the support log, we can find an error message similar to the following example:
“The operation for the entity "vm" failed with the following message: "Unable to DATE & TIME - write VMX file: /vmfs/volumes/ID/VM/VM.vmx.". Unable to write VMX file: DATE & TIME - /vmfs/volumes/ID/VM/VM.vmx. Insufficient permission to access the file …”
When you access the vCenter Console, you'll notice the NetApp volume is connected and the virtual machine is registered in the VMware Inventory. However, any attempt to manually start the virtual machine from the console will result in failure due to an error message indicating that the VMX file is locked.
We have identified two main reasons for the reported error:
- The export policy is set up incorrectly
- Native FPolicy is enabled in NetApp.
If the NetApp Export policy isn't configured correctly according to NetApp's prerequisites, VMware won't be able to start a virtual machine. Please ensure the NetApp Export policy includes all VMware ESXi hosts configured in the EnsureDR job, and select Read-Write access as permissions.
To verify the Read-Write permissions for the chosen VMware ESXi host as defined in the NetApp Export Policy, follow these steps:
1. Obtain the IP address of the VMware ESXi host.
2. Identify the NetApp volume following the format 'VolumeName_EnsureDR_Failover'.
3. Connect to the NetApp at the DR site using an SSH client.
4. Execute the NetApp command 'check-access' to confirm that the ESXi host (from step 1) has Read-Write permissions on the NetApp volume collected in step 2.
If the 'check-access' command does not confirm Read-Write access for the chosen VMware ESXi host, modify the EDR Export Policy to grant Read-Write access for the selected host.
In the event that Native FPolicy is enabled on the NetApp Storage, it might restrict access to the VMX file crucial for VMware's proper functioning. To address this issue, either disable Native FPolicy or configure it to allow VMware full Read-Write access to essential files within the VMware environment.