If you’re working with containerized applications, chances are you’ve come across Harbor—a powerful, enterprise-grade container registry. Whether you’re migrating images or integrating Harbor into your CI/CD pipeline, knowing how to push a local image tarball to Harbor is essential.

In this article, we’ll walk through how to load and push the nginx-amd64.tar image to a Harbor registry hosted at habor1.test.com.

Prerequisites

Before we begin, make sure you have:

• Docker installed and running
• Access to the Harbor registry (habor1.test.com)
• A project created in Harbor (we’ll use demo in this example)
• The image tarball: nginx-amd64.tar

Step 1: Load the Image from Tarball

Start by loading the image into your local Docker registry:

docker load -i nginx-amd64.tar

You should see output like:

Loaded image: nginx:latest

Step 1.5: Inspect the Loaded Image

To confirm the image was loaded and check its tag, run:

docker images

This will list all available images. Look for the nginx image and note its TAG and IMAGE ID. If the image shows <none> for repository or tag, use the IMAGE ID to tag it manually.

Example output:

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
<none>       <none>    abc123def456   2 hours ago    133MB

Step 1.6: Tag the Image for Harbor

Docker requires the image to be tagged with the registry address and project path. Use the IMAGE ID from the previous step:

docker tag abc123def456 habor1.test.com/demo/nginx:latest

This tells Docker:

• abc123def456: the image ID of the loaded image
• habor1.test.com/demo/nginx:latest: the full path to the Harbor repository, including project (demo), image name (nginx), and tag (latest)

Step 2: Log in to Harbor

Authenticate with your Harbor registry:

docker login habor1.test.com

Enter your username and password when prompted. If Harbor uses a self-signed certificate, make sure Docker trusts it by placing the CA cert in:

/etc/docker/certs.d/habor1.test.com/ca.crt

Then restart Docker:

systemctl restart docker

Step 3: Push the Image to Harbor

Now push the image to your Harbor registry:

docker push habor1.test.com/demo/nginx:latest

If everything is configured correctly, Docker will upload the image layers and register it under the demo project in Harbor.

Step 4: Verify in Harbor UI

Log into the Harbor web interface at https://habor1.test.com, navigate to the demo project, and confirm that the nginx image appears with the latest tag.

download the ca.crt from a remote Harbor server at 172.171.20.40 using OpenSSL, you can extract it directly from the TLS handshake. Here’s the command:

openssl s_client -connect <harbor server>:443 -showcerts </dev/nul

• Initiates a TLS connection to port 443 on <harbor server>
• Displays the full certificate chain, including the server certificate and any intermediate or root CA certs
• You’ll see blocks like:Code-----BEGIN CERTIFICATE----- MIID... -----END CERTIFICATE-----

To Save the CA Certificate

1. Copy the relevant -----BEGIN CERTIFICATE----- block (usually the last one in the chain).
2. Paste it into a file:bashnano ca.crt
3. Save and exit.

Use the CA with Docker

Place it in Docker’s trusted certs directory:

mkdir -p /etc/docker/certs.d/<harbor ip>
cp ca.crt /etc/docker/certs.d/<harbor ip>/ca.crt
systemctl restart docker

Now Docker will trust Harbor’s certificate when you run:

docker login <harbor IP>

To create a SAN-enabled certificate for Harbor and replace the default certificate in a Harbor OVA deployment, here’s a complete walkthrough:

Step 1: Create a SAN Certificate Using OpenSSL

SSH to harbor ova with root user.
Create a Config File (harbor-san.cnf)

[req]
default_bits       = 2048
prompt             = no
default_md         = sha256
req_extensions     = req_ext
distinguished_name = dn

[dn]
C  = AE
ST = Dubai
L  = Dubai
O  = bcmllab
CN = harbor1.test.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = harbor1.test.com
IP.1  = 172.171.20.40

Generate Key, CSR, and Self-Signed Cert

# Generate private key
openssl genrsa -out harbor.key 2048

# Generate CSR
openssl req -new -key harbor.key -out harbor.csr -config harbor-san.cnf

# Generate self-signed certificate
openssl x509 -req -in harbor.csr -signkey harbor.key -out harbor.crt -days 365 -extensions req_ext -extfile harbor-san.cnf

