Automatic Backup After Migration

[mkaec]

I have multiple 2012 R2 Hyper-V hosts configured in B&R. After I used live migration to move a VM to a new host, I checked the backup job. In the "Virtual Machines" tab, clicking recalculate showed a size of 0.0 for the migrated VM. To resolve, I removed the VM, then re-added it from the new host.

Is it possible to configure B&R to automatically make adjustments to existing backup jobs so that migrated VMs will still back up without the need for me to edit the backup jobs?

[veremin]

How your VMs are added to the jobs? Via standalone hosts or via SCVMM?

[mkaec]

They are standalone hosts. The live migration was performed using Hyper-V Manager.

[veremin]

Only VMs added to one cluster or managed via SCVMM (also added to backup console) can be tracked after Live Migration. Otherwise, job reconfiguration is needed. Thanks.

[mkaec]

Only VMs added to one cluster or managed via SCVMM (also added to backup console) can be tracked after Live Migration. Otherwise, job reconfiguration is needed. Thanks.

The referenced link states the reason for this behavior is "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."

I ran some tests with two Server 2012 R2 hosts to test this and it appeared to me that the IDs were not changing. There were 3 things I checked before and after the live migration.

1. Name of the machine's configuration XML file. This is in the format of <GUID>.xml. The file name did not change after the move.
2. The contents of the machine's configuration XML file from each host before and after the move. The only GUIDs I found that changed were "HostResource" and "SwitchName".
3. The ID produced from the PowerShell script available at http://stealthpuppy.com/retrieving-a-vm ... m-hyper-v/. The ID returned by the script was the same before and after the move.

Perhaps older versions of Hyper-V did change the ID when migrated between standalone hosts and that has since been fixed. (I do not have hosts running older versions of Windows to test with.) To me it looks like it is technically possible for Veeam to track moved VMs between standalone hosts, at least with Server 2012 R2.

[foggy]

Host ID's are also used to track VMs and since those are changed after live migration between standalone hosts, there's no ability to track such VMs.

[mkaec]

That's how it currently works. But, it's like that because of a design decision, not a technical limitation. My request is that some intelligence be added to the process.

For example, the current code probably looks something like this:

Code: Select all

if (guestNotFoundOnHost)
    GiveUpAndLogError();

A different implementation might be:

if (guestNotFoundOnHost)
{
    CheckOtherHostsForGuest();
    if (guestFoundOnMUltipleHosts)
        LogErrorAndQuit();
    else if (oneOrMoreHostsCouldNotBeChecked)
        LogErrorAndQuit();
    else if (guestFoundOnOneAndOnlyOneHost)
        UpdateHostIDAndContinue();
    else
        LogErrorAndQuit();
}

I imagine the reason why host IDs are tracked is to handle the edge case when the same guest guest somehow gets registered on multiple hosts. That issue can be avoided while still automatically processing moves between standalone hosts.

[foggy]

You're correct that this is a design decision that is also effective in other areas of product operation. Anyway, thanks for your feedback.

[Battlestorm]

Hi,
I'm currently stuck in the situation where by i have 3 HV Vm's being backed up with veeam from a standalone hyper-v server.
the vm's have been moved to a new hyper-v server and the old hyper-v server has been shutdown, breaking the backups

is there any way to update the backup jobs with the new server/location without recreating them?

regards,
Daniel

[foggy]

Daniel, you would need to add the new host to Veeam B&R and re-add VMs to the job.

[mkaec]

It looks like there is a tool available to deal with a similar issue in VMware (kb2136). It would be nice if there were something like this for Hyper-V that could help remap VMs after a live-migration between standalone hosts.

[nc2500]

What is the proper way of handling Veeam backups when a VM is live migrated to another host (non-clustered environment, no SCVMM)? When doing this, Veeam errors when trying to backup the VM on the host it no longer exists on and when on the new host, it creates new restore points for the VM. This is undesirable as we would like it to maintain its historical backed up data as the VM is only moved to a new host but is the same VM. Is there anyway to tell Veeam that a VM has moved to another host? We add individual VM's to backup jobs and not entire hosts (for licensing and space reasons). Thanks for any advice.

[Dima P.]

Hello nc2500,

You have to add new host to Veeam B&R and configure new backup job. Do not forget to remove the host from your old backup job (if it was set as a source for backup job). Thanks!

[nc2500]

That seems to be a very inconstant way of handling this creating unnecessary full backups. We use live migration frequently. It's unfortunate that Veeam doesn't have a way to recognize this for standalone Hyper-V hosts.

[mkaec]

Yes, please add migration support for us non-clusted, non-SCVMM users.

I know in past discussions there was some concern about B&R making a mistake and linking up two VMs that should not be linked. So, what about a simple tool that admins could use to manually map moved VMs? It would be similar to the "Map a Backup File" function.

[nc2500]

I agree, a simple Veeam tool to map the host would be fine even if manual. Microsoft's development of shared-nothing live migrations has been a great benefit for small to mid-size businesses. Unfortunately Veeam's implementation does not take this major feature into consideration and makes it rather unusable. It seems to me that this is not the way to develop a product by crippling major features that people may use.

[spgsit5upport]

Absolutely, a mature product like Veeam should have this option build in from day ONE!

[mkaec]

In my original post, I asked for Veeam to handle the moves automagically. It would be possible in the most common cases and be very convenient. But if priorities are elsewhere, a way to manually remap would be sufficient, and much easier to implement.