How Can We Help?
How VirtuCache supports regular vMotion, Storage vMotion, X-vMotion across different vcenter objects?
The table below lists how VirtuCache supports migrating VMs live or cold between Hosts, Datastores, vCenters, Datacenters, Clusters, Sites, and vSwitches.
| Source host where the VM is moving from. | Destination host where the VM is moving to. | vMotion Type. | How VirtuCache supports it? |
|---|---|---|---|
| VirtuCache is installed with the same build number as on the destination host | VirtuCache is installed and running | Live/Cold Migration – Compute and/or Storage | Migration is supported irrespective of the caching policy and when the source and destination hosts are in the same or different clusters, vCenters, sites, and datacenters. There should be network connectivity between the source and destination hosts over the ‘replication network’ |
| VirtuCache was never installed | VirtuCache is installed and running | Live/Cold Migration – Compute and/or Storage | Migration is supported in all cases without caveats |
| VirtuCache was previously installed, OR currently installed but not running, OR running but is a different build than on the destination host | VirtuCache is installed and running | Live/Cold Migration – Compute and/or Storage | Migration is supported irrespective of the caching policy and when the source and destination hosts are in the same or different clusters, vCenters, sites, datacenters. Note that in a live vmotion or restarting the VM after a cold vmotion, and for the first 10 minutes of the life of the live VM on the new host, VirtuCache tries to contact the source ESXi host to serve VM reads from the cache device of that host if the block is not found in local cache of the destination host (we call this read redirect). Because, on the source host, VirtuCache is not running or is a different version, VirtuCache will fail this process quickly. However, if a large amount of storage IO is happening in this VM during the live vmotion or right when the VM starts up after a cold vmotion, then live migration might fail or the VM might freeze for a short duration (under 30 seconds), because it will take VirtuCache longer to fail the read redirect process. One way to prevent this problem is to make sure the VM comes over as uncached and you run the VM uncached for the first 10 minutes, and after the first 10 minutes of the VM’s life on the new host, you then assign it a Write-Through or Write-Back caching policy |
| VirtuCache is installed and running | VirtuCache is not installed, OR VirtuCache is installed but not running | Live Migration – Compute and/or Storage | Live migration is possible but not recommended for VMs with Write-Back caching policy. It is recommended to change the caching policy to uncached or Write-Through before attempting to live migrate the VM. In case live migration is accidentally attempted on a VM having a Write Back policy to a host where VirtuCache is not installed, we ensure that the dirty write cache is first synced to backend storage before we allow the vmotion to proceed. If large amounts of storage IO is happening in the VM at the time this vmotion is done, the VM migration might time out because the destaging of write cache to backend storage is not completed within the 90 second window allowed by VMware for vMotion to start |
| VirtuCache is installed and running | VirtuCache is not installed, OR VirtuCache is installed but not running | Cold Migration – Compute and/or Storage | Migration is supported in all cases without caveats |
| Any scenario | Any scenario | vSwitch only migration without migrating compute or storage | Migration is supported in all cases without caveats |