Uncategorized – Page 50

Quick Tip - Automate JVM Heap configurations after increasing VCSA memory

01.12.2015 by William Lam // 1 Comment

If you are using the VCSA (vCenter Server Appliance) and you wish to increase the VM memory settings to one of the three supported memory configurations: 8-16GB, 24GB & 32GB, there is on additional configuration change before the new memory configuration can take effect. This change is adjusting the JVM Heap memory settings for the following vCenter Server Services: vSphere Web Client, Inventory Service and SPS (vSphere Profile-Driven Storage). If you would like to do this from the UI, you can access the VCSA's VAMI interface and under vCenter Server->Services tab, there is a "Inventory Size" toggle that you will need to set based on your VCSA's configured memory. Once you have save the settings, you will need to restart the vCenter Server for the changes to take effect.

Note: The text in the VAMI states that the appliance requires at least 16GB of RAM for a Medium configuration which is actually incorrect, it should actually say 24GB for Medium configuration. The correct supported VCSA memory configuration maximum can be found here.

The UI is great but what if you wish to automate this change? This is especially handy if you have already automated the memory increase for the VCSA itself. Luckily, we can turn to our handy vpxd_servicefg command which supports modifying the JVM Memory based on the three supported vSphere Inventory Sizes. Below is the chart with the respective Inventory Size and command to issue within the VCSA. The parameters reflect the JVM Heap configurations for the vSphere Web Client, Inventory Service and SPS (vSphere Profile-Driven Storage).

Inventory Size	VCSA Memory	Command
Small	8-16GB	/usr/sbin/vpxd_servicecfg 'jvm-max-heap' 'write' '512' '3072' '1024'
Medium	24GB	/usr/sbin/vpxd_servicecfg 'jvm-max-heap' 'write' '512' '6144' '2048'
Large	32GB	/usr/sbin/vpxd_servicecfg 'jvm-max-heap' 'write' '1024' '12288' '4096'

Once the command has successfully completed, you can refresh the VCSA VAMI interface and you should see the appropriate size has been configured. For the changes to take effect, you will need to restart the vCenter Service by issuing one of the following commands:

/usr/sbin/vpxd_servicecfg service restart

/etc/init.d/vmware-vpxd restart

Automate forwarding of vRealize Operations Manager logs to Syslog Server

01.06.2015 by William Lam // 3 Comments

Forwarding logs to a syslog server from vRealize Operations Manager has been greatly simplified with the latest 6.0 release. Instead of having to manually tweak syslog-ng.conf with past releases, there is now a new UI option under Administration->Support->Logs which allows you to easily configure syslog configurations. There are currently 4 loggers (Analytics, Collector, Web & SuiteAPI) that can be configured to be forwarded to a syslog server.

To configure using the vROps UI, you select the root logger folder and then click on the gears icon at the top. From here, you can configure the syslog server as well as the syslog port.

Though this is a nice UI enhancement, it would have been really nice to have been able to configure this using an API. In doing some digging, I found that you could still automate the syslog configurations by simply adding a couple of lines into the respective log4j.properties files:

vROps Logger	Configuration File
Analytics	/usr/lib/vmware-vcops/user/conf/analytics/log4j.properties
Collector	/usr/lib/vmware-vcops/user/conf/collector/log4j.properties
Web	/usr/lib/vmware-vcops/user/conf/web/log4j.properties
SuiteAPI	/usr/lib/vmware-vcops/tomcat-enterprise/webapps/suite-api/WEB-INF/log4j.properties

Here is a simple shell script called configurevROpsSyslog.sh that you can run against your vROps instance to forward your logs. There are two variables SYSLOG_SERVER and SYSLOG_SERVER_PORT that will need to be updated before running the script. Here is an example of running the script that can come in handy to forwarding your logs to your favorite syslog server such as vRealize Operations Insight.

UPDATE (01/17/15) - Thanks to Steve Flanders for letting me know there is one additional location for configuring syslog which is the Audit logs located in under Administration->Audit. It looks like the configuration also goes into the Collector log4j.properties and I have updated my script to ensure this is also configured as part of the script.

Automating Active Directory Identity Source & Default Domain in vSphere Web Client

01.05.2015 by William Lam // 4 Comments

Over the holiday break I learned about two awesome tidbits from my buddies Blair Fritz and Frank Buechsel who both work over in our GSS Organization. The first tidbit came from Blair who recently shared a newly published VMware KB 2063424 that provides both a Windows and Linux script to automate the setup of your Active Directory as an Identity Source within vSphere SSO. The reason this is so cool is that you no longer have to perform this additional manual step using the vSphere Web Client just to be able to start using your Active Directory as a source for authorization within your vSphere environment. In my opinion, this step should just happen automatically if your vCenter Server (applies to both VC for Windows and VCSA) is already joined to an Active Directory Domain.

UPDATE (01/15/19) - For vSphere 6.5 and 6.7, please refer to VMware KB 67304 for the updated package required to automate this configuration

Looking at the contents of the script, I have extracted the main parts of the script to create a quick snippet that can easily be integrated into my existing VCSA 5.5 Configuration script if you are interested in automating this particular configuration.

AD_DOMAIN=primp-industries.com
EXPORTED_SSO_PROPERTIES=/usr/lib/vmware-upgrade/sso/exported_sso.properties

if [ -e ${EXPORTED_SSO_PROPERTIES} ] ;then
	rm -f  ${EXPORTED_SSO_PROPERTIES}
fi

cat > ${EXPORTED_SSO_PROPERTIES} << __SSO_EXPORT_CONF__
ExternalIdentitySource.${AD_DOMAIN}.name=${AD_DOMAIN}
ExternalIdentitySource.${AD_DOMAIN}.type=0
ExternalIdentitySourcesDomainNames=${AD_DOMAIN}
__SSO_EXPORT_CONF__

/usr/lib/vmware-upgrade/sso/sso_import.sh > /dev/null 2>&1
rm -rf ${EXPORTED_SSO_PROPERTIES}

The next tidbit that I learned the same day came from Frank. It was in regards to configuring the default Identity Source for vSphere SSO which includes localos, vsphere.local and if you have Active Directory configure, your AD Domain is an option as seen in the screenshot below. For a fresh installation, the "localos" Domain is always the default and I was interested in configuring my AD Domain as the default. It turns out this is also possible to automate and more details can be found in this handy VMware KB 2070433.

Similar to the other KB, I have created a quick snippet which can be integrated into my existing VCSA 5.5 Configuration script if you are also interested in automating this configuration.

AD_DOMAIN=primp-industries.com
SSO_ADMINISTRATOR_PASSWORD=vmware
SSO_LDIF_CONF=/tmp/defaultdomain.ldif
                
cat > ${SSO_LDIF_CONF} << __DEFAULT_SSO_DOMAIN__
dn: cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local
changetype: modify
replace: vmwSTSDefaultIdentityProvider
vmwSTSDefaultIdentityProvider: ${AD_DOMAIN}
__DEFAULT_SSO_DOMAIN__

ldapmodify -f ${SSO_LDIF_CONF} -h localhost -p 11711 -D "cn=Administrator,cn=Users,dc=vsphere,dc=local" -w ${SSO_ADMINISTRATOR_PASSWORD}

I was quite happy to learn about these two tips as these are literally the two last configurations that I have not been able to automate since the vSphere SSO Admins APIs are currently private. I will be updating my VCSA Configuration Script in the next few days to include these additional configurations and will publish an updated script once it is complete. A big thanks goes to both Blair and Frank for sharing this awesome information!