You now have:

• harbor.crt – your certificate
• harbor.key – your private key

Step 2: Replace Harbor OVA Certificate

Locate Harbor Certificate Directory:
On Harbor OVA, certificates are typically stored under:

/opt/harbor/ssl/

Stop Harbor Services

docker-compose -f /opt/harbor/docker-compose.yml down

Replace Certificates

cp harbor.crt /opt/harbor/ssl/server.crt
cp harbor.key /opt/harbor/ssl/server.key

If you’re using a custom CA:

cp ca.crt /opt/harbor/ssl/ca.crt

Restart Harbor

docker-compose -f /opt/harbor/docker-compose.yml up -d

Managing large-scale VMware Cloud Foundation (VCF) environments can be challenging, especially when it comes to adding multiple hosts. The bulk commission feature, which uses a JSON template, simplifies this process significantly, making it more efficient and error-free. In this blog, we’ll walk through how to commission hosts in VCF using the bulk commission method with JSON, along with screenshots for each step.

Why Use Bulk Commission?

1. Efficiency: Quickly add multiple hosts without repetitive manual steps.
2. Consistency: Ensure all hosts are configured according to predefined standards.
3. Scalability: Ideal for large environments, reducing administrative overhead.

Step-by-Step Guide to Bulk Commission Hosts Using JSON

Step 1: Prepare the JSON Template

First, create a JSON file that includes the details of the hosts you want to commission. Here’s an example template:

{
    "hostsSpec": [
        {
            "hostfqdn": "wd1-cls1-esx1.test.com",
            "username": "root",
            "storageType": "VSAN",
            "password": "password",
            "networkPoolName": "wd1-cls1-networkpool-001"
        },
        {
            "hostfqdn": "wd1-cls1-esx2.test.com",
            "username": "root",
            "storageType": "VSAN",
            "password": "password",
            "networkPoolName": "wd1-cls1-networkpool-001"
        },
        {
            "hostfqdn": "wd1-cls1-esx3.test.com",
            "username": "root",
            "storageType": "VSAN",
            "password": "password",
            "networkPoolName": "wd1-cls1-networkpool-001"
        }
    ]
}

Ensure that each host meets the necessary criteria for VCF, such as compliance with the VMware Hardware Compatibility Guide.

Step 2: Upload the JSON Template to SDDC Manager

1. Log in to the SDDC Manager.
2. Navigate to the ‘Hosts’ section.
3. Click on ‘Commission Hosts’.
4. ‘Select All’ in the checklist and click on Proceed
5. Click on ‘Import’ and Upload the JSON file containing your host details.

Step 3: Validate and Commission the Hosts

1. SDDC Manager will validate the JSON template and the hosts listed.
2. Review the validation results. If any issues are found, correct them in the JSON file and re-upload.
3. Confirm the commissioning to proceed with adding the hosts to the SDDC Manager.

Step 4: Monitor the Commissioning Process

1. Monitor the progress in the SDDC Manager dashboard.
2. Check for any errors or warnings during the process and resolve them as needed.

Conclusion

Using the bulk commission feature in VMware Cloud Foundation with a JSON template streamlines the process of adding multiple hosts, making it faster and more reliable. This method not only enhances efficiency but also ensures consistency across your infrastructure. By following these steps, you can easily scale up your VCF environment with minimal effort.

If you need to uninstall the spherelet from an ESXi host, you might encounter some issues. This blog post will guide you through the process based on the following CLI outputs.

Initial Steps

First, check if the Spherelet is installed on the ESXi host:

[root@vcf-mgmt-esx1:~] esxcli software vib list | grep spherelet
spherelet                      2.3.2-24203661                        VMware  VMwareCertified   2024-12-27    host

If the Spherelet is listed, proceed with the uninstallation process.

Attempt Uninstallation

Try to remove the Spherelet VIB:

[root@vcf-mgmt-esx1:~] esxcli software vib remove -n spherelet

