• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • Nested Virtualization
  • VCSA
  • VSAN

vpxd_servicecfg

Increasing disk capacity simplified with VCSA 6.0 using LVM autogrow

02/10/2015 by William Lam 19 Comments

With previous releases of the VCSA, increasing disk capacity was not a very straight forward process. Even though you could easily increase the size of the underlying VMDK while the VCSA was running, increasing the guestOS filesystem was not as seamless. In fact, the process was to add a new VMDK, format it and then copy the contents from the old disk to the new disk as detailed in VMware KB 2056764. This meant with previous releases of VCSX 5.x, you would need to incur downtime of your environment and it could be also be quite significant depending on your familiarity with the steps mentioned in the KB not to mention the time it took to copy the data.

UPDATE (12/06/16) - For VCSA 6.5 deployments, please refer to the article here as the instructions have changed since VCSA 6.0.

The reason for this unnecessary complexity is that VCSA did not take advantage of a Logical Volume Manager (LVM) for managing its disks. In VCSA 6.0, LVM is now used to make it extremely easy to increase disk capacity while the VCSA is running. VCSA 6.0 further simplifies this by separating out the various functions into their own disk partitions comprised of 11 VMDKs compared to the monolithic design in previous VCSA releases. This not only allows you to increase capacity for specific a partition but you can also now attach specific storage SLA's using VM Storage Policies on specific VMDKs such as the Database or Log VMDK for example.

In the example below, I will walk through the process of increasing the DB VMDK from the existing 10GB to 20GB while the vCenter Server is still running.

Step 1 - Verify the existing disk capacity using "df -h"

increase-vmdk-in vcsa-01
Step 2 - Increase the capacity on VMDK 6 which represents the DB partition using the vSphere Web/C# Client.

Step 3 - Once the VMDK has been increased, you will need to run the following command in the VCSA which will automatically expand any Logical Volumes that have had their Physical Volumes increased:

vpxd_servicecfg storage lvm autogrow

increase-vmdk-in vcsa-02
Step 4 - Confirm the newly added capacity has been consumed

increase-vmdk-in vcsa-03
If you would like to learn more about the different VMDK structure in the new VCSA 6.0, I will be sharing more details in a future article.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA, vSphere 6.0 Tagged With: autogrow, lvm, vcsa, vcva, vpxd_servicecfg, vSphere 6.0

Completely automating vCenter Server Appliance (VCSA) 5.5 Configurations

01/15/2015 by William Lam 8 Comments

As promised, here is a new script called configureVCSA55.sh that I have put together after learning about a couple new VCSA automation tips here and here. This script will fully automate the configuration of a vCenter Server Appliance (VCSA) 5.5 and once the script has completed, you will have a fully functional vCenter Server Appliance. There are several variables at the top of the script that you will want to edit prior to running the script.

Here is a summary of the high level operations the script is performing and not all operations will be performed, it will depend on the variables that you have configured.

  • Accept EULA
  • vSphere Inventory Size Configuration
  • Active Directory Configuration (optional)
  • DNS Search Domain Configuration
  • NTP Configuration
  • vCenter Server Database Configuration
  • vSphere SSO Configuration
  • vSphere SSO Identity Source Configuration for Active Directory (optional)
  • Active Directory default Identity Source Configuration (optional)
  • VMware Telemtry Configuration (optional)

To run the script, you can either SCP the script to a newly deployed VCSA and run it locally in the shell or remotely via SSH using the following command:

ssh [email protected][VC-IP] < configureVCSA55.sh

completely-automate-configuration-vcsa55.0
I almost never go through a manual configuration of the VCSA anymore (since 5.0) as it just takes way too long! Hopefully you will find this script handy when needing to quickly test something or automating the deployment of a few dozen VCSA which I know of a few customers that are doing on a regular basis 🙂

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA, vSphere 5.5 Tagged With: vcsa, vcva, vpxd_servicecfg, vSphere 5.5

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.

increase_memory_on_vcsa
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

or

/etc/init.d/vmware-vpxd restart

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA Tagged With: jvm heap, vcsa, vcva, vpxd_servicecfg

Automating VCSA 5.5 Configurations including SSO Administrator password

11/03/2014 by William Lam 3 Comments

As many of you know, I am a huge fan of the VCSA (vCenter Server Appliance), not only for its ease of deployment and setup but also the fact that I can easily automate the entire deployment in just under a couple of minutes. I have written about this topic in the past using the vpxd_servicecfg command to automate both VCSA 5.0 and VCSA 5.1. I figured it was probably a good idea to update this for latest VCSA 5.5 which includes several new enhancements to vpxd_servicecfg command such as the VMware Customer Experience Improve Program configuration (vTelemtry) among other options that you can explore by simply running the vpxd_servicecfg on the VCSA.

