19.6 Troubleshooting Workload Failover or Failback

Problems or Messages

Solutions

Active Directory Domain Services are not available after a failback (Windows)

Active Directory Domain Services might not come up after a Failover, if chkdsk errors occur. Two avoidable causes of chkdsk errors are:

  • Log files related to Microsoft Updates if the source machine is not up-to-date with all Microsoft recommended patches or updates when you perform the first full replication.

  • System files and folders that should be excluded from your antivirus software.

To avoid these issues, follow these best practices described in Section 16.1, Prerequisites for Workload Protection before you run the first full replication.

During failback, the wrong NICs are mapped and failback hangs

Use one of the following workarounds to allow the failback to complete successfully:

  • Switch the IP configuration to the expected mappings so that the target is successfully configured.

  • Reboot the 'takecontrol' hardware to the LRD, then repeat the steps to use it as the failback target. There is a good chance that Forge will map to the correct Ethernet interfaces the next time.

  • In the Web Interface, if the failback seems to hang near the end of completion, the failback target likely cannot communicate with the PlateSpin Forge Server that the failback is complete. Switch the network cables in the back of the failback target to place the correct NIC on the intended networks. This enables the failback target to communicate with the PlateSpin Forge Server, and the failback completes.

X2P Failback of Linux Workloads Causes Failure of the X-Server Graphical Interface

The issue is caused by a reconfiguration of the failed-over VM when VMware tools are installed. To correct this, use the following command to find the files with the string BeforeVMwareToolsInstall in the filename:

find / -iname '*BeforeVMwareToolsInstall'

After you identify all such files, move them back to their original locations, then reboot the workload to fix the workload's X Server interface.

During failback to physical, the target Windows machine becomes unbootable

The networking tasks performed on the second boot for target Windows machines in failback to physical scenarios can be problematic in the following scenarios:

  • If the target machine has the same network adapter hardware and networking drivers as the failover VM.

    The network drivers that the target machine requires are the same as those already installed on the failover VM being failed back to physical. It is not necessary to re-install drivers. In some scenarios, removing and re-installing drivers can result in the target machine becoming unbootable.

  • If the target machine is booting from SAN.

    If a target machine boots from SAN, Forge installs drivers before the first boot. If the Configuration Service removes these newly installed drivers during the second reboot, the target machine becomes unbootable. It is necessary to avoid the driver install tasks on the second reboot.

For failback to physical scenarios to target Windows machines, Forge provides two light networking configuration settings for the PlateSpin Forge Server that optimizes the network configuration process on the target machine during the second boot and helps avoid situations that can cause a target Windows machine to become unbootable. See Section 7.4, Configuring Behavior for Installing Network Drivers on Target Physical Machines at Failback.