We have to shutdown the management components of the VMware homelab in a specific order to keep components operational by maintaining the necessary infrastructure, networking, and management services prior before shutdown.
The order is as follows:
Author: Adrian Page 10 of 12
With VMware Cloud Director 10.3, the SSL certificates of the HTTP and the console proxy endpoints are not stored in a PKCS12/JCEKS formatted keystore anymore, but in PEM format only.
So the simplified process is as follows (after creating a backup of the old certificate and key files):
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j --cert /opt/vmware/vcloud-director/data/transfer/user.http.pem --key /opt/vmware/vcloud-director/data/transfer/user.http.key
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -p --cert /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem --key /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.keyAfterwards the cell must be restarted, e.g. using service vmware-vcd restart. The procedure must be performed on all available cells in a cell group.
To customize the VMware Cloud Director URLs we must also edit the Web Portal endpoints in the Service Provider Admin Portal under Administration > Settings > Public Addresses.
There we enter our VMware Cloud Director public URL for HTTPS (secure) connections and click Replace Certificate File to upload the certificates that establish the trust chain for that endpoint. The certificate chain must match the certificate used by the service endpoint, which is the certificate we’ve uploaded to each VMware Cloud Director cell before.
Pro tip: The key must be provided in a separate file, not included in the certificate PEM file. The certificate file must have the following schema:
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: DomainName.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: CA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----
VMware vRealize Suite is a purpose-built management solution for the heterogeneous data center and the hybrid cloud. It delivers and manages infrastructure and applications to increase the business agility while maintaining IT control. It provides the most comprehensive management stack for private and public clouds, multiple hypervisors, and physical infrastructure.
It consists of the following solutions:
- vRealize Automation (and vRealize Orchestrator)
- vRealize Operations
- vRealize Log Insight
To automate installation, configuration, upgrade, patch, configuration management, drift remediation and health from within a single pane of glass, we will use vRealize Suite Lifecycle Manager.
The below diagram shows technological capabilities and organizational constructs.
In the lab environment we’ll install all solutions as single node instances with the following sizings:
| Name | Purpose | Size | vCPU | Memory (GB) | Disk (GB) |
| vrslcm1 | Lifecycle Manager | – | 2 | 6 | 78 |
| wsa1a | vIDM | Medium | 8 | 16 | 60 |
| vra1a | vRealize Automation | Medium | 12 | 42 | 236 |
| vrops1a | vRealize Operations | Extra small | 2 | 8 | 274 |
| vrli1a | vRealize Log Insight | Small | 4 | 8 | 530 |
After the deployment of these solutions, we’re going to initially integrate them.
With VMware VMware Cloud Director you can build secure, multi-tenant clouds by pooling virtual infrastructure resources into virtual data centers and exposing them to users through Web-based portals and programmatic interfaces as a fully automated, catalog-based service.
In the lab environment, we’ll setup a simple single cell installation, and add our workload vCenter Server vc2.lab.local and the NSX-T Manager nsx1.lab.local as infrastructure resources.
From these infrastructures we’ll create cloud resources such as a provider VDC, a Geneve network pool, and an External network.
Then we’ll create a tenant organization and assign resources from the provider VDC as an organization VDC to this particular organization. We’ll also create an Edge Gateway to allow the tenant to access the outside world from within his Cloud.
In this lab session, I want to transform my workload cluster into a “native Kubernetes platform” by using vSphere with Tanzu.
VMware Tanzu is a portfolio of products and solutions which allow its customers to build, run, and manage Kubernetes controlled container-based applications.
In the Operations (or Run) catalog depicted above, VMware has different implementations for Tanzu Kubernetes Grid, all of which provision and manage the lifecycle of Tanzu Kubernetes clusters on multiple platforms. It consists of the following options:
- vSphere with Tanzu: Also known as Tanzu Kubernetes Grid Service (TKGS). Runs Kubernetes workloads natively in vSphere and enables self-provisioning of Tanzu Kubernetes clusters running on vSphere with Tanzu.
- Tanzu Kubernetes Grid (TKG): TKG is a standalone offering whose origins come from VMware’s acquisition of Heptio and is installed as a management cluster, which is a Kubernetes cluster itself, that deploys and operates the Tanzu Kubernetes clusters. These Tanzu Kubernetes clusters are the workload Kubernetes clusters on which the actual workload is deployed.
- Tanzu Kubernetes Grid Integrated (TKGI): TKGi’s origins come from VMware’s acquisition of and joint development efforts with Pivotal. TKGI (formerly known as VMware Enterprise PKS) is a Kubernetes-based container solution with advanced networking, a private container registry, and life cycle management. TKGI provisions and manages Kubernetes clusters with the TKGI control plane, which consists of BOSH and Ops Manager.
In this session, we’ll cover vSphere with Tanzu.