The other reason I wanted to update this for the latest VCSA 5.5 is that I was working with Engineering last week on a project and several of them did not know about this capability of being able to automate the VCSA configuration. Instead of providing them with the raw commands, I thought I would create an updated script that can be shared with the community so that others could also benefit from it. Lastly, I also did this for myself as I deploy a large amount of VCSA for all sorts of testing that I am doing on a regular basis and this would allow me to quickly speed up my deployment by simply going to my own blog 🙂

Below is a shell script that contains several variables that can be edited based on your environment setup and you can run this script over SSH using something like: ssh [email protected][VCSA-IP] < configureVCSA.sh

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#!/bin/bash
# William Lam
# www.virtuallyghetto.com
# Script to automate VCSA 5.5+ Configurations
 
# User Configurations
 
# SSO Administrator password (administrator@vsphere.local)
SSO_ADMINISTRATOR_PASSWORD=VMware1!
 
# Join Active Directory (following 5 variables required)
JOIN_AD=0
AD_DOMAIN=primp-industries.com
AD_USER=administrator
AD_PASS=mysupersecurepassword
VCENTER_HOSTNAME=vcenter51-1.primp-industries.com
 
# Enable NTP
ENABLE_NTP=0
NTP_SERVERS=192.168.1.1
 
# Enable VMware Customer Experience Improvement Program
ENABLE_VC_TELEMTRY=1
 
################ DO NOT EDIT BEYOND HERE ################
echo "Accepting VMware EULA ..."
/usr/sbin/vpxd_servicecfg eula accept
 
if [ ${JOIN_AD} -eq 1 ]; then
        echo "Configuring vCenter Server hostname ..."
        SHORTHOSTNAME=$(echo ${VCENTER_HOSTNAME} |  cut -d. -f1)
        /bin/hostname ${VCENTER_HOSTNAME}
        echo ${VCENTER_HOSTNAME} > /etc/HOSTNAME
        sed -i "s/localhost/${SHORTHOSTNAME}/g" /etc/hosts
        echo "Configuring Active Directory ..."
        /usr/sbin/vpxd_servicecfg ad write "${AD_USER}" "${AD_PASS}" ${AD_DOMAIN}
fi
 
echo "Enbaling Time Synchronization ..."
if [ ${ENABLE_NTP} -eq 1 ]; then
/usr/sbin/vpxd_servicecfg timesync write ntp ${NTP_SERVERS}
else
/usr/sbin/vpxd_servicecfg timesync write tools
fi
 
echo "Configuring vCenter Server Embedded DB ..."
/usr/sbin/vpxd_servicecfg db write embedded
echo "Configuring vCenter Server SSO w/custom administrator@vsphere.local password ..."
/usr/sbin/vpxd_servicecfg sso write embedded ${SSO_ADMINISTRATOR_PASSWORD}
 
echo "Starting the vCenter Server Service ..."
/usr/sbin/vpxd_servicecfg service start
 
if [[ -e /var/log/vmware/phonehome ]] && [[ ${ENABLE_VC_TELEMTRY} -eq 1 ]]; then
echo "Enabling vCenter Server Telemtry ..."
/usr/sbin/vpxd_servicecfg telemetry enable
fi

 

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA, vSphere Tagged With: sso, vCenter Server, vcenter server appliance, vcsa, vcva, vpxd_servicecfg

Quick Tip – Automate the enabling of the Customer Experience Improvement Program (vTelemetry) in VCSA

09/16/2014 by William Lam 4 Comments

The VMware Customer Experience Improvement Program is a new feature that was introduced with the latest release of vCenter Server 5.5 Update 2 (vCenter Server for Windows & the VCSA). This feature provides the following per the documentation:

If you choose to participate in the Customer Experience Improvement Program (Program), VMware receives anonymous information to improve the quality, reliability, and functionality of VMware products and services. VMware wants to understand better your vSphere deployment and business needs, and improve VMware response to customer requirements. You can choose to participate in the Program for vSphere at any time.

In my opinion, this has been needed for quite some time now. If you have ever installed any consumer based software, there is usually an option that allows customers to provide basic telemetry data back to the vendor so that they can better understand how the product is being used and more importantly leverage that data to help improve the product and features future.

The process of collecting basic telemetry (sometimes also known as phone home) is not a new concept in the Enterprise. In fact, for those of you who manage a storage array, this has been a standard practice for many many years now where every night, the storage array sends back a variety of telemetry data that may include performance information, utilization, logs, etc. to the vendors HQ. This data is then analyzed and the vendor maybe able to sport trends of a potential issue and proactively alert customers to take action before a problem even arises. Michael White has also recently written about the topic here which I recommend a read as well.

