Moving Hyper-V guest VM to another host

[elsispro]

Is there a way to make VBR be aware of the VM being moved from one standalone Hyper-V host to another and continue the backup chain instead of creating a new chain? For example If I have one job that has multiple Hyper-V hosts added (that is - all possible VMs) and I move some VM from one host to another (even preserving the name and ID of VM) VBR does not continue the original chain, but create a new one instead. This is very inconvenient if there are frequent VM moves. And you cannot delete the old chain right away, because you would lose previous restore points.

[Vitaliy S.]

If you're using Failover Cluster or SCVMM as a root object in the backup inventory (jobs), then migrating VMs between hosts should not cause this behavior. Please review this thread for more information. Thanks!

[willrussell]

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.

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.

Mike,

Was this ever actually considered as an improvement?

We've got a few clients who have only two Hyper-V hosts but no shared storage or VMM server. If we could have a manual mapping tool to tell B&R it's the same VM on the new host that would be very helpful in terms of saving backup storage space.

Will

[Vitaliy S.]

If you're using the reversed incremental mode, then you could use a backup mapping option in the job settings. This option will still create a new full backup, but it will not consume 2x space since you already have a full image stored on the VBK file (latest file). If you're using forward incremental mode, then there are no changes in how Veeam B&R behaves when VMs are migrated from host to host without using Failover Cluster/SCVMM. Thanks!

[willrussell]

Hi Vitaly,

Thanks for the clarification, that's useful to know.

Will

[mkaec]

I was excited to be notified there was a response in this thread, but sad to find that there is still no plan to ease the pain for customers that move VMs on standalone Hyper-V hosts that don't have SCVMM.

[dmitryk8]

I need to move some VMs from one Hyper-V cluster to another. Current VBR build is 10.0.0.4461 P1.
As I understand, the only way is to remove VM from the job and then add again? Or may be there were improvements?

[Egor Yakovlev]

No improvements.
Moved VM receives a new ID at the target host\cluster and is treated as new VM by Veeam respectfully. Re-add is still the way to go, and if mass VM migration is planned, a PowerShell script might ease your migration process with jobs edit.
/Cheers!

[mkaec]

And "Map" functionality that would ease the process after the move is still MIA.

[DrazenSego]

Hi all,
Im have similar question:
In different hyper-v hosts, 2016 and 2019, can i migrate vm from 2016 to 2019 and then back to 2016 (after maintance is over on 2016 host) host with B&R suite. Im not going to upgrade vm version, it will stay V8.

[willrussell]

You can migrate without Veeam, just use Hyper-V (shared nothing) live migration. If your processors are different model/stepping then you might need to turn on the processor compatiblity mode first for each VM (and doing that requires a short VM downtime).

If you are talking about the backup side of things, then the info above is still relevant if you need to back up the VM on its temporary location, i.e. you'll have to re-add the VM(s) to the job via it's the 2019 host, and the next backup Veeam will run will be a full backup, not incremental. Then when you move it back to 2016, you re-add the VM(s) to the job again, and the full backup will happen again. This doesn't happen if you have your hosts configured via SCVMM or within a cluster.

The backup is only relevant if you are moving the VM for an extended period. If you are just dealing with a short (few hours) maintenance window, then your RPO might not need to worry about backup via the 2019 host. Just move the VMs via Hyper-V live migration, do maintenance, then move VMs back again via live migration. Note that storage live migration can take a while (depending on storage speed at both sides, network speed and VM size).

[DrazenSego]

Thx Will,
Thing that worries me, if i remember correctly, vm once moved to a newer hyper v host cannot be moved back because source hyper v host is newer now...
Thats why im looking for B&R sollution.

[willrussell]

It's not an issue with Hyper-V live migration, so long as you keep the configuration at V8. I have moved VMs from 2016 to 2019 and back to 2016 without issue using LM. This is the best way to do it.

Funnily enough it's NOT possible to do this with Veeam - https://helpcenter.veeam.com/docs/backu ... ml?ver=110

