> Expert > Backup and Restore Agents > Virtualization > Virtual Server Agent > VMware > Transport Modes

HotAdd Transport for VMware

The term HotAdd refers to the way the backups are completed. In HotAdd mode, virtual disks from the virtual machines being backed up are automatically mounted to the proxy, so they can be accessed by the proxy as local disks. The ESX host the proxy is running on must have access to all datastores for the virtual machine. If the virtual machine and the proxy are not on the same host, all datastores must be shared between the hosts and the hosts must be within the same datacenter.

If SAN mode is not available, HotAdd mode can achieve close to SAN mode performance.

To enable incremental backups of virtual disks, Changed Block Tracking (CBT) must be used for the first full backup. (CBT is enabled for backups by default.)

Licensing

In vSphere 5.0, the SCSI HotAdd feature is enabled only for vSphere editions Enterprise and higher, which have Hot Add licensing enabled. No separate Hot Add license is available for purchase as an add-on. In vSphere 4.1, HotAdd was also enabled in the Advanced edition. Customers with vSphere Essentials or Standard editions cannot perform proxy-based backups, which rely on SCSI HotAdd. Those customers must use alternate transport modes.

HotAdd Scenarios

Backup of NFS Datastores

You can perform backups even when VMware datastores are configured on NFS volumes. The Virtual Server Agent and MediaAgent are configured on a virtual machine. During backup, the VSA mounts the VMDKs of the source VMs to itself, using a process called HotAdd. The source VMDKs then appear as a local disk to the VSA. The VSA module reads the VMDK locally, performs deduplication, and sends the data to the MediaAgent module on the same VM to be written to the disk library.

While not as efficient as SAN mode, this configuration ensures that no data is transferred over the IP network during backup. VM restores are also performed locally.

For information about sizing, see VSA Hardware Requirements.

HotAdd Installations - Virtualized Agent and Virtualized MediaAgent

In this configuration, the Virtual Server Agent and MediaAgent are both installed in HotAdd mode. The backup destination is typically network based (CIFS/NFS) or another VMFS datastore and tape out options are very limited. Shared storage is required for HotAdd backups of virtual machines living on other ESX hosts.

When To Use

  • All virtual environment where physical servers are not preferred.
  • Datastores are configured on NFS.
  • Each MediaAgent can write directly to a mount point presented to the virtual machine.
  • Able to segregate backup and production traffic on the network.

When Not To Use

  • Direct backup to tape is required.
  • Backup traffic cannot be segregated from production traffic.

HotAdd Installations - Virtualized Agent and Physical MediaAgent

In this configuration, the Virtual Server Agent is installed in HotAdd mode and the MediaAgent is installed on a physical computer. Data is transferred over the LAN to the physical MediaAgent. This model also allows for the use of a centralized Windows MediaAgent and Linux MediaAgents. Shared storage is required for HotAdd mode backups of virtual machines living on other ESX hosts.

When To Use

  • Direct backup to tape or SILO to cloud is required.
  • Segregation of backup and production data is possible.
  • Physical MediaAgent is required for other protection tasks and secondary operations.
  • Network speed between ESXi hosts and the MediaAgent is limited, and the primary storage policy copy uses deduplication.

When Not To Use

  • Segregation of backup and production data is not possible.
  • If SAN-based datastores on Fiber Channel or iSCSI are used, and the same storage is accessible from a physical VSA proxy, then use SAN mode configuration instead of HotAdd.

SCSI Controllers and Device Nodes

HotAdd relies on the SCSI protocol:

  • With VDDK 6.5 or later, ensure that you use the paravirtual SCSI (PVSCSI) controller. For more information, see Virtual Disk Development Kit Release Notes.

  • For older VDDK versions, use the LSI Login SAS type of SCSI controller.

  • HotAdd does not support IDE disks.

A single SCSI controller can have up to 15 disks attached, with at least one SCSI device node reservation for the virtual machine OS. If you run concurrent backup jobs that include more than 15 disks, you might need to add SCSI controllers to the VSA proxy that is responsible for hot adding disks. Having insufficient SCSI device nodes can cause delays for backup or backup copy operations and create a backlog of snapshots.

If the backup operation for a disk cannot reserve a SCSI device node, one of the following events occurs:

  • If the transport mode is specified as HotAdd, the backup job fails.
  • If the transport mode is specified as Auto, the backup job switches to NBD mode for the remaining disks.

To ensure that enough SCSI device nodes are available, the best option is to load balance backups across multiple VSA proxies.

SCSI Port Number Sequence

VMware uses SCSI ports in sequence, but sorts digit by digit rather than by the total port number, port numbers might be assigned incorrectly in the VMX file for a VMware VM that has the Virtual Server Agent installed (a VSA proxy). For example:

scsi0.pciSlotNumber = "160" 
scsi1.pciSlotNumber = "224" 
scsi2.pciSlotNumber = "256"
scsi3.pciSlotNumber = "1184"

In this example, VMware would use port 1184 before 224, causing backups to fail.

To resolve this issue, change the port assignments in the VMX file for the VSA proxy, as shown in the following example:

scsi0.pciSlotNumber = "160" 
scsi1.pciSlotNumber = "1184"
scsi2.pciSlotNumber = "224" 
scsi3.pciSlotNumber = "256"

Note

When a VSA proxy has 4 SCSI adapters, you must reorder the port assignments to 0-160, 1-1184, 2-224, and 3-256.

Testing HotAdd

You can use the following process to test HotAdd attachments for a VM:

  1. Create a snapshot on the VM that you planning to back up.
  2. Attach the base disk from that VM to the VSA proxy as an independent or non-persistent disk.
  3. If the attach is successful, the VSA proxy will be able to perform a HotAdd operation.
  4. Detach the disk from the VSA proxy.
  5. Remove the snapshot for the VM.

Best Practices for HotAdd

  • Helper virtual machines are not required for HotAdd proxies using VADP.
  • If VSA proxies are included as subclient content, backups of the proxies use NBD transport mode instead of HotAdd mode.

As a best practice, use separate subclients to protect VSA proxies, and schedule backups at a different time than other backups, so that the proxies are available when they need to be used to perform backups for other VMs. - When deploying the Virtual Server Agent for HotAdd backups, choose the datastore with the largest VMFS block size to ensure backups can mount and back up virtual machines residing on all datastores. For VMFS-3, a proxy that needs to back up and restore very large virtual disks should be deployed on volumes that support a large block size, with the block size of the proxy datastore matching the block size of the datastore for the disk being backed up. VMFS-5 uses a consistent file block size and can handle volumes up to about 60TB. - On the server hosting the Virtual Server Agent, ensure that automount has been disabled to disable automatic drive letter assignment:

diskpart> automount disable
- Scrub automount settings to ensure that previous drive letter assignments and other volume mount settings are cleared:

diskpart> automount scrub
- When HotAdd disks are backed up, a snapshot and redo log are created. While the HotAdd disk is still attached, do not remove the snapshot or the virtual machine being backed up. If the VM is removed while the disk is still attached, clean up of redo logs fails, and you must remove virtual disks from the backup appliance manually. If the snapshot is removed, the redo log could be left in an unconsolidated state. - Virtual Windows disks created by HotAdd backup or restore operations might have different disk signatures than the original virtual disks.

Loading...