Mount proxy node and data mover node requirements

Operations require specific node types and certain environment settings.

Consider these Data Protection for VMware node requirements before you attempt any tasks:
  • Data mover nodes are required for the following operations:
    • IFINCREMENTAL - indicates the incremental-forever incremental backup type.
    • IFFULL - indicates the incremental-forever full backup type.
  • Mount proxy nodes are required for the following operations:
    • Full VM instant access
    • Full VM instant restore
    • Mount
  • A mount operation accesses a Windows system and a Linux system that function as mount proxy systems. The Windows proxy system also requires the recovery agent to be installed. These two mount proxy nodes function together during a mount operation. Mount proxy nodes are created in pairs and are required by the datacenter node for each Windows or Linux system that serves as a proxy.
  • Only one mount proxy node is allowed for each physical or virtual Windows mount proxy system. If you want to use multiple mount proxy node pairs, you must install each Windows mount proxy node on a separate system, along with a recovery agent.
  • You cannot mount the backup of a Windows mount proxy node or Linux mount proxy node to itself.
  • The following requirements are specific to data movers and mount proxy systems if VMs are in a VVOL datastore:
    • For stability, the data mover and mount proxy should reside on a non-VVOL datastore.
    • For improved performance for file restore for Windows guest VMs, configure the Windows mount proxy system in the same datacenter and the same ESXi host as the guest VMs. This configuration takes advantage of the VMware virtual disk hot add capability.
    • Linux only: The credentials for the vCenter must be set on the mount proxy system by using the dsmc Set Password command.
    • Linux only: The VMCHOST option for the mount proxy must be specified in the dsm.sys options file.

The recovery agent is restricted to one node assignment. This node must be a mount proxy node. Although a Windows system might contain multiple data mover nodes, only one proxy mount node is allowed for the recovery agent to use. As a result, operations that use the recovery agent fail when you attempt to connect to a system with a node that is not assigned to the recovery agent.

These examples show types of operations that fail when a node that is not assigned to the recovery agent is used:
Mount operations
When you run a mount operation with the mount proxy node from VMware datacenter DC1, the recovery agent connects to that mount proxy node. Because that connection to the mount proxy node is the only correct connection, the recovery agent does not use another mount operation with any other nodes on that mount proxy system. As a result, the mount operation fails when you use a mount proxy node from VMware datacenter DC2.
Before you attempt a mount operation, you must disable multipathing on the Linux mount proxy system.
Note: Logical Volume Manager (LVM) filtering can block iSCSI connections.
Note: The Linux mount proxy system does not support LVM auto activation.
Instant access or instant restore operations
You attempt to run an instant access or instant restore operation with a mount proxy node from a Windows system that is used as a mount proxy system. A Windows mount proxy system requires the recovery agent to be installed. Because the connection from the recovery agent to the Windows mount proxy node (to run the mount operation) is the only correct connection, an instant access or instant restore operation that attempts to use this mount proxy node (from the same Windows system) fails.
Mount proxy nodes and data mover nodes require proxy authority to the datacenter node. This proxy authority is granted automatically when you set up your nodes with the Data Protection for VMware vSphere GUI Configuration Wizard. However, if you manually set up your mount proxy nodes and data mover nodes, you must grant this proxy authority to the datacenter nodes on the IBM Spectrum Protect™ server with the GRANT PROXYNODE command. For example:
GRANT PROXYNODE TARGET=DC_NODE AGENT=LOCAL_MP_WIN 
GRANT PROXYNODE TARGET=DC_NODE AGENT=LOCAL_MP_LNX

File sharing security

When you share a mounted virtual machine snapshot, certain security issues can occur that are related to NFS (Linux) and CIFS (Windows) protocols. Review these issues to better understand the security impact when you share a mounted virtual machine snapshot.

When all of the following conditions exist on Linux systems, respective users can access directories on the shared system:
  • The mounted volumes that belong to Linux system (B) are shared to a different Linux host (A).
  • The Linux host (A) has the same user names as the Linux system (B) that was backed up
For example, root user (A) can access all root user (B) files, and tester (A) can access all of tester (B) files. In this situation, the permission group and user are changed to nobody.
This output is an example of access to mounted volumes:
esx2vm55:/opt/tivoli/tsm/client/ba/bin # ls -la /CVT/TSM/ESX2VM21/2014-05-22-01_32_53/Volume7

total 19
drwx------   4   500   500   1024   Apr 28 23:53 .
drwxr-xr-x   8   root  root  4096   May 27 22:06 ..
drwxrwxr-x   2   500   500   1024   Apr 28 23:52 RAID_0
drwx------   2   root  root 12288   Apr 28 23:52 lost+found
This output is an example of access to shared volumes:
[tester1@ESX2VM51 Volume7]$ ls -la

total 19
drwx------   4   nobody nobody  1024   Apr 28 23:53 .
drwxr-xr-x   8   nobody nobody  4096   May 27 22:06 ..
drwxrwxr-x   2   nobody nobody  1024   Apr 28 23:52 RAID_0
drwx------   2   nobody nobody  12288  Apr 28 23:52 lost+found

Make sure that the correct Linux hostname/IP address or Windows user name is specified. If the correct hostname/IP address or user name is not specified, the share operation fails. This failure is identified by the operating system.

On Windows systems, a user with the same credentials as the backed up Windows virtual machine can access the shared volumes on any Windows system.