Managing VPGs : VPG Statuses and Synchronization Triggers : VPG Statuses
  
VPG Statuses
The following statuses are displayed:
Status
Substatus
Comment
Deleting
Deleting the VPG
 
VPG waiting to be removed
Failing Over
Committing Failover
The VPG is being failed over.
Failing over – Before commit
A VPG being failed over is in the initial stage, before committing the failover.
Promoting
The failover has completed and the data from the journal is being promoted to the failed over virtual machine disk.
Rolling back Failover
The failover is being rolled back to prior to the failover.
History Not Meeting SLA
See Not Meeting SLA, below.
The VPG is meeting the RPO SLA setting but not the journal history.
None
 
Volume Initial Sync
After adding a virtual machine to an existing VPG not meeting the journal history SLA.
Initializing
Creating VPG
 
Full Syncing
Initial Sync
Syncing
Volume Initial Sync
Meeting SLA or Based on Alerts
 
Bitmap Syncing
Delta Syncing (When Force Sync is applied)
Recovery is Possible
After a rollback.
Rolling Back
 
User Paused Protection
Volume Initial Sync
After adding a virtual machine to an existing VPG meeting SLA.
Zerto Virtual Manager paused protection
 
Moving
Committing Move
 
Moving – Before commit
Promoting
Rolling back Move
Not Meeting SLA
Site Delta Sync (when Force Sync is not applied)
 
Delta Syncing a volume
Error
Journal/recovery disks are missing
Journal storage error
Needs configuration
Recovery storage error
Recovery storage profile error
Site disconnection
Site disconnection. No checkpoints
VM not protected
Volume Full Syncing
Volume Initial Sync
After adding a virtual machine to an existing VPG not meeting the SLA.
VPG has no VMs
 
Recovered
The VPG has been recovered.
RPO Not Meeting SLA
See Not Meeting SLA, above.
The VPG is meeting the journal history SLA setting but not the RPO.
None
 
