VMware Cloud director 10.2 is there

VMware Cloud Director 10.2 is there! This is a big release and a big step forward.

I played already with Cloud Director 10.2 for a while and this is a big release with lots of improvements:

  • NSX-T integration: The NSX-T integration was significantly improved so that NSX-V and NSX-T reached feature parity! One of my personal highlights are the support of VRF´s and the AVI load integration
  • Support of vSphere with Tanzu in Cloud Director: VMware Cloud Director supports as of now vSphere with Tanzu integration. It is possible to enable self-service creation of TKG clusters and management out of VMware Cloud Director 10.2

Please stay tuned, I will publish a series of blog posts on the integration of vSphere with Tanzu in VMware Cloud Director very soon!

For your reference:

Update vSphere 6.x in a VMware Cloud Director environment to vSphere 7

With VMware Cloud Director 10.1.1 VMware introduced support for NSX-T 3.0 and vSphere7.
Motivated by the new supported version I considered to update my lab from vSphere 6.7 U3 and NSX-V to vSphere 7.
After studying the Interoperability matrix, I noticed that vSphere 7 does not support NSX-V. As a consequence, you cannot directly upgrade from vSphere 6.7 and NSX-V to vSphere 7 and NSX-T. In the follwoing I want to high level describe how to update a VCD and vSphere 6.7 environment with NSX-V to vSphere 7.

Interoperability checks

If you would like to update an environment from vSphere 6.x and NSX-V to vSphere 7 in combination with VMware Cloud Director 10.1.1. First of all, you have to ensure that your planned version are compatible with each other. Therefore, you have to check the VMware interoperability matrix very carefully. You will notice that vSphere 7 does not support NSX-V.

See: https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&1=3495&661=4249&175=&hideUnsupported=false

As a consequence, you cannot upgrade directly from vSphere 6.7 U3 to vSphere 7 in a VCD environment using NSX-V. Therefore, you have to check the vSphere 6.x compatibility with NSX-T:

How to upgrade from vSphere 6.7 U3 and NSX-V to vSphere 7