"The version of the target host on which the VM is restored must be the same or later than the version of the source host where the original VM was registered."

When you try and restore a backup of a 2019 VM to 2016, it will not let you.

So just use live migration, easiest solution all round

If you want to test for your own piece of mind, create a test VM (it doesn't need an OS installing, so just give it a small disk) and try to move backward and forward.

[DrazenSego]

Many thx Will.
It was 2 years ago since i had that scenario. Thx for guidance.

[audax]

Hello Veeam?
Any progress with remapping utility for HyperV users with standalone hosts?
In SMB environment we cannot all afford SCVMM or cluster.

[Vitaliy S.]

Hi audax,

Unfortunately, there is no such utility for Hyper-V.

Thanks!

[JRRW]

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

Hey now, I resemble that comment!

SCVMM 2022 isn't..... well it's not completely horrible, it has some neat features vCenter doesn't have... But it also leaves a lot to be desired.

[karsten123]

SCVMM 2022 is still not supported

[tagisade]

Any updates on this issue, @Veeam?

[david.domask]

Hi Oliver, welcome to the forums.

Can you clarify which item specifically you're asking about? If it's about migrating VMs between stand-alone HyperV hosts and continuing the backup chain, no new information to share right now. Veeam will be able to track such migrations if the hosts are part of a cluster/added to SCVMM.

[mkaec]

Can I get another +1 each year to apply to this request? It's painful to have moved hosts do a full backup because Veeam doesn't know what is super obvious to the administrators.

[bytewiseits]

Can Veeam please re-visit this feature request - being 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 moved and imported onto the new Hyper-V host, the VM ID can be retained so re-mapping should be possible with the VM ID as the anchor. Yes the Host ID will change (thus the VM+Host ID), however this is a Veeam logic issue that can be altered for re-mapping.

With the current lack of re-mapping, you have to do a full active full backup of each VM again, which in turn creates another full backup chain in any local and remote backup copy jobs as well. For offsite copy jobs it takes much more time to upload a full backup offsite again as well where it really should not be needed in the first place (as it is the same VM).

Though retention is fairly self governing, once the 'old' VM backup GFS points age out we still have to manually remove the last remaining backup as well to free up that space. If the chain was re-mapped and continued on, none of this would be needed.

We really need Veeam to look at addressing this shortfall in the SMB space where there are many customers with single Hyper-V servers with only a couple of VMs. Refreshing host hardware is not as simple as it should be (ie just move VMs) with the lack of re-mapping.

[sykerzner]

Please, Veeam this would be a huge benefit to us also.

We have been many of our clients to Veeam over the past 5 years. At this point, some of their hosts' hardware is getting old and need to be replaced. Since this causes Active fulls, (double space, offsite etc), this is a real painpoint. This also assumes we have the space on the local Veeam storage or in the cloud, or have to sell our clients more space, just to get this done...

[tvveen]

Can Veeam please re-visit this feature request - being 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 moved and imported onto the new Hyper-V host, the VM ID can be retained so re-mapping should be possible with the VM ID as the anchor. Yes the Host ID will change (thus the VM+Host ID), however this is a Veeam logic issue that can be altered for re-mapping.

With the current lack of re-mapping, you have to do a full active full backup of each VM again, which in turn creates another full backup chain in any local and remote backup copy jobs as well. For offsite copy jobs it takes much more time to upload a full backup offsite again as well where it really should not be needed in the first place (as it is the same VM).

Though retention is fairly self governing, once the 'old' VM backup GFS points age out we still have to manually remove the last remaining backup as well to free up that space. If the chain was re-mapped and continued on, none of this would be needed.

We really need Veeam to look at addressing this shortfall in the SMB space where there are many customers with single Hyper-V servers with only a couple of VMs. Refreshing host hardware is not as simple as it should be (ie just move VMs) with the lack of re-mapping.

+1 please re-visit this @Veeam

[DVelez]

A customer with a very small network is replacing his server and moving all Hyper-V VM's to a new one. It is possible to move the VM's to the new server without starting a new backup chain?

Thanks!