Migrating an instant recovery using vCenter?

[BobbyHood]

What will happen if you have a Veeam instant recovery running and migrate it to production using vCenter rather than through Veeam quick migration? Does Veeam handle that gracefully? I'm on v11a.

[HannesK]

Hello,
with everything you do on VMware side, VMware will not inform the backup product (no matter which vendor), what VMware did.

I assume that you talk about storage vmotion. So the first question would be, why do you want to do it on the VCenter side instead of letting Veeam do exactly the same (we also use storage vmotion if available)?

To answer the question: The VM will be fine, because it's storage vmotion. Instant recovery itself (on the Veeam side) will be orphaned. So you need to stop it manually.

The Veeam repository is "just another NFS datastore". No magic involved

Best regards,
Hannes

[BobbyHood]

Thanks, it worked fine. I was mainly concerned that unpublishing the VM after a vCenter migration could delete the VM but it didn't.

I had to do it with vCenter because the "migrate to production" option was grayed out. I previously started migration the right way but I manually stopped the session. Afterward the migration option was no longer available. Apparently it doesn't reset when the session is manually stopped. Some work had been done on the restored VM so I couldn't unpublish and start over.

[david.domask]

Hi @BobbyHood,

Thanks for sharing the result. The greyed out part is a known issue found in v11a set to be resolved in a future release (for PMs, issue 382627) and your workaround is quite valid. It indeed is related to the starting/stopping, and shouldn't happen like that in future releases.

[Seve CH]

Thanks, it worked fine. I was mainly concerned that unpublishing the VM after a vCenter migration could delete the VM but it didn't.

Do not forget to remove the write-redirect snapshot. After doing the storage vMotion, your VM is still running on the snapshot and Veeam won't remove it.

[DanielJ]

Borrowing this thread to describe my use case. I have an imported giant vm in Azure format, which I need to restore into VMware, so the only option is using instant recovery. Since the vm has so many large disks, "migrate to production" just takes too long time. It runs into the backup window and is then interrupted by timeout errors (yes, it's strange. I thought restore traffic was always prioritized). If it had been possible to deselect some disks before migrating to production, and then migrate one disk at a time into the same vm, I would have done that. But it seems that it's not possible (single disk instant recovery seems to not be available at all for imported backups). So I'm now storage migrating the IR published vm from vCenter, since that can be done with a single disk at a time. Like the OP of this thread I was afraid that the vm with all its migrated disks would be simply deleted when I stop publishing it, but if the above is correct, VBR will leave it. I wonder, how does VBR decide wether to delete the vm or not? Is it enough that something has been changed from the VMware side?

[HannesK]

Hello,

I have an imported giant vm in Azure format

could you maybe explain what "Azure format" means? What type of backup is it and why is it "imported" instead of "external repository"?

It runs into the backup window and is then interrupted by timeout errors (yes, it's strange. I thought restore traffic was always prioritized).

This makes zero sense to me: backup should not affect the migration, because that VM did not exist before in VMware. How can it be, that a new VM was added to a backup job (I guess backup jobs based on folders, resources pools etc. So exclusions should also solve that)?

I wonder, how does VBR decide wether to delete the vm or not?

Veeam knows its own datastores. The software does not delete VMs on production datastores.

Best regards,
Hannes

[DanielJ]

could you maybe explain what "Azure format" means? What type of backup is it and why is it "imported" instead of "external repository"?

Platform = "Microsoft Azure" in the Imported view. Created by Veeam for Microsoft Azure, I would presume. It is imported because it was located on a Cloud Connect repository, then copied to a Windows server managed by the VBR server used to create the instant recovery session.

This makes zero sense to me: backup should not affect the migration, because that VM did not exist before in VMware. How can it be, that a new VM was added to a backup job (I guess backup jobs based on folders, resources pools etc. So exclusions should also solve that)?

I did not say that the published vm itself was being backed up. The whole restore was running so long that it ran into the backup window; lots of backup jobs started competing for bandwidth and after a couple of hours the quick migration job timed out. We continued to migrate this customer's vms during the next night as well, and did not see any more timeouts or similar problems after we started using storage migration from vCenter instead of "migrate to production".

The software does not delete VMs on production datastores.

I know it doesn't delete vm disks on other datastores, but it does unregister the published vm from vCenter. That's what I called "delete the vm", even if any migrated disk files remain on the datastores. I simply wondered how VBR decides wether or not to do this, and I have seen now that the unregistering happens as long as there is still at least one connection to the Veeam datastore (configuration file or disk file(s)). Makes sense.

[HannesK]

Platform = "Microsoft Azure" in the Imported view. Created by Veeam for Microsoft Azure, I would presume. It is imported because it was located on a Cloud Connect repository, then copied to a Windows server managed by the VBR server used to create the instant recovery session.

nice one - that's mobility

lots of backup jobs started competing for bandwidth and after a couple of hours the quick migration job timed out.

well, it's always complicated, if hardware is not fast enough. But I understood the problem now, thanks