Moving Hyper-V guest VM to another host

[Mildur]

Hi Ryan,

I’ve moved your topic to the existing discussion.
You’re not the first customer to ask about migrating VMs to a new standalone cluster while continuing existing backup chains.

There are several topics on our forum regarding this scenario, including at least one mentioning an "unsupported method." Unfortunately, we cannot comment on these unsupported approaches. Running SQL queries outside of official support is not supported.

Best,
Fabian

[JRRW]

Are any Sticky? Because, I tried searching for this in the forums and either A: your search is atrocious or B: it's being filtered, because I couldn't find any of these existing topics.

[JRRW]

why not sizing your repositories correctly?

For some systems, this is not an option to have x2.5/x3 storage space.

Case in point, even at our ROBOs we have massive file servers. We have enough space to restore one or two for short time periods, but you're talking about having x2 the storage for long periods of time (assuming you have longer on disk retention) and with ReFS/XFS synthfulls, we don't have them running on dedupe appliances that would otherwise make double identical backups fit easier.

[mkaec]

You’re not the first customer to ask about migrating VMs to a new standalone cluster while continuing existing backup chains.

How many more need to ask before product management would consider putting something into the development queue to address the need?

[bytewiseits]

Can Veeam please re-visit this feature request (asking yet again as this is an actual problem that is being faced in the real world):
To be able to move a VM from one standalone Hyper-V host to another and then re-mapping the existing backup to the VM within Veeam?

When the VM is migrated to the new Hyper-V host, the VM ID is fully retained (so why not use the VM ID as the primary anchor?). Veeam just need to add a way to re-map the Host ID for the VM similar to re-mapping a backup chain. Even if a general check is done to verify the VM ID is the same (so cannot map to a different VM accidentally).

With Immutable storages both onsite and offsite becoming more common this is causing even more issues with retention and space utilization (particularly with immutable GFS), as well as the completely unnecessary re-upload of the offsite VM data (complete full instead of continuing as an incremental).

And before any further comments about 'sizing storage' properly or having a full Hyper-V cluster - for us specifically, we generally have multitudes of smaller customer deployments with just a single host (migrating VMs during host hardware upgrades), or slightly larger sites where a full blown cluster is just not practical (ie just 2 nodes with local storage). Building out a full cluster with the associated management requirements just shouldn't be necessary for a backup product to provide some basic maintenance functions in these scenarios. We shouldn't need to have 2-3x the storage space (and multiple immutable chains) just to continue a backup of the same VM due to a backup provider limitation (and yes - this is a Veeam limitation, not a Hyper-V limitation).

Please Veeam - put some development cycles towards this highly annoying VBR limitation and show Hyper-V admins some love!