Hide Forgot
- What is the nature and description of the request? Enable Self Hosted Engine deployment to different subnet from the hypervisor - Why do you need this? (List the business requirements here) From a network security perspective we split hypervisors from management software since they have different needs for inbound/outbound communication. Also we could have a scenario where we have hypervisors on two different network zones that are not allowed to communicate with eachother, but are allowed to communicate with a common management zone. One other issue with the deployment is that it requires a pingable gateway, and that is usually not available in a firewalled environment. - How would you like to achieve this? (List the functional requirements here) Enable deployment of self hosted engine on any subnet/vlan available to the hypervisor where it will be running. Remove check for pingable gateway. - Do you have any specific time-line dependencies? No - List any affected packages or components. Self hosted engine - Would you be able to assist in testing this functionality if implemented? Yes - For each functional requirement listed in the previous question, can test to confirm the requirement is successfully implemented Yes
Hi Pawan, (In reply to Pawan kumar Vilayatkar from comment #0) > - What is the nature and description of the request? > Enable Self Hosted Engine deployment to different subnet from the hypervisor > > - Why do you need this? (List the business requirements here) > From a network security perspective we split hypervisors from management > software since they have different needs for inbound/outbound communication. > Also we could have a scenario where we have hypervisors on two different > network zones that are not allowed to communicate with eachother, but are > allowed to communicate with a common management zone. > One other issue with the deployment is that it requires a pingable gateway, > and that is usually not available in a firewalled environment. I don't get the security aspect here. The HE needs to communicate with the Hypervisors on the management LAN. So it needs to be in the same network as the Hypervisors. The pingable gateway itself is simply a host that is expected to be available all the time and if it is not, then the network is broken. So even in a firewalled environment, you have at least the firewall interface that is pingable (or at least could be configured this way). So the only piece remaining is the RHV-M Web-UI (https/port 443) and (if used) the central authentication (AD or LDAP). Both could be configured via a second interface that is added to hosted engine after install. With the appropriate firewall rules you could then separate this traffic. From a security point of view, I believe this is more "dangerous" than having a firewall controlled access to https port (incoming) and central authentication if needed (outgoing). As such I do not understand the reasoning behind moving the management to a different zone. Could you please elaborate a bit more on why this is needed? Thanks! Martin
moving to HE deployment
BZ<2>Jira Resync