Forum Discussion

StefanoC66's avatar
StefanoC66
Iron Contributor
Oct 02, 2025

Hyper-v Replica Traffic segregation

We have two standalone Windows 2025 Hyper-v Servers.

They have been configured with a network team for Management, one for VM traffic and one for replica traffic.

We have configured both hosts with self-signed certificate to configure HTTPS replica.

The two hosts FQDN are

host1.company.com

host2.company.com 

and those names are resolved in the DNS with the management Network IP.

To have the replica going through the "replica team" we created on each host's host file two entry like

host1.repl.company.com

host2.repl.company.com

pointing to the replica network IP.

The self-signed certificate of each host contains both fqdn ( xxx.company.com, xxx.repl.company.com )

Problem is that when activating a replica for a VM if we chose xxx.repl.company.com as replication partner the process fails with the error that the hosts cannot be contacted, if we use the fqdn company.com it works.

To test connectivity we also set the hosts file using the replica network IP for the company.com FQDN and it works.

So it's like it doesn't like the FQDN repl.company.,com 

Any Idea on what the issue might be ?

thanks

 

Hyper-V
Windows Server

1 Reply

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor
    Oct 02, 2025

    Hi StefanoC66​,

     

    I'd expect you're running into Kerberos authentication issues since there's no service principal name registrations (contained in the servicePrincipalName attribute) matching your CNAME on the Active Directory computer objects belonging to the hypervisor hosts.

     

    What I wouldn't expect it to relate to is the self-signed certificate, though if you're getting an untrusted root error, you can easily get around that by putting the partner's certificate (without the private key - so just the CER file type) in the other partner's trusted root authority store.

     

    Taking one of my Hyper-V hosts as an example, you can see that by default the hosts registers a number of services under the NetBIOS and DNS names of the actual host:

     

     

    However, if I knock up a CNAME - doesn't matter where (such as in a DNS zone or in the hosts file as you've done), then I'd have to go and add an entry for each relevant service to the computer object's servicePrincipalName attribute.

     

    I haven't bothered using CNAME records for Hyper-V hosts before so I can't authoritatively say which ones are required for your exact scenario, but if I had to guess, I'd work through the services in this order:

     

    1. Hyper-V Replica Service;
    2. Microsoft Virtual System Migration Service;
    3. WSMAN;
    4. HOST;
    5. Microsoft Virtual Console Service (I can't see this being needed but I've listed it for completeness).

     

    Do not add entries for the RestrictedKrbHost or TERMSRV services.

     

    As an example, if I wanted to register a CNAME of hv1.repl.company.com for the Hyper-V Replica Service then my list would grow from:

     

    To:

     

     

    Naturally, you'd need to do this for each required service.

     

    Once that's done, you'd likely need to restart the Hyper-V host for the changes to take effect.

     

    In any case, this is what's required to get Kerberos working with the CNAME. If Kerberos isn't what's holding you back then you may still run into this as an issue later, but for now, this would be my first item to check based on your description.

     

    Cheers,

    Lain

Resources