Volume Initial Sync
After adding a virtual machine to an existing VPG not meeting the RPO SLA.
The following provides a full description of the sub-statuses:
Substatus
Description
Bitmap Syncing
A change tracking mechanism of the protected machines during a disconnected state or when a VRA buffer is full. In these situations, Zerto Virtual Replication starts to maintain a smart bitmap in memory, in which it tracks and records the storage areas that changed. Since the bitmap is kept in memory, Zerto Virtual Replication does not require any LUN or volume per VPG at the protected side.
Note: The VRA buffer is set via the Amount of VRA RAM value, specified when the VRA is installed
The bitmap is small and scales dynamically, containing references to the areas of the protected disk that have changed but not the actual I/O. The bitmap is stored locally on the VRA within the available resources. For example, when a VRA goes down and is then rebooted.
When required, Zerto Virtual Replication starts to maintain a smart bitmap in memory, to track and record storage areas that change. When the issue that caused the bitmap sync is resolved, the bitmap is used to check updates to the protected disks and send any updates to the recovery site. A bitmap sync occurs when any of the following conditions occur:
Synchronization after WAN failure or when the load over the WAN is too great for the WAN to handle, in which case the VPGs with the lower priorities will be the first to enter a bitmap sync.
When there is storage congestion at the recovery site, for example when the VRA at the recovery site cannot handle all the writes received from the protected site in a timely fashion.
When the VRA at the recovery site goes down and is then rebooted, for example during a Zerto Virtual Replication upgrade.
During the synchronization, new checkpoints are not added to the journal but recovery operations are still possible, assuming there are valid checkpoints in the journal. If a disaster occurs requiring a failover during a bitmap synchronization, the VPG status changes to Recovery Possible and you can recover to the last checkpoint written to the journal.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
Note: If the synchronization takes longer than the configured history, all the checkpoints in the journal can be lost, preventing a failover from being performed. For the resolution of this situation, see “To configure disaster recovery policies:”, on page 318.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc
Committing Failover
Failing over the VPG.
Committing Move
Completing the move, including removing the protected virtual machines.
Creating VPG
The VPG is being created based on the saved definition.
Deleting the VPG
Deleting the VPG.
Delta Syncing
The Delta Sync uses a checksum comparison to minimize the use of network resources. A Delta Sync is used when the protected virtual machine disks and the recovery disks should already be synchronized, except for a possible few changes to the protected disks, for example:
When a virtual machine was added to the VPG and the target recovery disk is defined as a preseeded disk.
After a source VRA upgrade of a major release: Depending on the nature of the upgrade, a VRA upgrade on the protected side may trigger either a Delta Sync or a Bitmap Sync. See the version release notes to determine if a sync will be triggered with a source VRA upgrade.
For reverse protection after a move or failover.
A Force Sync operation was manually initiated on the VPG.
A host protecting virtual machines was restarted and the protected virtual machines on the host had not been vMotioned to other hosts in the cluster or a protected virtual machine was vMotioned to another host without a VRA, and then vMotioned back to the original host.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal but recovery operations are still possible, assuming there are valid checkpoints in the journal. If a disaster occurs requiring a failover during a delta synchronization, you can recover to the last checkpoint written to the journal.
Note: It is not possible to perform a move during a delta sync.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
Delta syncing a volume
Synchronization when only delta changes for a volume needs synchronizing, for example, when a volume is added to a protected virtual machine in a VPG, and a preseeded disk is used.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal but recovery operations are still possible, assuming there are valid checkpoints in the journal. If a disaster occurs requiring a failover during a delta volume synchronization, you can recover to the last checkpoint written to the journal.
Note: It is not possible to perform a move during a delta sync.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
Error
Problem situation, for example, when a ZVM is disconnected from a VRA used to protect virtual machines. The VPG cannot be recovered until the problem is resolved,
Failing over - Before commit
Preparing and checking the VPG virtual machines in the recovery site.
Full Syncing
Full synchronization to ensure that the protected disks and recovery disks are the same after some change to the system. This type of sync is the same as an Initial Sync but occurs after protection started. In general, this type of sync should not happen.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
Note: During the synchronization, new checkpoints are not added to the journal. Also, recovery operations are not possible.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
Initial Sync
Synchronization performed after creating the VPG to ensure that the protected disks and recovery disks are the same. Recovery operations cannot occur until after the initial synchronization has completed.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
Adding a virtual machine to a VPG is similar to creating a new VPG, a volume initial sync is performed for the new virtual machine. For more information, see Volume Initial Sync.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
Journal/recovery disks are missing
Zerto Virtual Manager cannot locate disks that were connected to a virtual machine. As a result, recovery operations cannot be performed on the VPG containing the virtual machine.
Journal storage error
There was an I/O error to the journal. For example, if the journal was full and the size was increased. Once the problem is resolved a synchronization is required.
Moving - Before commit
Preparing and checking the VPG virtual machines in the recovery site.
Needs Configuration
One or more configuration settings are missing, for example, when reverse protection is not specified.
Promoting
Updating recovered virtual machines in the VPG with data from the journal.
Recovery is possible
Communication with the Zerto Virtual Manager at the protected site is down so continuing protection is halted, but recovery on the remote site is available (compare with Site disconnection).
Recovery storage error
There was an I/O error to the recovery storage. For example, the datastore is almost full or the virtual machines are turned off and the recovery disks are inaccessible.
Recovery storage policy error
The storage policy in the recovery site specified to be used by the VPG cannot be found.
Rolling back
Rolling back to an initial status, for example, after canceling a cloning operation on the VPG.
Rolling back Failover
Rolling back a Failover operation before committing it.
Rolling back Move
Rolling back a Move operation before committing it.
Site disconnection
Communication with the Zerto Virtual Manager at the remote, recovery, site is down so continuing protection is halted (compare with Recovery is possible).
Site disconnection. No checkpoints
Communication with the Zerto Virtual Manager at the remote, recovery, site is down and there are no checkpoints to use to recover the VPG at the recovery site.
Syncing
Status while type of synchronization is being evaluated.
User paused protection
Protection is paused to enable solving a journal disk space problem, for example, by increasing the disk size or cloning the VPG.
VM not protected
A virtual machine in the VPG is no longer being protected. For example, when the virtual machine was moved to another host without a VRA.
Volume Full Syncing
Synchronization when a full synchronization is required on a single volume.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal. Also, recovery operations are not possible.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
Volume Initial Sync
Synchronization when a full synchronization is required on a single volume, for example, when changing the target datastore or adding a virtual machine to the VPG without using a preseeded disk.
For synchronization to work, the protected virtual machines must be powered on so that the VRA has an active IO stack, which is only available when the virtual machine is powered on.
Recovery can be performed on a VPG while a Volume Initial Sync is being performed for virtual machines added to an existing VPG. However, only the virtual machines that were already in the VPG can be recovered. The new virtual machines can only be recovered after the volume initial sync for them is complete.
Note: Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual machines can start at different times, depending on when the promotion to the virtual machine ends. All synchronizations are done in parallel, whether a delta sync or initial sync, etc.
VPG has no VMs
A configured VPG where the virtual machines have been removed from it, for example when changing both the datastore and host for the virtual machines in the VPG, causes the VPG to be recreated.
VPG waiting to be removed
An attempt to remove the VPG failed and it must be forcibly removed. For details, see Deleting a VPG When the Status is Deleting.
Zerto Virtual Manager paused protection
Protection is paused to enable solving a journal disk space problem, for example, by increasing the disk size or cloning the VPG.