vCenter Server Appliance Certificates Exchange

Today I want to talk to you about exchanging certificates. A topic often covered in blogs. In my test environment, I am using:

  1. Microsoft Windows Server 2019 as Domain Controller and as Certificate Authority
  2. VCSA 7.0 Build 16386335 (at the time of writing brand new)

I won’t write about how to configure the Microsoft CA, I will just describe how you need to proceed step by step changing certificates in VCSA.

So that is how you know it:

The website is considered not secure.

VCSA – Creating the .csr via SSH

VCSA – Transferring files, creating certificates

  1. Transfer the files
  2. Request a certificate
  3. Copy .csr
  4. Download, export, transfer back

1. Transfer the files

2. Request a certificate

3. Copy .csr

4. Download, export, transfer back

So download and export both, please.

VCSA – Continue with import via SSH

OK, finally at the end how it should look like:

Some more information regarding certificates:

Using the right shell to download files:
https://kb.vmware.com/s/article/2100508

Obtaining certificates from a Microsoft CA:
https://kb.vmware.com/s/article/2112014

Creating a Microsoft CA template:
https://kb.vmware.com/s/article/2112009

 

Wondering why you cannot login to VCSA: Failed to start File System Check on /dev/uuid

I do not know what happened today but I could no longer use my VCSA 7.0 (Build 16386292).

Started with pinging … which did not succeed. So I checked VM console:

In text:

Failed to start File System Check on /dev/uuid

Dependency failed for /sysroot.

Dependency failed for Initrd Root File System.

Dependency failed for Reload Configuration from the Real Root.

Simply do fsck /dev/sda3 and enter “a” for all or “y” for each object to fix from the console, power off (or enter reboot) and start VM:

After the reboot, you should be able to login.

Limiting vCPU’s, RAM and/or Disk sizes in Cloud Director 10.0 Part 3

After limiting and testing configuration maximums, let us see what kind of questions could come up.

1. Do I need to set the configuration limits on every cell?

The answer here is NO. I only executed the commands on cell 1 and I am now connected to cell 2:

2. Some other useful information

  • The configuration is Cloud Director or system wide
  • Existing VMs are not affected (of course!)
  • As I was working with System Administrator, it affects the Super Admin account as well
  • It is not required to restart Cloud Director or any other services

3. One thing you need to know about

  • I could create a VM with more disk space (as System Administrator), so there is no enforcement in that case

 

 

Patching your ESXi 7.x Hosts on the Command Line

Do you still remember how to patch ESXi on the command line?

  1. Download the patch from https://my.vmware.com/group/vmware/patch
  2. Save the depot on a share reachable by your hosts (in my case a NFS share)
  3. Enable SSH on your hosts and connect
  4. Put your host of choice into Maintenance Mode
  5. Execute esxcli software vib update –depot=/path/to/your/file/location/VMware-ESXi-7.0b-16324942-depot.zip
  6. Reboot host if required

See some screenshots for your reference

Starting point:

esxcli software vib update –depot=/path/to/your/file/location/VMware-ESXi-7.0b-16324942-depot.zip:

Finished:

 

Limiting vCPU’s, RAM and/or Disk sizes in Cloud Director 10.0 Part 2

In the previous post I have set some limits for vCPU, RAM, and Disk size. Now let’s check the functionality and messages.

1. Create vApp

Clicked to add Virtual Machine:

I have chosen to cross the limit for all settings:

Summary:

Results:

Task Details:

2. Create VM

Let us see if the creation of a VM produces the same results:

Well yes of course, works as expected.

If you take a closer look at the details, you may ask yourself “Why do I see Type: vapp in there?”. If you click on your vApps menu, you will see there has no object been created, but at the end we use the same template for the details.

Let us shortly continue with a summary in part 3 here.

Limiting vCPU’s, RAM and/or Disk sizes in Cloud Director 10.0 Part 1

Recently, I was working with a VMware partner to implement Cloud Director for their end customer. They are on vSphere 6.7 and use NSX-T 2.5 together with vCloud Director 10.0. The three vCD cells we implemented are based on our appliance.

The question of the end customer came up if it is possible to restrict the workloads in their size.

If you search on the Internet, you will find several blogs regarding that topic which I was reading as well. For my customer, I went through the steps in my home lab to document it for them.

Before handover, we updated the cells to vCD 10.0.0.2. Let us start with some screenshots for better documentation:

Ok, let’s take a look into the commands next. I recommend using a ssh connection to the primary cell to check the settings:

