Description of problem: ----------------------- RHHI-V recommends customers to make use of frontend network for ovirtmgmt and backend network for gluster traffic. When a host is added to virt cluster with the FQDN/IP, then ovirtmgmt bridge will be created on the corresponding network interface. In RHHI-V case, the host is added to the virt+gluster cluster, then ovirtmgmt is created on that corresponding NIC, and also the peer probe will initiated on that particular network address. There should be proper solution to take care of this issue Version-Release number of selected component (if applicable): -------------------------------------------------------------- RHHI-V 1.5 RHV 4.2.7 How reproducible: ------------------ Always Steps to Reproduce: -------------------- 1. Create a virt+gluster cluster (hc) 2. Add a host with 2 IPs, in to the cluster using IP1 Actual results: --------------- ovirtmgmt bridge is created on network interface corresponding to IP1, and also peer probe will be initiated with the same IP Expected results: ----------------- ovirtmgmt should be created with IP1 Peer probe should happen with IP2 Only when there is one IP up, ovirtmgmt & gluster network can be the one and the same Additional info:
(In reply to SATHEESARAN from comment #0) > Description of problem: > ----------------------- > RHHI-V recommends customers to make use of frontend network for ovirtmgmt > and backend network for gluster traffic. > > When a host is added to virt cluster with the FQDN/IP, then ovirtmgmt bridge > will be created on the corresponding network interface. > > In RHHI-V case, the host is added to the virt+gluster cluster, then > ovirtmgmt is created on that corresponding NIC, and also the peer probe will > initiated on that particular network address. > > There should be proper solution to take care of this issue > > Version-Release number of selected component (if applicable): > -------------------------------------------------------------- > RHHI-V 1.5 > RHV 4.2.7 > > How reproducible: > ------------------ > Always > > Steps to Reproduce: > -------------------- > 1. Create a virt+gluster cluster (hc) > 2. Add a host with 2 IPs, in to the cluster using IP1 > > Actual results: > --------------- > ovirtmgmt bridge is created on network interface corresponding to IP1, and > also peer probe will be initiated with the same IP > > Expected results: > ----------------- > ovirtmgmt should be created with IP1 > Peer probe should happen with IP2 > > Only when there is one IP up, ovirtmgmt & gluster network can be the one and > the same > > > Additional info: When the additional NIC (i.e IP2) is associated with the gluster network, then the gluster cluster is also peer probed with IP2. For the data separation, bricks need to be associated with IP2, the peer probe is not the issue. Did you try this out?
Sas, could you respond to the question?
Have we added this to pre-checks? If so, can you update the tracker with this bug?
(In reply to Sahina Bose from comment #1) > When the additional NIC (i.e IP2) is associated with the gluster network, > then the gluster cluster is also peer probed with IP2. > For the data separation, bricks need to be associated with IP2, the peer > probe is not the issue. > Did you try this out? Problem here is that when someone adds the host with gluster IPs, then the ovirtmgmt bridge is created on that network interface. ovirtmgmt is used by VMs.
(In reply to SATHEESARAN from comment #4) > (In reply to Sahina Bose from comment #1) > > When the additional NIC (i.e IP2) is associated with the gluster network, > > then the gluster cluster is also peer probed with IP2. > > For the data separation, bricks need to be associated with IP2, the peer > > probe is not the issue. > > Did you try this out? > > Problem here is that when someone adds the host with gluster IPs, then the > ovirtmgmt > bridge is created on that network interface. ovirtmgmt is used by VMs. SO, do you mean a check to ensure that the FQDN used to add host to engine is not equal to the one used to create gluster cluster?
Closing. Please re-open with requested information if this needs to be taken up
(In reply to Sahina Bose from comment #6) > Closing. Please re-open with requested information if this needs to be taken > up I feel better option here is, when adding a host to the HC cluster, there should be an option for backend/gluster/Storage FQDN and host FQDN. Gluster peer management should happen using Storage FQDN and host FQDN should be used for ovirtmgmt. I will further discuss this with Gobinda and team, will raise suitable bz with listed scenarios