As mentioned above, you cannot upgrade directly from vSphere 6.7 U3 and NSX-V to vSphere 7 in a VMware Cloud Director environment. Therefore, I recommend the following method:

  • Check the Interoperability matrix if NSX-T 3.0 is supported by your vSphere/ESXi version
  • If necessary, update vSphere/ESXi to a version supported by NSX-T 3.0
  • Install and configure NSX-T 3.0
  • Add the vCenter server that you want to migrate to vSphere 7 as Compute Manager in NSX-T (This is very important because the NSX-V to NSX-T migration tool can only migrate VM/vApps within the same vCenter server! See https://fojta.wordpress.com/2020/04/15/how-to-migrate-vcloud-director-from-nsx-v-to-nsx-t/)
  • Migrate VMs from NSX-V to NSX-T
  • Upgrade vSphere/ESXi

I highly recommend to have a look at Tom Fojita´s great blog post „How to Migrate VMware Cloud Director from NSX-V to NSX-T„!


You cannot upgrade in a VMware Cloud Director environment with vSphere 6.x and NSX-V directly to vSphere 7. You have to migrate from NSX-V to NSX-T first and vSphere/ESXi afterwards.


Usage Meter 4.2 is there

We just released Usage Meter 4.2 with some exciting new features:

Usage Meter 4.2 now supports the metering

  • VMware Cloud Foundation
  • NSX-T Data Center
  • vRealize Network Insight 
  • vCloud Availability 3.0.x and vCloud Availability 3.5.x
  • vCloud Director 9.5.x, vCloud Director 9.7.x, vCloud Director 10.0.x, and VMware Cloud Director 10.1
  • Horizon Desktop as a Service 9.0

For more details see: https://docs.vmware.com/en/vCloud-Usage-Meter/4.2/rn/VMware-vCloud-Usage-Meter-42-Release-Notes.html

CSE as a Service with encrypted configuration files

Disclaimer: All changes that you might do are your own responsibility! Please backup your configuration files before changing them. I am not liable for any damages you might create following this blog post!

I do not describe the installation of CSE in detail. For a detailed describtion how to install CSE on RedHat Enterprise Linux or similar Linux systems, see: http://www.virtualizationteam.com/cloud/vmware-container-service-extension-2-6-1-installation-step-by-step.html.

With CSE2.6 an encryption of configuration files was introduced to protect confidential information like RabbitMQ, vCenter and VMware Cloud director password.

If you want to execute the Container Service extension as a Service you need to ensure the highest level of security possible, particularly in production, so let´s start at the beginning :wink:

The CSE configuration file

You should not leave any configuration information not encrypted, otherwise your server maybe more openly accessibly .

See below an example of a config.yaml.

  exchange: cse-ext
  host: amqp.vmware.com
  password: guest
  port: 5672
  prefix: vcd
  routing_key: cse
  ssl: false
  ssl_accept_all: false
  username: guest
  vhost: /

  api_version: '33.0'
  host: vcd.vmware.com
  log: true
  password: MySecretPassword
  port: 443
  username: administrator
  verify: true

- name: vc1
  password: MySecretPassword
  username: cse_user@vsphere.local
  verify: true
- name: vc2
  password: MySecretPassword
  username: cse_user@vsphere.local
  verify: true

  enforce_authorization: false
  listeners: 10
  log_wire: false
    enable: true

  catalog: cse
  default_template_name: my_template
  default_template_revision: 0
  ip_allocation_mode: pool
  network: mynetwork
  org: myorg
  remote_template_cookbook_url: https://raw.githubusercontent.com/vmware/container-service-extension-templates/master/template.yaml
  storage_profile: '*'
  vdc: myorgvdc

By default CSE expects an encrypted config.yaml unless you use –skip-config-decryption.

To encrypt a config file use:

cse encrypt config.yaml --output encrypted-config.yaml

During the encryption of the file you are asked to define a password. This password is needed whenever you are using the configuration file.

You have to keep in mind that CSE does not have an internal possibility to store information like connections, credentials for needed connections or even for a state.

This means that CSE is completely stateless, with all advantages and disadvantages. One of the advantages is that you can redeploy CSE on any server as long as CSE is installed and you have the configuration file. One of the disadvantages is that you need to provide the configuration file and the password during startup of the service. This means you have to find a way to provide the password during the boot time.

To start CSE you will be prompted during the startup of the service to provide the password for the encrypted configuration file:

In a real world installation of CSE you do not want to start CSE manually, whenever your server reboots or during startup of a server. Therefore you need to have a systemd unit file to automatically start CSE. If you followed my post carefully, you might have an idea what the challenge might be: You have to provide a password during the boot time of the server.
You have to provide the password during boot time of the server in an environment variable $CSE_CONFIG_PASSWORD.
There are two ways to declare this variable:

  • in the init script
  • in an environment script referenced in the startup script
  • directly defined in the systemd unit file

Excursion: Systemd unit file

To understand how to define the variable it is useful to understand the structure of a systemd unit file. For more detail see: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

The init script contains of several sections. I will just explain section relevant for CSE that are the absolute basis:

  • Unit
  • Service

The Unit section looks like follows:

Description=Container Service Extension for VMware vCloud Director

In the Unit section you describe the service itself as well as dependencies that need to be fulfilled to start your service successfully.
Wants means that the network service is a soft requirement meaning that the network service should be started but the init script will be executed even if the service was not started successfully.
After means that the service will be started after the network service was started.

The Service section looks like follows:

[Environment=CSE_CONFIG_PASSWORD='mysecretpassword'] optional
[EnvironmentFile=/path/to/file] optional

In the section service you define the startup of the service like which executable should be started, which user to use for the startup of the service and which WorkingDirectory.
In our example of CSE,you will execute a shell script to start CSE.
ExecStart defines the executable which to use and how to call the executable.
User defines the user under which the service will be started.
WorkingDirectory defines which directory to use to store temporary information like log files.
EnviromentFile defines a file, in which you can set the environment that is used when the service is started.
Environment defines variables that are available during execution of the script. In our usecase you need either Environment, EnvironmentFile or none of them.

Define the variable in the init script

You can define CSE_CONFIG_PASSWORD directly in the shell script that is called to start CSE. You have to add export CSE_CONFIG_PASSWORD=’mysecretpassword‘ to the shell script like:

export CSE_CONFIG_PASSWORD='mysecretpassword'
/home/stefan/.local/bin/cse run -c /home/stefan/encrypted-config.yaml

To ensure that that only and only the service user has read/write and execute permission ont the file because you have to store the password in clear text!

The environment variable is just valid for the time of execution and cannot be read by other users than the service user and root if somebody has unauthorized root access, you have another problem.

Define CSE_CONFIG_PASSWORD in the environment script

To define the config in the init script, you need to add EnvironmentFile=/path/to/file to the cse.service systemd unit file.
A systemd unit file could look like follows:

Description=Container Service Extension for VMware vCloud Director



Please be aware if the EnvironemntFile is not available during execution of the script, your script will fail and CSe will not start.
The environment file is quite easy:


You have to ensure that that only and only the service user has read/write and execute permission on the file because you have to store the password in clear text!

Definition in systemd unit file

To define the environment variable in the systemd unit file you just have to add Environment=CSE_CONFIG_PASSWORD='Mysecretpassword' to the systemd unit file that defines the CSE startup.
You can find several examples of the unit file above.

You have to ensure that that only and only the service user has read/write and execute permission on the file because you have to store the password in clear text!


During the creation of this Blog entry I used several sources, that might be interested for further reading:

Systemd unifiles: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
systemd environments: https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html
CSE documentation: https://vmware.github.io/container-service-extension/INSTALLATION.html

And many discussion with colleagues like Eiad Al-Aqqad (see http://www.virtualizationteam.com/about)

Let´s get started

We are working on a daily basis on so many topics that would be interesting for a broader audience. Therefore, I thought that it would be a great idea to start a blog.

So stay tuned, there will be a lot of interesting material posted in the next days.