Disclaimer: this is not something for production environments (at least, I hope for your sake, GSS should be able to fix it), but more for test or homelab environments.
Say your vCenter is broken. And I mean really really broken to the point where you can’t get the services to run anymore and you either go through a VMware GSS case and hope they can fix it. I’m good at breaking things and somehow (don’t ask) got to a point where I had broken the SSO and Inventory services and couldn’t get them back up.
I’m not a fan of putting in a GSS ticket for my home lab (even though those guys would even help!), so I had 2 options; restore vCenter from a backup or deploy a new appliance. I soon realised I hadn’t put the vCenter VM in my backup job (<insert failwhale here>) so had to resort to deploying a new one. In small environments with no automation/orchestration systems attached, this is not that big of a deal – there are not that many configuration options inside vCenter which you need to recreate. The logical objects (datacenter, cluster, folders) and the placing of your ESXi hosts and VMs in those logical objects and the rest of the important configuration (VMs, ESXi settings) will be preserved on the ESXi hosts. There’s one thing that’s a bit more work; the vSphere Distributed (VDS).
The configuration for the VDS exists inside the vCenter and cannot be fully exported from the ESXi hosts, for as far as I can tell (please enlighten me if you do know a way!). You can view the basics, like which VMs are attached to which portgroups, but not an overview of all VDS portgroups and their settings. To be able to recreate the VDS on a new vCenter, you need at least an overview of all portgroups and the VLAN IDs.
Important Note: It’s going to take a bit more when you’re using VXLAN (with for example NSX). The VXLAN portgroups will be have to be created from the NSX Manager and this probably won’t be as seamless as regular portgroups.
Anyway, I started poking around inside the vCenter Appliance for the VDS configuration. Couldn’t find it in regular files, so I resorted to the vPostgres database.
I cannot state this enough, only go into the vCenter database if VMware GSS tells you to, or if you’re working with a test environment. Things may go boom.
To get into the database, login to the vCenter Appliance via SSH (or console) and get into the bash shell by typing shell, then execute psql:
root@vcenter [ ~ ]# /opt/vmware/vpostgres/9.3/bin/psql -d VCDB postgres
root@vcenter [ ~ ]# /opt/vmware/vpostgres/9.4/bin/psql -d VCDB postgres
Once you’re in the psql prompt, execute this query:
VCDB=# SELECT p.dvportgroup_name, s.vlan_id, s.allow_promiscuous, s.forged_transmits, s.mac_changes FROM vpx_dvportgroup p, vpx_dvport_setting s WHERE s.dvportgroup_id = p.id;
dvportgroup_name | vlan_id | allow_promiscuous | forged_transmits | mac_changes
Trunk_Port | | | |
vMotion | 102 | | |
DSwitch_Prod_Int-DVUplinks-78 | | 0 | 1 | 0
Internal Management | 105 | | |
Testlab | 107 | 1 | 1 | 1
Internal VM Traffic | 109 | | |
This output lists a couple of things. I wanted an overview of all portgroups with the VLAN IDs and the security settings configured on them (I knew some had custom settings). There are a lot more settings of the portgroup you can look at. To see all options, do a \d+ vpx_dvport_setting and you’ll get the full table layout for the portgroups.
Reattach ESXi Hosts & VMs to the new VDS
When you’ve finished the configuration of the new VDS, you can reattach the ESXi hosts and VMs without downtime. Add the ESXi hosts like you would add a new ESXi host and in the wizard migrate the physical uplinks, any vmkernel nics and the VMs from the old (non-existing) VDS to the new VDS. Remember, if you leave the ESXi hosts and VMs alone, the old VDS configuration will continue to operate even if there’s no vCenter anymore (mine was broken for about 2 weeks). Just make sure that you map the VM vNICs to the proper new VDS portgroup when you add the ESXi hosts. The migration will be seamless, comparable to a vMotion.