With VIO 2.0 I added a second cluster using this technique:
This cluster has its own dvSwitch (not NSX).
How do I add networks to the second dvSwitch? Each time I add a Network, it gets added to the original dvSwitch.
I have tried setting "Physical Network" to various things.
VMware Integrated OpenStack Archives - OpenStack Blog for VMware - VMware Blogs
Currently the vds plugin supports one dvswitch across multiple clusters. Could you please mention any reason why you'd like to use different dvswitches for each cluster and not span the same dvswitch across the clusters?
Oh... so, do we support more than one vCenter server? Or does there need to be one VIO 2.0 implementation for each vCenter server?
There needs to be one VIO 2.0 deployment for each vCenter. It is however possible to have each of the (1 VIO 2.0 + 1 vCenter) deployment as multiple regions accessed through a common horizon interface and keystone can be configured on each of these so that they authenticate against the same backend. However, each vcenter will need a VIO 2.0 deployment.
Could you please describe your requirements and setup a little bit more?
A pretty normal use case would be 2, or 3, or 4 vCenter Servers, plus access to AWS. I am having trouble finding blog or collateral to assist me building this.
"It is however possible to have each of the (1 VIO 2.0 + 1 vCenter) deployment as multiple regions accessed through a common horizon interface ..."
Can someone point me towards some documentation on how to do this?
Thanks
We have two ways to support multiple regions.
The easier way is to configure horizon to manage multiple regions and each region has its only keystone service. To manage more regions in this case, you can click VIO UI->Manage->Horizon Region, where you can add keystone service internal endpoints for other regions. Please note the 1st VIO's horizon must be able to ping these added keystone endpoints directly. For this way, users need to relogin from horizon when they switch between different regions.
The second way is to configure other regions to use the same keystone as 1st VIO, so users will use the same keystone to do authentication among these regions(thus the keystone service has more access pressure than the first way and scale might be an issue), and no need to relogin when they swtich between different regions. If this is the way you prefer to go now, we can send some documentation to you as that involves many steps of changes, and maybe would be better to work with you and your team for this way.
Would like to know your opinions and feedback here.
Regards,
Jun
I sort of assumed option 2... I don't see much pressure on the Keystone server of a handful of users... maybe 100, authenticating occassionaly.
However, if it is hard to get working, happy to try option 1 instead.
Sure. after you try option 1, and in case find you still need option 2, we will see how to send the steps of configuration change to your team later.