Hyper-V Replica using IP Address instead of NETBIOS/FQDN
Is there any chance to have Hyper-V Replica to work over IP address instead of NETBIOS/FQDN?
Without messing with DNS / hosts file (%windir%\system32\drivers\etc).
Scenario: Sending replica traffic over dedicated network.
Network Constraint (control which networks HR runs upon, based on network interface).
A function similar to the control for live migrations would be optimal for us.
A sequence of priorities from multiple networks and a maximum same time replications.
QoS does not have to be, we can also control it elsewhere.
Agree. Nothing to add
Andreas Hagberg commented
Needs to be dedicated traffic for replication. With IP.
This feature would help our DR configuration significantly as currently all replica traffic is "bundled" with production traffic across our site-site VPN. If we could move this data onto a different VLAN / IP subnet it would make QoS across the enterprise significantly easier and would help us prioritise production traffic over replica traffic on critical links where bandwidth is limited.
Currently it is possible but it's a significant overhead to configure, especially across multiple cross-customer managed environments. Enabling this out of the box via GUI and/or powershell would be a significant benefit for our business.
I am adding my vote to this. But I would also like to see the option to adjust throughput values on a specific interface. The difference when "moving" (copying) a running VM, versus a turned-off VM, is staggering due to some inbuilt/hidden throttling. This is discussed here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/49f56d32-c7f4-440c-87fd-2fa8262a6e57/live-migration-throughput-running-vs-off?forum=winserverhyperv
Stanislav Zhelyazkov commented
It still needs to be netbios/FQDN based but to allow you to define DNS names for replica endpoints.
Jean-Francois Aprea commented
Okay for that,
In fact, in 2012 R2, it is not intuitive to direct Hyper-V Replica traffic
• DNS or HOSTS file is needed to direct resolution to “the good destination IP and from the source too”.
• Because enabling a Hyper-V Replica for a VM requires specifying the target host by name / fqdn, the target host name will respond by default with the IP address bound to the management interface if we defined the primary IP.
• In this case, the replication traffic is sent via the management interface from the source host to the management interface of the destination host and we don’t want this behavior
• For example, it should be cool to use the live migration VLAN for Hyper-V Replica replication traffic.
To do that today, we need to direct the replication specifically, with DNS or HOSTS files and we have to use certificate based mutual authentication.
A good approach should be:
• to “connect directly” the Hyper-V Replica Feature with a dedicated NIC at the Hyper-V host level (and not playing with artifact as DNS or HOSTS files)
• to have the ability to attach the Hyper-V Replica Feature for a specific VM or “VM Group” to a specific NIC (or TEAM). The idea is to have a “Hyper-V Replica preference directed replication traffic for specific VM or Group of VM”
Just my 2 cents to modernize this so cool feature,
Silvio Di Benedetto commented
I'm agree with Charbel
Kurt Roggen [BE] commented
Indeed, to be able to use a dedicated network (interface) for replication traffic.