Article number
Affected Versions
Source Hypervisor
Target Hypervisor

Problem with After a Reboot of a VRA VM, the VRA Fails to Start Login Service

Viewed 428 times


An administrator may notice a VRA, post-reboot, does not fully come back up leading to many GUI alerts.

Root Cause

Each VRA has a crontab that backs up the passwords, shadows and group files (/etc/passwd, /etc/shadow and /etc/group) to the location /mnt/log/persistence. Upon every boot the BootProcess script checks if these password, shadow and group files are similar to the files in persistence directory, and if they are not, the script restores them.

In some cases the copy files command will copy files but not their contents. In this scenario it caused the BootProcess script to remove all users/groups and the password files from the system resulting in the inability to properly boot up the kernel.


  • From the ZVM GUI there are ZVM to VRA disconnection alerts as well and VRA to VRA disconnection alerts.

  • Due to the disconnected VRA, any VPGs associated with this VRA will experience increasing RPO and will eventually error out.

  • Attempts to SSH to the VRA VM fail, however, ping may still work.

  • From vSphere, the VRA VM console will show the following FAILED errors, specifically "Failed to start Login Service".

VRA no  login Prompte


To workaround this issue, follow the steps below:

  1. Migrate workloads off the host of the affected VRA.

  2. Uninstall and reinstall the VRA.

  3. If migration of VPGs off of the VRA is failing, export VPG settings, delete associated VPG(s) of the affected VRA, reinstall the VRA, and reimport VPGs.

This issue was permanently fixed in Zerto 7.0 Update 3. Upgrading to this code version or higher will avoid further impact.

Note: This issue can reoccur after performing the workaround until an upgrade to 7.0u3 or later can be performed.