You might encounter the following error.

 [LiveInstallationError]
 VMware_bootbank_spherelet_2.3.2-24203661: Failed to unmount tardisk spherele.v00 of VIB VMware_bootbank_spherelet_2.3.2-24203661: Error in running [/bin/rm /tardisks/spherele.v00]:
 Return code: 1
 Output: rm: can't remove '/tardisks/spherele.v00': Device or resource busy

To resolve this, follow these steps:

Check Spherelet Service Status

Check the status of the Spherelet service:

[root@vcf-mgmt-esx1:~] /etc/init.d/spherelet status
2024-12-28 23:17:55,772 init.d/spherelet spherelet is running

Stop the Spherelet Service

Stop the Spherelet service to free up the resources:

[root@vcf-mgmt-esx1:~] /etc/init.d/spherelet stop
2024-12-28 23:18:02,329 init.d/spherelet spherelet stopped

Verify that the service has stopped:

[root@vcf-mgmt-esx1:~] /etc/init.d/spherelet status
2024-12-28 23:18:06,950 init.d/spherelet spherelet is not running

Remove the Spherelet VIB

After stopping the service, retry the VIB removal:

[root@vcf-mgmt-esx1:~] esxcli software vib remove -n spherelet
Removal Result
   Message: Operation finished successfully.
   VIBs Installed:
   VIBs Removed: VMware_bootbank_spherelet_2.3.2-24203661

Verify that the Spherelet VIB is removed:

[root@vcf-mgmt-esx1:~] esxcli software vib list | grep spherelet
[root@vcf-mgmt-esx1:~]

When deploying a Supervisor in VMware vSphere with Tanzu, it’s not uncommon to encounter an issue where the “Host Config Status” becomes stuck at “Configuring.” This blog post outlines the observations, steps to resolve the issue, and crucial details to consider in environments without internet access.

Observations

• Stuck at “Configuring Host Nodes”:
  Each ESXi host shows the status “Configuring Host Nodes” stuck at “Installed and Started Kubernetes Node Agent on the ESXi Host.” See the screenshot below for reference.

• Image Compliance Issues:
  Under Cluster > Updates > Image, you might see the message: “The cluster needs remediation to finish enabling these solutions: VMware vSphere with Kubernetes – Supervisor Cluster 8.0.3.” This suggests that certain components required for the Supervisor Cluster are not compliant with the desired image.

• Verify Spherelet Installation:
  To verify if the Spherelet is installed on the ESXi hosts, SSH into the ESXi hosts and use the esxcli command:

   ssh root@<esxi-host>
   esxcli software vib list | grep spherelet

• Check Spherelet Logs:
  Check the Spherelet logs to identify any issues. The logs are located at:

   /var/log/spherelet.log

Steps to Fix

Please note that in this environment, there’s no internet access. If the internet were available, the vLCM could remediate the cluster with the Spherelet VIBs. Here are the steps to manually resolve the issue:

1. Copy the Spherelet VIB:
   Copy the Spherelet VIB from vCenter to each ESXi host. The Spherelet VIB is part of the following ZIP file in vCenter:

   /storage/lifecycle/vmware-wcp/spherelet/vsphere-wcp-depot.zip

2. Extract and Upload the VIB:
   Extract the latest VIB from the ZIP file and upload it to the /tmp directory of each ESXi host.
3. Install the VIB:
   Install the Spherelet VIB on each ESXi host using the esxcli command:

   esxcli software vib install -v /tmp/VMware_bootbank_spherelet_2.3.2-24203661.vib

4. Confirm the VIB Installation:
   Verify that the VIB has been installed successfully by running:

   esxcli software vib get -n spherelet

5. Login to VAMI of vCenter:
   Access the vCenter Appliance Management Interface (VAMI).
6. Restart Workload Control Plane:
   Stop and start the ‘workload control plane’ service.
7. Verify Configuration Completion:
   After performing these steps, you should see that the host configuration is completed.

This blog post guides you through replacing the certificate for your Harbor registry deployed on a Tanzu Kubernetes Grid (TKG) cluster using Helm charts. We’ll assume you’re using VCD version 10.5.1 and Container Service Extension (CSE) version 4.2.

Understanding the Need for Certificate Replacement

Harbor certificates, like any security certificate, may need to be replaced due to expiration, security upgrades, or changes in your PKI infrastructure. This process ensures secure communication within your container registry.