There are four categories of data that is being collected:

  • esxcfg-info.xml
  • Extension.json
  • AboutInfo.json
  • performance-stats.txt

If you wish to learn more about what is being collected and how to view the data before it is sent, please take a look at the documentation here.

One thing I had noticed when deploying the latest VCSA 5.5 Update 2 is that there is now an option to enable the Customer Experience Improvement Program and of course I was interested in automating this configuration as part of my VCSA deployment script.

automate-telmetry-customer-improvement-program-0
Taking a look at the logs, I found that there is a new option that has been introduce in /usr/sbin/vpxd_servicecfg called telemtry:

Telemetry data collection modes:
read         : read and return the current status of the collector
enable       : enables the telemetry data collection
disable      : disables the telemetry data collection

To enable the Customer Experience Improvement Program as part of the VCSA setup, you must enable it after vpxd (vCenter Server) has started. Here is the modified VCSA configuration shell script:

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/bash
 
echo "Accepting EULA ..."
/usr/sbin/vpxd_servicecfg eula accept
 
echo "Configuring Embedded DB ..."
/usr/sbin/vpxd_servicecfg db write embedded
 
echo "Configuring SSO ..."
/usr/sbin/vpxd_servicecfg sso write embedded
 
echo "Starting VCSA ..."
/usr/sbin/vpxd_servicecfg service start
 
echo "Configuring VC Telemetry ..."
/usr/sbin/vpxd_servicecfg telemetry enable

If you decide not to enable this feature during the initial deployment or if you have upgraded from an existing vCenter Server, this feature can also be enabled after the fact. To do so, you will need to login to your vCenter Server using the vSphere Web Client and under the Settings tab of your vCenter Server, there is an option to enable or disable the Customer Experience Improvement Program

automate-telmetry-customer-improvement-program-1
Note: When enabling or disabling the Customer Experience Improvement Program, a restart of vCenter Server is not necessary.

Hopefully customers will see the benefit and value in joining the VMware Customer Experience Improvement Program and over time, I think you will start to see some really neat benefits for those who participate in this program.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA, vSphere Tagged With: Customer Experience Improvement Program, telemetry, vcenter server appliance, vcsa, vcva, vpxd_servicecfg

How to automate NTP configurations on the VCSA using the CLI

02/03/2014 by William Lam Leave a Comment

NTP configurations should be a mandatory setting for everyone, regardless of whether we are talking about VMware products or general infrastructure software. It is just as critical as having proper DNS configured and can cause a whole slew of issues if not configured or setup properly. A question that was raised internally a couple of days back was around automating NTP configurations on the VCSA (vCenter Server Appliance) which is normally performed through the VAMI web interface as seen in the screenshot below.

Instead of using the VAMI UI, the user was interested in automating it through the command-line and wondered if this was possible. This is definitely possible among other VAMI operations by leveraging the vpxd_servicecfg utility and there are a couple of options when configuring NTP on a VCSA 5.5 system.

The option that most of you will probably using is to configure a list of NTP servers (comma separated). To do so, you can run the following command (replace the NTP server with your own):

/usr/sbin/vpxd_servicecfg timesync write ntp '172.30.0.100' ''

This command should have a return code of 0, else there maybe an issue connecting to your time source from the VCSA. You can also confirm the operation was successful or query the current configuration by running the following command:

/usr/sbin/vpxd_servicecfg timesync read

If you wish to synchronize your time with the underlying ESXi host through VMware Tools, then you can run the following command:

/usr/sbin/vpxd_servicecfg timesync write tools '' ''

Finally, if you wish to disable time synchronization on the VCSA for whatever reason, you can do so by running this command:

/usr/sbin/vpxd_servicecfg timesync write none '' ''

Note: If the VCSA is joined to an Active Directory domain, then the time synchronization is provided by your Active Directory server and no additional configurations are required.

Once you have configured your NTP servers, you should can also manually force a sync to ensure the current date/time is correct by running the following command:

sntp -P no -r [NTP-SERVER]

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, VCSA Tagged With: ntp, vcsa, vcva, vpxd_servicecfg, vSphere 5.5

  • Page 1
  • Page 2
  • Next Page »

Primary Sidebar

Author

William Lam is a Staff Solutions Architect working in the VMware Cloud on AWS team within the Cloud Platform Business Unit (CPBU) at VMware. He focuses on Automation, Integration and Operation of the VMware Software Defined Datacenter (SDDC).

  • GitHub
  • Google+
  • LinkedIn
  • RSS
  • Twitter

Sponsors

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy