Moving Hyper-V guest VM to another host

[Caillin]

I'm currently evaluating Veeam to backup our 3 hyper-v host nodes. If I create a backup job protecting a VM on Node 1, and then live migrate that VM to Node 2, it looks like the Veeam job needs to be modified with the original VM removed and the same VM on the second Node added and the job re-run. At this point, it copies all the data again from scratch, and creates a second set of backup files on disk with none of the original recovery points.

Is there some way to be able to tell Veeam that it's the same VM, just on a new Host and re-attach the backup file and recovery points?

I'm just worried about in the future when we want to load balance and move some VMs around between the hosts via Live Migration, that we'll lose all our hierarchical GFS recovery points for the moved VM.

[Caillin]

Might also add as it's not clear in my OP, this is not in a clustered environment. This is just 3 separate Hyper-V hosts with local storage.

[nefes]

You can either join that hosts to the cluster or to SCVMM and add it (cluster/SCVMM) to Veeam instead of standalone hosts. In that case VM will be tracked after Live Migration.

[Caillin]

We have a SAN and clustered environment now, but the environment we are migrating too, we will be using local storage and non-clustered Hyper-V nodes.

So if Veeam can only track virtual machine moves on a cluster (it doesn't support live migration between non-clustered hosts), is there any way to manually point the Veeam backup job to the newly moved VM and have it recognize it as the same VM, without treating it as a completely new VM and losing all the recovery points?

[foggy]

VMs are tracked by their unique IDs and migrating VMs within a cluster allows to preserve those ID's. However registering a VM on a standalone host assigns a new ID to it. You could run a query against Veeam database to replace the old VM ID with the new one after migration, however this is generally unsupported as could lead to undesired consequences.

[Vitaliy S.]

Caillin, you can use backup job mapping functionality (on the "storage" step of the wizard) to continue running incremental passes for your existing VMs.

[jetjaguar]

Hi forum,

i was wondering - how do i setup my backup of VMs if they reside on a different HV-Host (because i moved them). Is there a way to handle this?

I have 4 Hyper-V-Servers, every server with different VMs. Everytime i move them i get the error in the backuplog. How can i avoid this behavior? I have no Hyper-V-Cluster. I don´t want to manually edit each backupjob everytime the VMs are moved.

Thanks for insight.

Greetings

[PTide]

Hi,

Please review this thread for possible resolutions.

Thanks

[jetjaguar]

Thanks for the push.

To clarify things for me: The only way to track a VM is in a clustered environment? Because i don´t have a Hyper-V-Cluster nor am i planning to set one up.

[jetjaguar]

Couldn´t i just back the VMs up as standalone windows servers? What are the benefits of backing up machines via Hyper-V (standalone) when i can´t track the VMs over several standalone Servers?

Thanks again.

[PTide]

The only way to track a VM is in a clustered environment?

You can also use SCVMM as a central point of control, that will allow you to track VMs too.

Couldn´t i just back the VMs up as standalone windows servers?

Sure you could - just use Veeam Agent for Windows to backup VMs on the guest level.

What are the benefits of backing up machines via Hyper-V (standalone) when i can´t track the VMs over several standalone Servers?

Well, actually I can't come up with any, too.

Thanks

[mkaec]

If you're not clustering and you're not using SCVMM, then when you move a VM, Veeam doesn't see that and instead thinks the old VM has been deleted and a new one created. I'd really like for our use case to be supported better (standalone Hyper-V hosts without SCVMM).

[PTide]

Veeam tracks VMs based on VMs ID, which changes when you move a VM to another standalone host, that's a 100% normal Hyper-V behaviour.

[mkaec]

Veeam tracks VMs based on VMs ID, which changes when you move a VM to another standalone host, that's a 100% normal Hyper-V behaviour.

I don't think that's correct. I tested it two years ago and a live migration did not change the VM ID.
post159538.html#p159538

According to foggy, Veeam is also tracking the host ID and that is what breaks things after a move.
post159819.html#p159819

I actually did some maintenance recently in which I had to reformat the volume holding the VHDX files. I moved the VMs out, formatted the disk, moved them back in and Veeam was none the wiser.

I get why this design decision was made. But that's what it was...a design decision. I think it would be possible to better support VM moves for the standalone host scenario if the desire existed to do it.

[spgsit5upport]

Because i don´t have a Hyper-V-Cluster nor am i planning to set one up

Then you really OUGHT to re-think your design!

[brentearls]

I know historically if you moved a Hyper-V VM from host to host or cluster to cluster there was no way to remap it to the backup, so you had to manually remove and re-add the VM and the next backup was a full. I couldn't find any posts after about 2016 on this topic though. Is that still the case? I know with VMware there is the vcenter migration utility that essentially does the equivalent for VMware, but I can't find any option for Hyper-V.

[Vitaliy S.]

Yes, that's still the case, cause the way VMs are identified in Hyper-V hasn't been changed.

[spgsit5upport]

But Veeam should have mapping functionality for the odd occasions when VM ID is changed due to move (like between clusters which are no managed by SCVMM - perfect scenario is when one replaces WHOLE lot of hardware - hosts & storage)

[Rambler]

Can you clarify this for me once again? If I have standalone Hyper-V hosts managed by VMM and Live migrate a VM between these standalone servers (shared-nothing LM including storage), the VM GUID doesn't change. Will Veeam recognize this is the same VM and continue backups without intervention or how will it treat this?
For example, SCDPM has VMM integration so when you move a VM this configuration, DPM recognizes it and performs a consistency check job (ie. reads the whole VM again and updates the backup with modified blocks), but at least it does it automatically.

[nmdange]

As long as your Hyper-V hosts are added to Veeam via SCVMM only, then you can move the VMs between any host or cluster in VMM and Veeam will still recognize it as the same VM. In my experience, when the VMs are on 2016 hosts and VM version 8+, Veeam does not have to reset CBT data and continues just reading the changes. On 2012 R2 and earlier, then it would have to re-read the entire VM.

[Mike Resseler]

NMdange is correct.

In 2016 hosts and higher have an MRT and CRT file next to the VHD(X) and that file contains the CBT data. When you do a migration (whatever type of migration) that data is moved alongside the virtual disk and we can continue to work with it (because we know of the move through VMM).

Pre-2016, we have a specific, own created CBT type of driver. But it is per host which means if the VM gets moved, that CBT driver data is not moved with it.

I hope that clarifies things a bit

[Rambler]

Thanks for the clarification nmdange and Mike Resseler, one more question/scenario: what happens in scenario when VMM is not available? I assume backup fails (since it doesn't know the VM was moved), but what steps are you required to take in order to continue with the backups and can this be automated (scripted)? For example I have a standalone Hyper-V server with 100 VMs, I migrate all VMs to different host to perform host maintenance, but need to ensure backups will continue on the new host with the least ammount of (manual) work (if any).
We're talking WS2016(2019) Hyper-V and latest B&R.
Note: I apologize for asking in case this scenario is documented, feel free to refer me to documentation. I'm not a Veeam B&R user, I'm just researching DPM alternatives.

[Mike Resseler]

If SCVMM is down, we can't query it and the job will fail. Once VMM is back up and running, I believe a simple rescan of the VMM server should do the trick

[Rambler]

I worded my question poorly - I meant scenario where VMM isn't used at all to manage the hosts/VMs.

[mkaec]

That's a scenario I wish Veeam would build in support for. You need to delete the VM out of the job and add it back in associating it with the new host.

[Mike Resseler]

Marc,

It will be difficult to add support for that. We can't do that either with VMware. It is because vCenter is their SCVMM (And no, don't start saying which one is best ) that we have that support. vCenter is widely used by everyone with VMware while Hyper-V has... Well, not so much SCVMM fans...

I agree it is not pleasant, but unless we have a control center to connect to, we are in the dark

[mkaec]

Mike,

It would actually be possible to do for the normal case. The VM GUID does not change when the VM is moved (at least on Hyper-V). B&R currently maps the VMs based on both the GUID of the host and the VM. Logic could be implemented that if a VM is missing from a backup job, to see if the missing GUID is now present on another host and automatically link it back up. This would work 99% of the time, but I understand if you wouldn't want to implement something that is not 100%.

However, what your standalone host users could use is a mapping tool that would allow an administrator to tell B&R where a VM has been moved to, just like there is for telling B&R where backup files have moved to. This would be a suitable solution for the standalone host users. They typically don't move VMs that often, but when they do it is unpleasant to have to restart the backup chain over again.

[Mike Resseler]

Hmmm. That might be something to consider. Fact will remain that it will be a full backup on everything pre-2016 because we lost the incremental knowledge there.

[mkaec]

That's interesting. When vCenter or SCVMM is involved, do you also lose the incremental knowledge of the pre-2016 VMs?

Even if a full backup were required for the older guests, there would still be some benefit for them. The old backups would still be associated with the VM for restore and for proper retention handling. When I move a VM on a standalone host, I sometimes find that I have to manually clean up the orphaned restore points.

[Mike Resseler]

We don't lose them. We will continue to use incremental backups, but on the first run after we lost the knowledge, we have to do a full scan of the VM to understand what is changed, and then store the backups. What it means is that there will be more load on that host and that incremental will take longer than normal