DNS for RHEVM with separate NICs for host management and Internet connectivity

Latest response


I would like to set up RHEV-M so that there is:


- a NIC which is connected to the host management VLAN (i.e. the rhevm network).  This VLAN is generally not accessible from most of our network.


- a separate NIC which is connected to a network which is widely accessible


Since there are two NICs, there must be two IP addresses.  Similarly, there should be two domain names for the two IP addresses. 


Should the FQDN for RHEV-M be the domain name on the management network?  It seems to me that it should.


For example, I could name the NIC on the management VLAN rhevm.example.com.  The NIC on the widely accessible VLAN could be desktop.example.com.


Then, the hope is that users could access the User Portal using a URL with desktop.example.com.  The SSL cerfificate would have to be signed for desktop.example.com, even though RHEV-M's FQDN is rhevm.example.com.


This sounds like a VDI setup in the making.


Here is what I would do, given the need for two separate networks:

1. set up the rhevm network in a separated vlan/subnet, with it's own DNS working internally, resolving RHEV-M and hosts, and possibly an IDM/AD server as well. leave the domain names normal, rhevm.example.com, host1.example.com etc

2. set up another network, which will also be example.com, but with a separate DNS server, in this network one of rhevm's "legs" will be connected, as well as all the hosts' will have a NIC or bond there, attached to a logical network designated as "Display" network in RHEV. The public DNS will keep the same names, but the A records will hold different IPs for rhevm.example.com and hostX.example.com. 


A user in the public network, going to rhevm.example.com, will be presented with an SSL certificate signed for rhevm.example.com, not a specific IP. And when that user initiates a Spice session, RHEV-M user portal will redirect him to an IP of a host's display network NIC, which is also in the public network.


This is as basic as it gets, I know people implemented more complex setups, using reverse proxies and complex routing. Maybe some of them can pitch in, in this conversation