HyperV to Azure HCI migration

[Rumple]

So, apparently veeam can backup and restore VM's from HyperV to Azure Stack HCI 20H2...but can't replicate?
https://www.veeam.com/kb4047
That seems...odd...i would have expected if you can restore, then doing multiple change block restores should also be easy.
Especially since despite Microsoft claiming Azure Stack HCI is a New OS...its clearly not...its Windows Server 2019 with alot of functions ripped out (or just disabled).
I would say Azure OS is atl east 75% server 2019 at its core...

[Gostev]

Can you please quote where does it say it can't replicate? I am unable to find it mentioned in the support KB article.

[Rumple]

Veeam Support - Case # 04966859
Hi Mark,

Thanks for contacting Veeam Support. As for now, Veeam only supports the backup and restore of VMs from Hyper-V to Azure HCI, replication is not supported at this time.
Veeam supports backup and restore of virtual machine workloads running on the initial Azure Stack HCI
https://www.veeam.com/kb4047
Please let me know if there are other issues.

[Gostev]

Well, they are just referring to the same KB, which never mentions replication as unsupported.

I searched and couldn't find such limitation mentioned in any official release documentation, system requirements or known issues. I also know that Azure Stack HCI v1 is absolutely regular Hyper-V under the hood.

Can you please ask your support engineer for their source of knowledge? Unfortunately I can't just check with the responsible dev lead at this time, as he is on vacation. But I don't remember him ever mentioning this.

[Rumple]

I've asked in the ticket what replication isn't supported as the article doesn't say it is NOT supported and indicated that its possible that its being taken way too literally.

[johan.h]

If I remember correctly replication to Azure Stack HCI should work for you, the reverse may not be as successful.

Azure Stack HCI largely is still similar to normal Windows, but as things progress some storage related features (S2D) will diverge when compared to the normal Windows branch.

[johan.h]

Just double-checked for you. Replicating to Azure Stack HCI works. Doing the reverse results in a "following hosts are incompatible with the target host" error.

[Rumple]

thanks. So, my situation is that I have a hyperV cluster in Forest A, and HCI 20H2 in forest B...no connectivity is allowed between them directly.
HyperV is using SMB with offload Host. I have allowed the Veeam server + the Offload Host to bridge the networks and with hostfiles on each to resolve the HCI cluster name and server names.

The Veeam server succesfully added the HCI cluster but I am trying to replicate a VM between them. In my mind the veeam server should be acting as the proxy or at very least, the offhost proxy should and using credentials within veeam it should be able to replicate that VM over...

that was effectively the reason for the ticket.

[johan.h]

It looks like there are some connectivity issues, please continue to work with support on that. If these are in different forests make sure Veeam, and all Veeam components can access all required parts of the infrastructure with the correct credentials. If you have only allowed your off-host proxy to talk to the destination side, it is very likely that isn't enough.

Note that you will not be able to replicate from your HCI 20H2 server back to the Hyper-V cluster in Forest A.

[Rumple]

waiting for them to get back to me yet again.
Last test was to see if I could connect to port 2500 on the HCI host thats the destination for the replication job, but its not listening on port 2500 for any service so not sure if that's a problem or not.

[Rumple]

I swear to god if I run into any more first level techs that can't read I am going to lose my freaking mind.

they asked me to check if I can connect from offhost proxy to port 2500 on the HCI host.

That fails to connect because port 2500 is not listening on <HCI Host serverip>. I did turn the windows firewall off first just as a test…

PS C:\> netstat -ano | findstr "2500"
PS C:\>

His response:

Currently, even with the firewall off, the host is still not responding to connection attempts to port 2500 in your testing correct?

It would appear that there is still something on the network or the Operating System itself that is still causing this communication failure. As for ports not listening even with the firewall disabled, unfortunately this does specifically sound like an issue within the Operating System.

For proper communication, I would like to add that ports 2500 - 3300 would need to be open and allowed to communicate, are any of these ports listening on the HCI host?


I sent this message - Any further tests I can do….if the HCI host isn’t listening on port 2500…is it missing something? Is there a service to check,etc?

Obviously there is something missing if the destination Host does not have a service listening nothing can connect. Now, if only I could get someone to fucking respond to tell me what should be listening, what service I should look for, etc maybe I can get this ticket resolved before my 50th birthday....

[Mildur]

You can always escalate the case to a manager, if your unhappy with the responses or the response time > https://www.veeam.com/kb2320

[Rumple]

I do try and NOT use that card unless its a critical situation. I mean this is holding up my migration, but outside of being frustrated with the responses, its not really impacting business to the point I need to jump up and down on them

[Mildur]

Ok

[Rumple]

Wanted to close out this issue. Did some testing on my own after a few questions from Veeam support and realized that all the networking was 100% intact and working. IE, my B&R server plus my offhost proxy both could contact the HCI nodes/Cluster name and could resolve them (though use of hostfiles) but ultimately the problem was, as soon as I put load on the network, it crapped out causing the oddball errors.

Went in and swapped out network cables on the team and did more file level copies and got successful copies. Tried my test replication job and it worked fine too. no issues at all.
Being in a network team and having a bad cable somewhere made it an intermittent problem to troubleshoot.