Prerequisites

• Access to your TKG cluster and kubectl CLI.
• New certificate and key files (harbor-v2.crt and harbor-v2.key).

Steps:

1. Create a New Secret:

• We’ll store the new certificate and key in a Kubernetes secret for secure management. Use the kubectl create secret tls command to create a secret named harbor-secret-v2:

   kubectl create secret tls harbor-secret-v2 --cert=harbor-v2.crt --key=harbor-v2.key --namespace=harbor-system

Replace harbor-v2.crt and harbor-v2.key with the actual filenames of your certificate and key files.

2. Update the values.yaml file:

• The values.yaml file defines various configurations for your Harbor deployment. Locate this file from your initial Harbor deployment process.
• Edit the values.yaml file to point to the newly created secret. Look for the certSource section and update it to use secrets:

   certSource: secret
   secret:
     secretName: "harbor-secret-v2"

This configures Harbor to use the certificate and key stored in the harbor-secret-v2 secret.

3. Upgrade Harbor with the New Configuration:

• Deploy the updated configuration with the new certificate using the helm upgrade command:

   helm upgrade harbor harbor -n harbor-system -f ./values.yaml

This command upgrades the harbor deployment in the harbor-system namespace using the configuration specified in the updated values.yaml file.

Conclusion

By following these steps, you’ve successfully replaced the certificate for your Harbor registry deployed on your TKG cluster. Remember to update your Harbor clients or local configurations to reflect the new certificate details for continued secure communication.

Virtual Graphics Processing Units (vGPUs) are a game-changer for cloud deployments, enabling high-performance graphics processing for workloads like 3D design, video editing, and AI applications within virtual machines (VMs). VMware Cloud Director (VCD) streamlines vGPU management through vGPU policies, allowing you to define the allocation of these powerful resources to your VMs.

This blog post will guide you through creating a vGPU policy in VCD, ensuring your VMs have the graphics horsepower they need:

Prerequisites:

• Access to the VCD Provider Portal with administrative privileges.
• Pre-configured vGPU profiles in VCD. These profiles represent the different types of vGPUs available in your environment, typically created from the capabilities of your underlying vSphere cluster with NVIDIA GPUs.

Creating a vGPU Policy:

• Log in to the VCD Provider Portal with your administrative credentials.
• Verify vGPU Profile Visibility: Navigate to Infrastructure Resources > vGPU Profiles. Ensure the vGPU profiles corresponding to your available GPUs are listed here. If not, you’ll need to create them beforehand (refer to your VCD documentation for specific steps).

• Create the vGPU Policy:
  • Go to Cloud Resources > vGPU Policies.
  • Click New.
  • On the “What is a vGPU Policy?” screen, click Next.

• Define Policy Details:
  • Name: Enter a descriptive name for your vGPU policy. Ideally, match it to the vGPU profile it references for clarity (e.g., “High Performance vGPU”).

• vGPU Profile: Select the vGPU profile that defines the type and capabilities of the vGPU to be assigned.

• Provider VDC Scope : Choose the PVDC has access to the poloicy.

• Placement: Choose No for placement flexibility. You can assign this policy to VMs and let VCD determine optimal placement based on available resources.

• Sizing: Select No for sizing flexibility. You can configure VM CPU, memory, and storage independently during VM deployment.

• Finalize the Policy:
  • Select the Organization VDC where you want this policy to be available.
  • Review the policy details on the “Ready to Complete” screen and click Finish to create the vGPU policy.

Congratulations! You’ve successfully created a vGPU policy in VCD. Now, when deploying VMs in the chosen Organization VDC, you can assign this policy to provide the necessary vGPU power for your graphics-intensive workloads.

Additional Considerations:

• You can create multiple vGPU policies with different vGPU profiles to cater to varying VM requirements.
• For more granular control, explore the options for placement and sizing policies within VCD, allowing you to define specific placement rules and resource allocation for vGPU-enabled VMs.

By leveraging vGPU policies, you can efficiently manage and allocate vGPU resources within your VCD environment, empowering your tenants with the graphics processing capabilities they need for their demanding workloads.