Skip to main content
Druva Documentation

DRaaS failover prerequisite checks

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

Overview

Are the VMs in your environment DR ready? Find out this and more as Phoenix automates this process for you with the Prerequisites checks capability. When the VMs are being backed up, the prerequisites checks kick into action and provide the status; if the VMs have successfully cleared the checks and are DR ready or not.
With these checks in place, you can prepare a robust DR strategy and avoid any surprises during failover. It further helps you reduce failed requests to the cloud, and your cloud spending too!

The status of the failover prerequisite checks is available through the Virtual Machines page. 

The following diagram illustrates the capability. 

Draas_Prereq_checks.png

Video_icon.png

Watch the video

► Expand for a feature overview video that provides more insights about the failover prerequisite check capability.

 

Requirements for enabling the prerequisites checks

To leverage the  prerequisite checks capability,  you must take the following actions:

Failover prerequisites check statuses

The following table describes the failover prerequisites check statuses

Status Description
Success Failover prerequisites check passed.
Not initiated Prerequisites check could not be initiated because either:
  • Backup proxy is not able to connect to the ESXi host on port 443. 
  • The first backup job after the VMware backup proxy upgrade is not completed.
  • The Phoenix backup proxy is on a version older than 4.8.11. See, Upgrade backup proxy in your environment.
  • The VM is not running. 
  • The VM does not have VMware Tools installed and running.
  • The failover prerequisites check binary execution has failed or timed out.
Invalid credentials

Prerequisites check could not be performed because either:

Missing credentials

Failover prerequisites checks could not be performed because credentials are not assigned to the VM. See, Configure virtual machines for backup

Error Failover prerequisites check failed. See, DRaaS failover prerequisite checks
Warning Prerequisites check passed with warnings. It is recommended to fix the warnings even though the failover won’t fail if not resolved immediately. 

Resolving DR failover prerequisite checks

After you resolve the checks, trigger a new back job and only after all the checks are successful, the VM is DR ready. 

Linux failover prerequisite checks

Check Description

Source Metadata Collection

What is verified

Verifies that all required metadata was collected from the source.

Potential errors

  1. Target OS customization error.

  2. Unable to identify partition using the parted command. 

Recommendation

  1. The is a generic Linux customization error.  Download the logs from the Job Details page.  
  2. Couldn't parse output of the parted command. On the source VM, run parted command.  If no output or incorrect output is generated, then fix the issue with parted and rerun backup.

    Sample output 

    (parted) print
    Model: VMware Virtual disk (scsi)
    Disk /dev/sda: 42.9GB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags:
    Number Start End Size Type File system Flags
    1 1049kB 30.9GB 30.9GB primary ext4 boot
    2 30.9GB 42.9GB 12.0GB primary linux-swap(v1)

Free Space

What is verified

Verifies there is enough free storage space.

Potential errors

The source does not have enough free space on {MPOINT} ({DEVICE}). At least {SIZE} Mb needed space is required․ 

Recommendation

Provision additional free disk space as described in the message. 

Bootloader

What is verified

Verifies the source boot loader is supported.

Potential errors

Source has an unsupported version of GRUB. Please install grub-legacy or grub2 on the source and try again․

Recommendation

Ensure that grub-legacy or grub2 is installed on the source virtual machine. Else, install the grub package on the source virtual machine.

Review the GRUB installation documentation for your operating system.  For example for CentOS refer to: https://wiki.centos.org/HowTos/GrubInstallation

OS Support

What is verified

Verifies the source operating system is supported.

Potential errors

  1. Migrations of 32bit Linux sources to AWS are not supported.
  2. This OS is not supported. Please review our documentation for supported OS for conversion․

Recommendation

Review the system requirements

Cloud-init Configuration

What is verified

Checks cloud-init configuration for potential problems.

Potential errors

  1. SSH pwauth is disabled in the cloud_init file. If you proceed, you might not be able to login to the target instance/VM․
  2. Lock password is enabled in the cloud_init file. If you proceed, you might not be able to login to the target instance/VM․

