Home > Tintri VMstore™ > Knowledge Base > SyncVM Feature Considerations

SyncVM Feature Considerations

Introduction

This document covers SyncVMTM limitations for restoring a VM from a snapshot, restoring a guest OS file from a snapshot and refreshing virtual disks from a snapshot (see: “Synchronizing VMs, vDisks and Files” in the VMstore System Administration Manual). 

Restoring a VM from a snapshot

This section covers limitations for restoring a VM from a snapshot:

  • If, when restoring a VM from a snapshot, you use a snapshot that contains one or more FLR (File-Level Restore) disks, then those FLR disks may have to be manually removed from the VM in the hypervisor. 
  • When performing RestoreVM operations for Hyper-V VMs, the network adapter configurations are not preserved and revert back to what they were at the time the snapshot was taken.
  • Restoring a VM from a crash-consistent snapshot is fast but may take longer for VM-consistent snapshots, due to the need to communicate with the hypervisor.      
  • VMstore creates a safety snapshot of the VM as a backup, prior to restoring the contents of the VM. 

Restoring a guest OS file from a snapshot

             This section covers limitations for restoring a guest OS file from a snapshot:

  • After restoring a guest OS file from a snapshot, the disk becomes part of a VM. If a Tintri snapshot is taken and used to clone the new VM, the added FLR (File-Level Restore) disk will be included. You can remove the added disk in vCenter. 
  • Restoring a guest OS file from a crash-consistent snapshot is fast but may take longer for VM-consistent snapshots, due to the need to communicate with the hypervisor. Upon completion, a percentage text link is displayed in the VM column next to the VM that was restored.
  • If a disk does not come online after synchronization, check the Storage Area Network (SAN) policy for the guest OS and set the policy to Offline before synchronization. The disks should be automatically added online after synchronization.

Refreshing virtual disks from a snapshot

             This section covers limitations for refreshing a virtual disk from a snapshot:

  • For Linux VMs with Logical Volume Manager (LVM), Tintri recommends using the RestoreVM option, and not the Refresh virtual disks option.
  • If you are attempting to refresh a virtual disk from a snapshot that has just been replicated from another VMstore, be aware the newly created snapshot may not be visible on the SyncVM dialog for up to 10 minutes.
  • If refreshing a virtual disk from a source snapshot that is from a different VM or the SCSI ID is different from the target disk ID, synchronization will be successful but the Windows Guest OS may not assign the drive letter to the same drive.
  • If you click vDisks in snapshot to specify how you would like to refresh the virtual disks in the target VM, it is recommended to not refresh the OS vDisk as part of this workflow, as doing this will cause all customizations in the target VM to be lost. For VMs whose virtual disks have been configured for LVM, please select all the required disks from the source snapshot.
  • Refreshing virtual disks from a crash-consistent snapshot is fast but may take longer for VM-consistent snapshots due to the need to communicate with the hypervisor. Upon completion, a percentage text link is displayed in the VM column next to each VM whose virtual disks were refreshed. 
  • Typically SCSI 0:0 is the OS disk, and is not selected for restoration.

Viewing 1 of 1 comments: view all
As per bug 48935 - This article should highlight the need for a second SCSI Controller per HyperV VM for a successful SyncVM restore to complete.
Posted 05:47, 28 Jul 2016
Viewing 1 of 1 comments: view all
You must to post a comment.
Last modified
10:54, 22 Apr 2017

Tags

Classifications

This page has no classifications.