Reliability reasons. This approach does not currently work reliably (issues on Hyper-V VSS side). Too many intermittent VSS failures.
We actually have this logic implemented, and may end up enabling it in v8, but it will still be heavily limited to no more than a few VMs per CSV being processed at once. Folks with really fast SAN will be able to tweak the maximum amount, but for average hardware, the limit will need to be pretty low (think 3-4 VMs at once).
baltechnique wrote:Since there is a SAN snapshot of the volume, each VM file is available separately (i'm not talking about vss inside the running VMs for application consistency), and since the snapshot is finished on the SAN, the redirected mode is back to normal mode for hyperV.
Consistency groups: Jobs can now process more than one VM from the volume snapshot at a time instead of creating a separate volume snapshot for each processed VM. For reliability reasons caused by Hyper-V backup architecture, the maximum amount of VMs is limited to four per snapshot by default in case of software VSS, and eight per snapshot in case of hardware VSS, but can be increased on fast primary storage with the MaxVmCountOnHvSoftSnapshot (DWORD) and MaxVmCountOnHvHardSnapshot (DWORD) registry values under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key.
foggy wrote:The main requirement is that only VMs residing on the same host can be processed from a single snapshot.
For instance if VM1 and VM3 are stored on the same CSV must i modify it like this :
VM List : VM1, VM3, VM2, VM4
or VM1, VM2, VM3, VM4 does also work ?
and you're also saying that i must migrate all VMs sharing same CSV (at least 4 by 4 or 8 by 8 if using hardware VSS) to same HyperV Host before backup ?
jmeisel wrote:The Backup-Job that should backup several VMs that are running on different HyperV-Hosts...
Users browsing this forum: No registered users and 1 guest