Next, see how to limit the values:

First, I have set the memory limit to 1 GB
Second, I have set the cpu limit to 1
Third, I have set the maximum disk size to 10 GB (10000 MB) here

So let us continue in part 2 later.

 

vSphere 7: Look at vSphere Lifecycle Manager

As I am upgrading my personal lab environment, I took a look at the new vSphere Lifecycle Manager to get upgrades of ESXi hosts done. An easy to use cool tool …

Import ISO

First, it is about to import an ISO as source for upgrades.

Create and Attach Baseline

Remediate

Scheduling Options let you plan the upgrade to a timeframe that fits your requirements

You can also configure remediation settings

I ran into the problem, that I suffered from errors: HostUpgradePrecheckTestFailMissingDependencyVibs

On this particular host, I had NSX-T 2.5.some.thing installed in the past but it did not exist anymore. So I ended up in removing NSX Vibs manually from my host – see this part of the documentation for help on that:

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-7FFEBD91-5D82-4E32-93AB-F10D8BFFECAA.html

After removing the Vibs and rebooting the server, I could restart the remediation and it went through without challenges.

Starting with VCF 4 – VMware Cloud Foundation 4.0.0

Part 1 – VMware Cloud Builder 4.0.0.0

VCF 4.0.0 has been released on 14th of April, 2020. So let us take a look into it. The most important topic is filling out the vcf-ems-deployment-parameter.xlsx sheet, plan, and prepare everything upfront before you start.

With VCF 3.9.0, I had to re-prep because I did not prepare 100% correctly before – you will regret, believe me. So yesterday, I deployed VCF 4.0.0 in my lab environment with no issues. It took about 3 hours and 15 minutes to install SDDC Manager 4, VCSA 7, vSAN 7, NSX-T 3.0 on my custom hybrid vSAN.

Important: This is a walk through with lots of screenshots – keep in mind that it does NOT mean that you just start and click next, next, … finish.

Best is to ask VMware PSO to help with architecture and planning workshops before implementing!

I deployed the Cloud Builder 4.0.0.0 (Build version 15956695, this is a pre-GA version) into my “standard management cluster”:

After this phase, start Cloud Builder VM …

I recommend taking a snapshot of the Cloud Builder just in case you need to restart. Log into Cloud Builder and choose your platform …

Read carefully the corresponding information:

And in the next step, download the .xlsx file to fill out before going ahead.

See my Excel file here for your reference (removed my passwords and added dummy license keys):

vcf-ems-deployment-parameter-mylab

After everything has been prepared, go ahead:

My warnings were not severe, so I continued …

I plan to add more content around VCF 4.0.0, but it is not easy to find time to do so …

Taking a look at the SDDC Manager

Part 3 – Start SDDC Manager & Repository

With VCF, if you log in to your vCenter Server, you see “vCenter Server Managed by SDDC Manager”:

After logging in, you see “This vCenter Server is managed by SDDC Manager”:

From now on, please log in to your SDDC Manager for vSphere Admin tasks as you may break workflows provided by the Manager component. It is now your starting point to configure additional components:

To continue with the deployment, you need to enter your Repository Settings to access downloads on vmware.com

After some time you will see several Bundles showing up. One of the next things to be deployed is vRealize Suite Lifecycle Manager 2.1.0 (Build 14062628) which I will do in the next step.

Functions of Cloud Builder

Part 2 – Cloud Builder and VMware Imaging Appliance (VIA)

Starting Cloud Builder after the deployment …

 

 

Keep in mind that you reach the VIA on https://<YourIP&gt;:8445/via

 

 

If an implemented installation process exists, there is no need to use this component.

Before you start using the Cloud Builder, take a snapshot so you can easily start from scratch at least for the appliance.

Log on to the Web Interface with the admin account and the password you have chosen during OVA deployment:

Make sure, you take the checklist serious and have everything prepared upfront:

 

After accepting the EULA, you can upload the configuration file …

and start the validation …

which will take a while …

Here you are able to do RETRY where required and warnings should not stop you from going forward. If Cloud Builder gets stuck, you may try to clean up things like portgroups or a Vlan in your host but to be clear here: It may be necessary to start over completely including a reinstall of ESXi. After you are finished with this step, the BRING-UP can start …

Now these steps take much more time. In my homelab, it took about 3 hours and 15 minutes to succeed …

You can download a report called bringup-results.pdf which I would use for a handover to the customer.