Great article ​@Link State ,

i heard from my Colleagues who are doing azure Local that there is an issue with Arc enabled VMs restored to Azure Local because you cannot manage them via Azure Portal afterwards. The reason is that they are not Arc-Enabled anymore and according to my colleague there is no easy way to get them back into the portal.

Have you encountered that issue as well or do you know how to get around that issue?

Regards

Chalid

Hello ​@CMF  , at the moment we have only performed recovery tests to verify the performance and quality of the backup.
However, we are encountering anomalies on the ARC agent during the migration of VMs from VMware to Azure Local. First, it is necessary to remove the ARC agent, install the Hyper-V drivers, and then migrate it. If this step is not performed, the VM will be duplicated on the Azure portal.

The problem you have encountered is well known. Here are some links on the subject:

Does Can enable Arc on non arc vm? - Azure Stack HCI - Microsoft Q&A

Thank you for the clarification. As noted in my previous answer, as the VM in question was an Arc-managed VM, unfortunately, there is not a process currently to get the restored VM added back into the portal. The only method to get any VM to show within the portal is to deploy the VM using the steps described in this article series. This is also noted in this article (first Note). We hope to bring this capability into a future release.

Az Stack HCI recover as arc-vm - R&D Forums

Azure Stack HCI VMs backed up by Veeam Backup and Replication just restore as Hyper-V VMs. Veeam has no control over its status as Azure Arc enabled VM.

If a VM was Arc-enabled, and the original is deleted, that VM restored by Veeam within 45 days would maintain its Arc connection, only if no other VMs are using that Arc connection.

However I believe Microsoft is considering some enhancements as to how VMs created in Hyper-V Manager could show up as Azure Arc enabled in the future.

Regards

We migrated our entire VMware environment to Azure local. It's important that the backup job uses the “on-host proxy”. While we also have VMware proxies, and the Hyper-V backup job used these proxies, the proxy doesn't have permission on the Hyper-V host. As a result, the checkpoint creation fails, and the VM locks. The only thing you need to do to restart the VM is to restart the host with the entire workload. This has a significant impact on production.

hi ​@Christoswan 

we use offhost without any problems

ok, I guess you don't have proxies in a VMWare environment? The problem exists when you have backup proxies in both environments

ok, forget what I wrote, the problem still exists

i have deployed an dedicated vbr only for Azure local m8. 

very...veryvery new user here, the powershell commands are to type in to any of the azure stack hci local nodes dealer’s choice?

or on the win25server that is running veeam, or both works but X or Y is preferred?

just because i had to add exception for python (azure cli) on all nodes when deploying. maybe i only had to do it on the ‘main’ node. now that i think...

If you intend to apply the policy: I ran it on a single node and the policy is applied to all nodes.

We migrated our entire VMware environment to Azure local. It's important that the backup job uses the “on-host proxy”. While we also have VMware proxies, and the Hyper-V backup job used these proxies, the proxy doesn't have permission on the Hyper-V host. As a result, the checkpoint creation fails, and the VM locks. The only thing you need to do to restart the VM is to restart the host with the entire workload. This has a significant impact on production.

hi ​@Christoswan 

we use offhost without any problems

 

Hi, in your backup job logs for Azure HCI VM, does it says “Using source proxy Name (offhost)” ?