Recommendation

  1. Cloud-init is installed on the EC2 instance and it has configurations that have disabled SSH password authentication. Ensure that SSH password authentication is allowed. 
  2. Cloud-init is installed on the EC2 instance and it has configurations that can lock the account's password.  
Supported FS

What is verified

Verifies source filesystems are supported.

Potential errors

{DEVICE} has {FS_TYPE} filesystem, which is not supported.

Recommendation

One of the devices has an unsupported FS. Failover can continue if it is excluded. For failover, this means the file system might be missing from the target.  See, Configure virtual machines for backup.

Ensure that the disk to be excluded does not have following mountpoints : "/", "/usr", "/var" ,"/boot"

Selected Disks

What is verified

Verifies failover can proceed with only the selected disks.

Potential errors

  1. {MOUNT} is not one of the supported mounts.
  2. Mount {MOUNT_POINT} won't be available on the target as disk {DISK} was skipped.
  3. Mount {MOUNT_POINT} won't be available on the target as some of the PVs of the Volume Group is on skipped disks: {DISKS}.
  4. Disk {DISK} isn't used by any file system.

Recommendation

  1. An unknown/unsupported mount point was listed in selected_mounts. Make sure selected_mounts is a subset of supported_mounts returned from preflight.
  2. If the skipped volume is critical, add the skipped disk to selected_disks. Can be ignored otherwise. 
  3. If the skipped volume is critical, add the skipped disk to selected_disks. Can be ignored otherwise.
  4. Consider removing the disk from the backup and selected_disks.
LVM PVs

What is verified

Verifies LVM physical volumes are on supported storage devices.

Potential errors

Device {DEVICE} which is a PV for LVM Volume Group {VOLUME_GROUP} (mount: {MOUNT}) was not recognized as a supported device.

Recommendation

The block device which holds the volume was not recognized as a supported device. Failover can't continue if the volume is critical.

Note: Bind-mount is also not a supported device.

UEFI

What is verified

Verifies the source doesn't boot using UEFI.

Potential errors

UEFI boot is not supported.

Recommendation

AWS does not support UEFI boot. The failover will fail.

XEN/AWS Platform Details

What is verified

Checks if the type of XEN hypervisor can be detected (does nothing for non-XEN).

Potential errors

Could not determine if this xen-based source is an  AWS EC2 instance, as instance metadata could not be retrieved.

Recommendation

Couldn't reach the AWS metadata service to determine this is an AWS instance. The instance ID will be missing. 

Verify if network settings are correct on ec2-instance.  Verify if "http://169.254.169.254/latest/meta-data/" is reachable from the instance.

To verify, launch a temporary EC2 instance with the same configuration as the failover instance.

If the metadata URL is not reachable from the temporary EC2 instance as well, refer to the AWS documentation for more information.

DHCP Configuration

What is verified

Checks the source DHCP config for unsupported options.

Potential errors

DHCP configuration contains 'supersede'.  Target might have a broken network.

Recommendation

The EC2 instance has custom DHCP client configurations. Druva doesn't reset the configurations. This could potentially cause issues.  Verify the /etc/dhcp/dhclient.conf of the EC2 instance.
 

Required Mounts

What is verified

Verifies the required mount points were recognized.

Potential errors

/mountpoint is mandatory.

Recommendation

Ensure that the VMDK containing "/" mountpoint is not excluded from backup. 

Windows failover prerequisite checks

 

Check Description
UEFI

What is verified

Verifies the source doesn't boot using UEFI.

Potential errors

Windows UEFI source conversion to public cloud is not supported.

Recommendation

AWS does not support UEFI boot. The failover will fail.

Hyper-V

What is verified

Verifies the source is not a Hyper-V host.

Potential errors

The source is running hyper-v.  Migration of hyper-v servers is not supported by Druva. Hyper-V server will not be able to run in the target cloud and the source will fail to start in the target cloud environment.

Recommendation

Hyper-V is not supported. 

OS Support

What is verified

Verifies the source operating system is supported.

