You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We have multiple vSAN clusters in different sites. Networking is different in each of them but they are reachable via L3 routing.
We can not create a scenario in which we could test vSAN cluster in each site one by one using single instance of HCIbench because use of your tool is limited to LAN only - there is no possibility to set a gateway in VMs via GUI setup. So, in each case in order to test different vSAN clusters we need to deploy HCIBench over and over again. This is inconvenient.
Describe the solution you'd like
Organizations can have more than one vSAN cluster. We have 3. Others could have more. We think that you concept of Linux networking is limited to usage of LAN only. Everyone who have more than one cluster needs different approach. As you use Linux everywhere (controller + VMs) and Linux is good at networking there should not be a problem to use a gateway inside controller and testing VMs to solve a networking problem we face. The fact is that Linux needs only one interface with gateway to reach outside world. So in HCIbench case controller and VMs could have one interface with L3 routing enabled to reach each other and they can be in completely different sites. If VMs would have gateway then controller could reach them via L3 routing. That way we can do single setup of HCIbench tool and we can use it to test current and future vSAN deployments from one place.
In short, we request you to employ L3 routing in order HCIbench to reach VMs in different vSAN clusters (locations). We strongly think that single HCIbench controller should be enough for our organization to test all our vSAN clusters. We know that VMware API can set gateway for Guest VM networking interface.
Describe alternatives you've considered
None.
Additional context
None.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We have multiple vSAN clusters in different sites. Networking is different in each of them but they are reachable via L3 routing.
We can not create a scenario in which we could test vSAN cluster in each site one by one using single instance of HCIbench because use of your tool is limited to LAN only - there is no possibility to set a gateway in VMs via GUI setup. So, in each case in order to test different vSAN clusters we need to deploy HCIBench over and over again. This is inconvenient.
Describe the solution you'd like
Organizations can have more than one vSAN cluster. We have 3. Others could have more. We think that you concept of Linux networking is limited to usage of LAN only. Everyone who have more than one cluster needs different approach. As you use Linux everywhere (controller + VMs) and Linux is good at networking there should not be a problem to use a gateway inside controller and testing VMs to solve a networking problem we face. The fact is that Linux needs only one interface with gateway to reach outside world. So in HCIbench case controller and VMs could have one interface with L3 routing enabled to reach each other and they can be in completely different sites. If VMs would have gateway then controller could reach them via L3 routing. That way we can do single setup of HCIbench tool and we can use it to test current and future vSAN deployments from one place.
In short, we request you to employ L3 routing in order HCIbench to reach VMs in different vSAN clusters (locations). We strongly think that single HCIbench controller should be enough for our organization to test all our vSAN clusters. We know that VMware API can set gateway for Guest VM networking interface.
Describe alternatives you've considered
None.
Additional context
None.
The text was updated successfully, but these errors were encountered: