vCenter Server Issue: Recent Tasks Show xxx.label

I had an annoying issue in my lab. Some time ago when I performed vSphere 6.7 PSC convergence my vCenter would stop displaying proper names of tasks in the vSphere Clients UI (both Flex and H5) and show only their placeholders with names like xxx.label.

While there are some KB or communities articles about the issue (and fix) none of them was applicable to my situation (running vCenter Server 6.7U1). I thought that VCSA patches or even deploying new appliance with backup restore would fix it but it did not.

After a little research I found out that the issue is caused by missing catalog.zip file in the /etc/vmware-vpx/locale/ folder. I had another lab with the exactly same vCenter Server build deployed so I just copied that file and transferred it to my vCenter Server Appliance. After service restart via VAMI UI tasks names were back.

I do not know the root cause, but if you have the same issue, give it a go.

Advertisements

NSX-T 2.4: Force Local Account Login

NSX-T supports Role Based Access Control by integrating with VMware Identity Manager which provides access to 3rd party Identity Sources such as LDAP, AD, SAML2, etc.

When NSX-T version 2.3 is integrated with VIDM you would get a choice during the login which type of account you are going to provide (remote or local).

NSX-T version 2.4 no longer provides the option and will always default to the SAML source (VIDM). To force the login with local account provide this specific URL:

https://<NSX-T_FQDN/IP>/login.jsp?local=true

PostgreSQL: Beware of the bloat!

During the last weekend my vCloud Director lab died. And the reason was PostgreSQL DB filled up all the disk space. How could that happen in my small lab with one running vApp?

PostgreSQL database when updating rows actually creates new ones and does not immediately delete the (now dead) old rows. That is done in a separate process called vacuuming.

vCloud Director has one pretty busy table named activity_parameters that is continuously updated. And as you can see from the below screenshot (as reported by pgAdmin table statistics) the table size is 26 MB but it is actually taking 24 GB of hard disk space due to the dead rows.

Another quick way to check DB size via psql CLI is:

\c vcloud
SELECT pg_size_pretty (pg_total_relation_size(‘activity_parameters’));

Vacuuming takes times and therefore it can be tuned in postgresql.conf via a few parameters which VMware documents specifically for vCloud Director here or here. Make sure you apply them (I did not). Another issue that could prevent vacuuming to happen is a stale long running transaction on the table.

The fix:

• short term: add more disk space
• long term: make sure postgresql.conf is properly configured
  autovacuum = on
  track_counts = on
  autovacuum_max_workers = 3
  autovacuum_naptime = 1min
  autovacuum_vacuum_cost_limit = 2400
• manually vacuum the activity_parameters table with the following psql CLI command:
  VACUUM VERBOSE ANALYSE activity_parameters;

And do not forget to monitor free disk space on your PostgreSQL host.

 

Upgrade PostgreSQL version 9 to 10

I had to perform multiple PostgreSQL database upgrades from version 9 to version 10. The database was used for vCloud Director but I believe it is generic enough for other purposes.

The base operating systems I am using is CentOS 7.

Here follows the step-by-step procedure:

1. Create database backup:
   su – postgres
   pg_dumpall > /tmp/pg9backup
   exit
2. Shutdown and uninstall old PostgreSQL v9:
   systemctl stop postgresql-9.5.service
   yum remove postgresql*
3. Archive old datafiles (you will need them later):
   mv /var/lib/pgsql/data/ /data.old
4. Install new PostgreSQL v10:
   yum -y install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
   yum -y install postgresql10-server
   systemctl enable postgresql-10
5. Initiate and start DB:
   su – postgres
   /usr/pgsql-10/bin/initdb
   cp /data.old/pg_hba.conf /var/lib/pgsql/10/data/
   cp /data.old/postgresql.conf /var/lib/pgsql/10/data/
   exit
   systemctl start postgresql-10
   
6. Restore backup
   su – postgres
   psql -d postgres -f /tmp/pg9backup
7. Reboot server. If everything works, you can delete your pg9backup and data.old archive.

Resource Consumption of Org VDC Allocation Types

The reference table below summarizes how different vCloud Director Org VDC allocation types consume vSphere resources. In other words: how a choice of allocation model for a particular Org VDC and its parameters (allocation, guarantees, quota, vCPU speed) translate to resource pool and VM resource settings (CPU/RAM) – reservations and limits.

click for large version

Notes:

• valid for vCloud Director 9.5 and older (down to 5.5)
• RP … resource pool
• Elastic … Org VDC can be divided across multiple RPs across clusters
• Although there are currently only three Org VDC allocation types the Allocation Pool can be elastic or non-elastic based on vCloud Director instance wide setting in General Settings