Potential errors

This OS is not supported for conversion. Please review our documentation for supported OS for conversion.

Recommendation

Review the system requirements

PV Drivers

What is verified

Verifies the source doesn't have 'AWS PV Network Device' NICs.

Potential errors

TCP offloading must be disabled on source with driver type {DRIVER}.

Recommendation

If phase 2 system has no network, disable TCP offloading on the source.

To disable TCP offloading

  1. In the Microsoft® Windows server, open the Control Panel.
  2. Select Network and Internet > Network and Sharing Center > Change Adapter Settings.
  3. Right-click on each of the private and public adapters, select Configure from the Networking menu, and click the Advanced tab. The window displays the TCP offload settings for the Citrix adapter. 
  4. Select each of the following TCP offload options, changing the value to Disabled, and click OK:
    • IPv4 Checksum Offload
    • Large Receive Offload
    • Large Send Offload
    • TCP Checksum Offload
Pending Updates

What is verified

Verifies there are no Windows Updates scheduled to happen on reboot.

Potential errors

Source has pending updates detected.

Recommendation

Windows updates are running on the source machine. A reboot is scheduled. The VM might reboot unexpectedly when booted into the final target OS. It might cause failover to fail.  Wait for the updates the complete. 

Network Drivers

What is verified

Verifies there are no incompatible NIC drivers installed.

Potential errors

Citrix PV Ethernet Adapter is not supported during AWS conversion.

Recommendation

The Citrix driver installed on the source might cause problems in phase 2. Uninstall the driver.

.Net

What is verified

Checks whether the required version of .Net Framework is installed.

Potential errors

Microsoft .NET Framework v{VERSION} will be installed.

Recommendation

This is an information message. It can be ignored.

Supported FS

What is verified

Verifies source file systems are supported.

Potential errors

The source has unsupported file systems '{FS_TYPE}' (volume {VOLUME_ID}, mount point {MOUNT_POINT}). Volumes with a non-supported file system can not be transferred.

Recommendation

One of the devices has an unsupported file system . Failover can continue if it is excluded.  See, Configure virtual machines for backup. Ensure that the disk to be excluded does not have following mountpoints : "C:"

Sysprep State

What is verified

Verifies previous Sysprep run wasn't incomplete.

Potential errors

Druva has discovered that a previous Sysprep attempt did not complete properly on the source VM.

In the registry navigate to ''HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\'' and locate the key ''BootExecute''. Remove the line containing ''sysprepDecryptor.exe'' and reboot the source VM before migrating.

Recommendation

In the registry navigate to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\ and locate the key BootExecute. Remove the line containing sysprepDecryptor.exe and reboot the source VM before migrating.

Is Domain Controller

What is verified

The source VM is a Domain Controller.

Potential errors

It appears that the source VM is a Domain Controller.

Recommendation

Domain controllers sometimes are slow to boot (might cause time outs) and are generally more prone to errors during failover.

Use larger instance-type like m4.xlarge family for running failover.

Free Space

What is verified

Verifies there is enough free storage space.

Potential errors

The source VM doesn't have sufficient space on C volume. Druva requires {TOTAL_SPACE_REQUIREMENT} MB free space on C volume.

Recommendation

Provision additional free disk space as described in the message. 

Antivirus Software

What is verified

Checks whether the source has AV/protection software installed.

Potential errors

{AV_NAME} antivirus software detected (service name: {SERVICE_NAME}). If failover fails, try whitelisting Druva software components.

Recommendation

Antivirus software blocks cli.exe or some other executable during failover. Try whitelisting the executables. 

Selected Disks

What is verified

Verifies failover can proceed with only the selected disks.

Potential errors

  1. Volume {MOUNT_POINT} won't be available on the target as disk {DISK} was skipped.
  2. Disk {DISK} isn't used by any file system.

Recommendation

Consider removing the disk from the backup and selected_disks.  See, Configure virtual machines for backup.

Ensure that the disk to be excluded does not have following mountpoints : "C:"

  • Was this article helpful?