Agent‑less PN Enrollment Limitations

•	Whether you use agent‑less or agent‑based enrollment, onQ can perform three PN backups simultaneously. However, with agent‑less enrollment, your agent‑less PNs must reside on different ESX/ESXi hosts.

•	Clustering, as outlined below, is supported for agent‑less PNs; however, a shared network and shared IP is not supported.

•	Due to a VMware limitation, dynamic disks are not supported. Do not attempt to protect them. If you protect them, the volumes and mount points based on the dynamic disks will not be available in the RN. Also, you will not be able to use QUARK to restore the dynamic disks.

•	For agent‑less PNs, FLR is supported; however, there are limitations. Go to File‑level Restore Limitations.

•

VMware does not support snapshots of raw disks, RDM physical mode disks, or guest operating systems that use an iSCSI initiator in the guest. As outlined above, snapshots for dynamic disks and logical drives are not supported. Therefore, Quorum protection for agent‑less PNs supports cluster nodes and local drives so long as they are primary partitions on basic disks. If the RN of such a cluster node is brought up in production mode, then the RN will connect to a production SAN as configurations from the PN will be replicated and are available on the RN.

•	CIFS volumes are not supported. When a NAS share is mounted on a PN, the security credentials are accessible for applications running in the PN. However, in the case of a PN proxy, those security credentials aren't accessible.

•	A virtual machine hosted on ESXi servers that are managed by vMotion can be enrolled as agent‑less PNs and protected by onQ; however, if you then migrate that virtual machine to a different host using vMotion, onQ is unable to back up that virtual machine.

•	Using the onQ Filter Driver, as described in (Agent‑based PNs) Methods of Performing Incremental Backups, to back up agent‑less PNs is not supported.

•

If a PN on the HA has custom (RN) networks defined and the DR has the default network defined, the RN on that DR might be configured with the custom networking information instead of the default networking information. The workaround is to create an xvf.dat file, then save it to C:\Program Files\Quorum\usr on the HA’s PN. As in the example below, edit the file to include the PN’s networking information. In the following example, 10.20.16.144 is the default IP of the PN enrolled on the HA, 255.255.248.0 is the default subnet mask, and 10.20.16.1 is the default gateway. Afterward, rebuild the RN. The PN on the HA continues to show the custom networks while the RN on the DR indicates what you specified in the xvf.dat file.

@@XV_PN_IP 10.20.16.144 @@XV_PN_MASK 255.255.248.0 @@XV_PN_GW 10.20.16.1

v3.8 SP1 HF1