Veeam Hyper-V Replication and non-Microsoft SMB3 Storage

[Lewpy]

What is the correct way to configure Veeam so that it can replicate a Hyper-V VM (2012 R2 in my case) between clusters, with the destination storage on an SMB3 share hosted on a Dell EMC Unity XT SAN (NAS server)? Why this particular storage configuration is in use is not the question [it is a temporary step in a bigger migration process]
I tried moving a replica target from CSV iSCSI storage to the SMB3 share (all went smoothly), and performed a "reseed/remap" in the replication job (again, the Veeam console accepted this), but I then got issues during replication that looked as if Veeam was trying to perform RPC calls against the SMB3 server and not liking the responses
So I moved the replica VM back to the CSV, and the retry worked fine. So I hadn't broken the replica VM by moving it.

I should point out that the SMB3 share is working fine for live VMs in the cluster, and I can move running VMs back and forth with no issue, and between Cluster Nodes, etc.

Obviously, I can't install any Veeam components on the NAS server offering up the SMB3 share, as it is non-Microsoft.
I am also aware that CBT will fail when I get round to moving the source VM to the SMB3 share topology too (pre-Windows Server 2016 hosts, so no native CBT).

I have a suspicion I need to add the SMB3 Share in to Veeam console (so I can define some credentials to use against it and perhaps avoid the RPC errors), but it is not exactly clear this is the correct approach?
The only location I can find to add the SMB3 share is under "Inventory -> File Share", which kind of implies you want to back it up rather than send replicas to it.
Or is this a topology that won't work?

*Update*
Sorry, I should state it is using Veeam B&R Enterprise v11.0.0.837

[PetrM]

Hi Lewis,

Backup of VMs whose disks are located on SMB3 share is supported, furthermore it's supported for both standalone and clustered servers. This page might be helpful, you'll find there the full list of requirements for every Hyper-V version. You should add SMB3 server as a component of backup infrastructure using the corresponding wizard, file share is a different solution for backing up a huge amount of files.

Also, it's difficult to say what is the source of the issue without seeing a full text of mentioned RPC errors. On the other hand, our possibility to troubleshoot technical issues over forum posts is quite limited and it would be best to show these errors to our support engineers so that they can narrow down the issue based on debug logs analysis.

Thanks!

[Lewpy]

Hi Petr,

Thanks for your reply
Yes, I deliberately avoided posting the details of the RPC errors, as I know this isn't a "technical support" forum, so I aimed my question more at "can I do this or not" .
Looking at the Wizard you pointed me at, that does clearly state on Step 3 that it needs to be "Microsoft Windows Server 2012 or newer", so I can't use that to add the non-Microsoft SMB3 server as it wants to deploy the Veeam components to it
Just to re-iterate: this isn't a backup from, but a replication to, if that makes a difference?

Thanks,
Lewis.

[PetrM]

I misunderstood the question, I thought you just need to add SMB3 server. It's not possible to use non-Microsoft server as a target for replication and SMB3 server cannot be used neither, this table reflects roles that can be assigned to different server types.

Thanks!

[Lewpy]

Hi Petr,

To me, that table isn't very clear for my scenario
My "target" is a Microsoft Windows Server 2012 R2 Hyper-V Cluster Node, so that is supported.
It's the fact that the VM storage is on a remote non-Microsoft SMB3 server that seems to be causing the issue.
I don't want to target the SMB3 server directly, it is accessed indirectly via the [supported] Hyper-V server.
The Hyper-V server can read/write to the SMB3 server using its SYSTEM/ComputerAccount$, so I kind of don't see why the Veeam agent on the Hyper-V server can't do the same (without needing any extra credentials).
In this scenario, it appears that Veeam is being "too clever" and wanting to interact on the remote SMB3 server, rather than just sending data to the remote SMB3 server
It looks like native Hyper-V Replication may be the solution to this scenario then.

Thanks,
Lewis.

[PetrM]

Ok, I see now, thanks for explanation. At first sight, it seems to be unsupported since we can place replica in MS SMB3 shared folder only, look at this step of replica job settings. However, I'd prefer to get more time to consider your scenario before I provide any "final" statements.

Thanks!

[PetrM]

Hi Lewis,

I've discussed your scenario with our QA engineers and we don't see a reason to say that your scenario is unsupported, any SMB 3.0 share which is supported by MS for Hyper-V can be used as a target for replica files. Most probably, there are some low-level details that are out of sight now, for example the cause of RPC errors. Could you please open a support case so that our engineers can examine your infrastructure and troubleshoot these errors? Also, don't forget to provide us with a support case ID.

Thanks!

[Lewpy]

Hi Petr,

I've sorted out my ProPartner account and have just raised a ticket on behalf of the customer for this (Case #04844049).

Thanks,
Lewis.

[Lewpy]

Hi Petr,

Just to conclude this issue, with feedback from support I did the following
1. Apply the latest v11 patch (P20210525, as the customer was on P20210401)
2. Step through the Properties wizard of both the source & destination Hyper-V clusters in the Veeam GUI under Backup Infrastructure, not changing anything but making sure it applied at the end (effectively, an update/refresh)
Following those steps, the replication of the VM on a non-Microsoft SMB3 share in the source cluster replicated successfully to a non-Microsoft SMB3 share in the destination cluster (with a warning over the lack of CBT, but this is expected behaviour in this scenario).

So to answer my initial question: you & the QA engineers were correct, no extra SMB3 share credentials were required, it just "worked" once everything was correctly aligned.

Thanks,
Lewis.

[PetrM]

Hi Lewis,

Glad to hear that it sorted out! I appreciate your feedback!

Thanks!