Managing VMware Resources with Azure Resource Manager and ARM Templates

In the previous posts of this series, we explored how to extend Azure governance and management capabilities to VMware-based resources using Azure Arc-enabled VMware vSphere. We demonstrated how to create a VMware virtual machine from the Azure portal and how to use the connectedvmware Azure CLI extension to manage VMware resources through Azure CLI. In this post, we will dive deeper into automation solutions that are available to manage VMware resources through Azure tools, specifically focusing on Azure Resource Manager (ARM) and ARM Templates.

Azure Resource Manager (ARM) is the deployment and management service for Azure. It provides a management layer that enables you to create, update, and delete resources in your Azure account. ARM offers features such as access control, locks, and tags to secure and organize your resources after deployment. Additionally, ARM provides a declarative Infrastructure-as-code language called ARM Templates to deploy and maintain resources.

ARM Templates are used to define the desired state of your resources in JSON or Bicep syntax. These templates can be used to deploy and manage resources across different Azure services, including VMware resources enabled by Azure Arc. With ARM Templates, you can automate the deployment and management of your VMware environment, making it easier to maintain consistency and compliance across your infrastructure.

Let’s take a look at a minimal ARM Template to deploy a VMware virtual machine:

“`json

{

“name”: “vmware-virtual-machine”,

“resources”: [

{

“type”: “Microsoft.VMware/virtualMachines”,

“apiVersion”: “2019-04-01”,

“name”: “myVirtualMachine”,

“location”: “eastus”,

“properties”: {

“vmwareInfrastructure”: {

“username”: “myUsername”,

“password”: “myPassword”

},

“vcpus”: 2,

“memoryMB”: 4096,

“storageMB”: 30720,

“osType”: “Other”,

“computevhd”: “path/to/vmdk”,

“diskController”: “LSILogic”,

” FloppyDrive”: “None”,

“cdrom”: “None”

}

}

]

}

“`

This ARM Template deploys a VMware virtual machine with the specified properties. You can modify this template to fit your specific needs and requirements.

Benefits of Managing VMware Resources with Azure Resource Manager and ARM Templates

—————————————————————————————

Managing VMware resources with Azure Resource Manager and ARM Templates offers several benefits, including:

### Consistency and Compliance

By using ARM Templates to deploy and manage your VMware resources, you can maintain consistency and compliance across your infrastructure. This ensures that all resources are deployed and configured in a standardized manner, reducing errors and improving security.

### Self-Service Resources

With Azure Resource Manager and ARM Templates, you can provide self-service VMware resources to your users. This enables them to deploy and manage their own resources without requiring IT intervention, improving productivity and agility.

### Global Security Posture

By extending Azure governance policy to infrastructure components outside the Azure native scope, you can maintain a global security posture across your entire infrastructure. This ensures that all resources, including VMware resources, are subject to the same security policies and controls.

Conclusion

———-

In this series of posts, we have explored how to extend Azure governance and management capabilities to VMware-based resources using Azure Arc-enabled VMware vSphere. We have seen how to create a VMware virtual machine from the Azure portal and how to use the connectedvmware Azure CLI extension to manage VMware resources through Azure CLI. Additionally, we have discussed how to use Azure Resource Manager (ARM) and ARM Templates to automate the deployment and management of your VMware environment.

By managing VMware resources with Azure Resource Manager and ARM Templates, you can maintain consistency and compliance across your infrastructure, provide self-service resources to your users, and maintain a global security posture. As the Azure Arc-enabled VMware vSphere feature is still in a preview stage, there will be a bunch of changes and enhancements before the Global Availability.

We hope this series of posts has provided you with valuable insights into managing VMware resources with Azure tools. If you have any questions or feedback, please do not hesitate to reach out to us.

Increasing Kubernetes Node Memory Online with VMware and Memory Hot Add

As a Kubernetes administrator, one of the common tasks you may encounter is increasing the memory allocated to nodes. However, this task can be challenging when working with virtual machines (VMs) provisioned manually, as there isn’t a controller that can automatically handle the memory upgrade process. In this blog post, I will discuss how to increase Kubernetes node memory online with VMware and memory hot add.

Background

———-

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. As Kubernetes workloads grow, they require more memory to function optimally. In some cases, increasing the node memory is necessary to ensure proper application performance. However, manually provisioned VMs lack the ability to automatically increase memory, making it a challenging task for Kubernetes administrators.

Memory Hot Add

————-

Memory hot add is a feature in VMware that allows administrators to increase the memory allocated to running VMs without downtime or service interruption. This feature utilizes Intel’s Extended Memory Technology (EMT) to add memory to running VMs. With memory hot add, you can increase the memory of a running VM without the need for a reboot or manual downtime.

Enabling Memory Hot Add

————————-

To enable memory hot add on your VMware infrastructure, follow these steps:

1. Log in to the vSphere Web Client and select the host where you want to enable memory hot add.

2. In the Host Configuration tab, select the Advanced button and scroll down to the Memory Management section.

3. Select the Enable Memory Hot Add checkbox to enable the feature.

4. Click Apply to save your changes.

Once memory hot add is enabled, you can increase the memory allocated to running VMs without downtime or service interruption.

Increasing Kubernetes Node Memory Online with Memory Hot Add

———————————————————–

To increase the memory of a Kubernetes node online with memory hot add, follow these steps:

1. Log in to the vSphere Web Client and select the host where your Kubernetes node is running.

2. In the Host Configuration tab, select the Advanced button and scroll down to the Memory Management section.

3. Select the Add Memory button to increase the memory allocated to the running VM.

4. Enter the amount of memory you want to add and click Apply to save your changes.

5. Wait for the memory hot add process to complete, which should take a few seconds.

6. Check the Kubernetes node status with `kubectl describe node` to verify that the increased memory has been allocated successfully.

As shown in the previous example, increasing Kubernetes node memory online with memory hot add is a straightforward process that can be completed without downtime or service interruption. This feature allows Kubernetes administrators to adapt to changing workload requirements quickly and efficiently, ensuring optimal application performance and customer satisfaction.

Conclusion

———-

In this blog post, we explored how to increase Kubernetes node memory online with VMware and memory hot add. We discussed the background of Kubernetes node memory management, the concept of memory hot add, and the steps required to increase Kubernetes node memory online. This feature allows Kubernetes administrators to adapt to changing workload requirements quickly and efficiently, ensuring optimal application performance and customer satisfaction.

If you are looking for options on how to protect your vSphere and VMware Cloud Director workloads, Nakivo Backup & Replication offers capabilities to back up vSphere VMs and VCD objects such as vApps, individual VMs, and vApp metadata, and ensure that remote workloads can be recovered in case of a data loss event.

Enabling NSX Network Detection and Response (NDR) in VMware NSX-T 3.2

In my previous post, I covered the deployment and enabling of NSX Intelligence on our NSX Application Platform. In this post, we will explore how to enable the integrated NSX Network Detection & Response (NDR) feature in NSX-T 3.2.

Before we begin, it’s essential to understand that the NDR solution in NSX-T 3.2 does not require the deployment of any sensors, unlike traditional NDR solutions. NSX-T becomes the sensor, monitoring traffic via NSX Intelligence, leveraging inputs from the NSX Malware Prevention solution and the NSX Intrusion Detection & Prevention (IDP) solution.

Requirements:

* NSX-T 3.2 or higher version

* NSX Manager installed and configured

* NSX Intelligence enabled

* NSX Malware Prevention and IDP solutions enabled

Step 1: Log in to the NSX Manager as an administrator.

Step 2: Click on the “Security” tab, then click on the “Network Detection and Response” option.

Step 3: On the “NSX Network Detection and Response” page, click the “Activate” button.

Note: Before activating NDR, ensure that your NSX license meets the minimum requirements for NDR activation.

Step 4: Select the cloud region you want to use for the NSX Advanced Threat Prevention (ATP) cloud service. If you have already activated the Malware Protection feature, the selected cloud region will be preselected.

Step 5: Run prechecks to ensure all prerequisites are met. The activation wizard validates that the minimum license requirement is met, performs connectivity checks between the NSX Manager and the ATP cloud service, and validates that the selected cloud region is reachable.

Step 6: If all pre-checks are successful, click “Activate.” This may take some time as the activation wizard does the needful to get NDR up and running.

Step 7: Once completed, the status should be green, indicating that NDR is active and functioning correctly.

Step 8: Log out of the NSX Manager and log back in as an administrator. Click on the top right corner where the nine dots are (3×3). This will open a new window with the NSX Network Detection and Response landing page.

At this point, your NDR solution should be active, and you should see a dashboard showing security-related activities. In future posts, we will explore how to enable additional features, correlate security events from NSX Intelligence, Malware Prevention, Suspicious Network Activity, and IDS/IPS, and see traffic populating the dashboard.

Quick Win: Turning on NSX Suspicious Traffic detectors is an excellent quick win, but be aware that there is a software bug in NSX-T 3.2.0.1 that can cause meltdowns in your NAPP/NSX-Intelligence environment if you enable Horizontal Port Scan and Uncommonly Used Port. It’s best to check the release notes before enabling these features to ensure they are fixed.

In conclusion, activating NSX Network Detection and Response in NSX-T 3.2 is a straightforward process that unlocks powerful security capabilities. By following these steps and exploring additional features, you can leverage NDR’s full potential and enhance your network security posture.

Deploying vSphere with Tanzu on a VDS Setup with HAProxy

In this blog post, I will share my experience of deploying vSphere with Tanzu on a VDS setup with HAProxy. While there have been several blog posts written on this topic, I will provide the steps I took to get up and running with vSphere with Tanzu. The official VMware documentation provides additional and detailed information.

Step 1: Unify Network with the following VLANs and routable networks:

Before deploying vSphere with Tanzu, it is essential to unify the network with the following VLANs and routable networks:

* vCenter modification to allow single node supervisor control plane VM as written by William Lam (https://williamlam.com/2021/09/single-node-supervisor-control-plane-vm-for-vsphere-with-tanzu-now-possible-in-vsphere-7-0-update-3.html)

Step 2: Select haproxy-v0.2.0 and New VM from this Template

From the Content Library, select haproxy-v0.2.0 and create a new VM from this template. Note that the Load Balancer IP Range is a subset of the 192.168.3.0/24 network and does not contain the Frontend IP as configured in Step 8-2.8.

Step 3: Configure the Networking

Configure the networking for the HAProxy VM by selecting the following options:

* Usable IP Ranges for this /26 subnet are 192.168.3.193-192.168.3.254

* Use the default gateway (192.168.3.1) and DNS server (192.168.3.100)

Step 4: Summary | Ready to Complete

After deployment, you should see the three IP addresses for Management, Workload, and Frontend as configured during deployment. Before proceeding with the enablement of Workload Management, have a look at the anyip-routes service with the command systemctl status anyip-routes.service. This service should be in an active (running) state.

Step 5: Review Configuration Files

Within the files /etc/vmware/route-tables.cfg and /etc/vmware/anyip-routes.cfg, and /etc/haproxy/haproxy.cfg, you can see what configuration has been made during the OVA deployment. See my config files below (some lines with comments are removed):

Step 6: Enable Workload Management

To enable workload management in the next step, you need the certificate, which can be copied from the contents of /etc/haproxy/ca.crt on the HAProxy VM. If all went well with the HAProxy deployment, you can now enable workload management. Depending on your setup, it may take some time to deploy the supervisor control plane VM(s).

Step 7: Monitor and Troubleshoot

After deployment, you should see a supervisor cluster with a control plane node address listed. The warning comes from a license that has not yet been configured. In the Hosts and Cluster View, you will notice a resource pool “Namespaces” with a SupervisorControlPlaneVM (1) and more if you did not tweak this setting (default is 3).

In conclusion, deploying vSphere with Tanzu on a VDS setup with HAProxy requires careful planning and execution. By following these steps, you can successfully deploy vSphere with Tanzu and enable workload management. However, it is essential to monitor and troubleshoot the deployment to ensure that everything is running smoothly and securely.

resetear la password SSO en vCenter Server Appliance del usuario: administrator@vsphere.local

En este artículo, exploraremos cómo resetear la contraseña del usuario administrator en un vCenter Server Appliance 6.5 y versiones posteriores. Si olvidamos o perdimos la contraseña root, podemos seguir los siguientes pasos para restablecerla:

Para comenzar, necesitamos conectarnos con las credenciales de root a nuestro vCenter Server Appliance a través de ssh. Para habilitar el shell de Bash, ejecutamos el siguiente comando:

Command> shell.set –enabled true Command> shell

Desde vCenter 6.5 en adelante podemos usar el siguiente comando para resetear la contraseña del usuario administrator:

$ /usr/lib/vmware-vmdir/bin/vdcadmintool

Nota: Esta utilidad solo está disponible en el nodo PSC externo o en vCenter Server con PSC integrado. Si ejecutamos este comando en el nodo de administración, se producirá un error “No such file or directory”.

Al ejecutar el comando, se nos solicitará el Account UPN correspondiente. En este caso, ingresamos:

User@vSphere_Domain_Name.local (Example – Administrator@vsphere.local)

Nota: Si el nombre de dominio de vSphere está personalizado, ingresamos el nombre de dominio personalizado en Account UPN.

Por último, copiamos la nueva password temporal.

Para finalizar, volvemos a iniciar sesión en vSphere Web Client con las nuevas credenciales del usuario administrator y guardamos los cambios.

Espero que esta información sea útil para aquellos que buscan resetear la contraseña del usuario administrator en un vCenter Server Appliance 6.5 o versiones posteriores. Si tiene alguna duda o sugerencia, no dude en dejar un comentario.

Resolving DHCP Issues with NSX-T Segments using a Single Script

As you deploy new NSX-T segments in your network, you may encounter an issue where DHCP is not functioning properly due to the default “segment security policy” preventing it. This can be a daunting task when dealing with multiple segments, but fear not, as we have a solution that can make this process much easier.

The issue arises when newly deployed NSX-T segments receive the default “segment security policy” which blocks DHCP traffic by default. To resolve this, you need to create a new “segment security policy” that allows DHCP, and assign it to the affected segments. However, managing this process for multiple segments can be time-consuming and error-prone.

To make this process easier, we have developed a script that enables you to change the “segment security policy” for all segments connected to a Transport Zone in one go. This script is available here and can be used to quickly resolve DHCP issues with NSX-T segments.

The script works by iterating through all the segments connected to a specified Transport Zone and updating their security policies to allow DHCP traffic. This ensures that all segments are configured correctly and DHCP traffic is allowed, without any manual intervention.

To use the script, simply download it and follow these steps:

1. Open a terminal or command prompt and navigate to the location where you saved the script.

2. Run the script with the following command: ./change_dhcp_policy.sh -t

3. Replace with the name of your Transport Zone.

4. The script will then iterate through all segments connected to the specified Transport Zone and update their security policies to allow DHCP traffic.

The script is designed to be user-friendly and easy to use, even for those who are not familiar with PowerShell. However, if you do encounter any issues, we have provided detailed instructions and troubleshooting tips in the script’s documentation.

In conclusion, managing DHCP issues with NSX-T segments can be a complex task, but with this script, it becomes much easier. Simply download the script, follow the instructions, and you’ll be able to resolve DHCP issues for all your NSX-T segments in no time.

So, if you’re dealing with DHCP issues in your NSX-T environment, don’t hesitate to give this script a try. It can save you a lot of time and effort, and ensure that your network is running smoothly and efficiently.

Local Kubernetes Clusters with Minikube and Kasten K10

Introduction

In this blog post, we will explore the ease of deploying a local Kubernetes cluster on your laptop or desktop machine using Minikube and how to use Kasten K10 to protect your data services. We will also cover the available addons for Minikube and how to use arkade to install the necessary tools and CLI’s.

Minikube

Minikube is a tool that allows you to quickly set up a local Kubernetes cluster on macOS, Linux, and Windows. It has an easy-to-use interface and supports many popular Kubernetes tools and Cli’s. With Minikube, you can easily spin up and down your Kubernetes cluster as needed.

Kasten K10

Kasten K10 is a data management solution that provides backup and recovery for Kubernetes applications. It supports many popular cloud providers and on-premises storage systems. With Kasten K10, you can easily protect your data services and ensure fast recovery in the event of a failure.

Getting Started with Minikube

To get started with Minikube, you can follow these steps:

1. Head over to the project page here.

2. Choose your installation method. You can use Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware as your container or virtual machine manager.

3. Download and install the Minikube binary using arkade get minikube.

4. Run the following command to spin up a Kubernetes cluster: minikube start

Available Addons for Minikube

Minikube has many available addons that can make your development experience easier and more efficient. Some of these addons include:

1. Volumesnapshots – allows you to create and manage snapshot backups of your volumes.

2. CSI-Hostpath-Driver – provides a host path driver for CSI volumes.

3. MySQL – a popular data service that can be protected using Kasten K10.

4. WordPress – a web application that can also be protected using Kasten K10.

Deploying Kasten K10

You can deploy Kasten K10 in your Minikube cluster using two methods:

1. Helm Chart – you can use the Kasten K10 helm chart to deploy the application.

2. Arkade – you can use arkade to install and configure Kasten K10.

Configuring Kasten K10

To configure Kasten K10, you will need to set the following:

1. API server port – set the API server port to 6433 instead of a random API port.

2. Container runtime – set the container runtime to containerd.

3. Kubernetes version – set the Kubernetes version to ensure that your Kasten K10 deployment is at a supported version.

Protecting Data Services

Once you have deployed and configured Kasten K10, you can protect your data services using the available addons. For example, you can use volumesnapshots to create snapshot backups of your volumes and csi-hostpath-driver to provide a host path driver for CSI volumes.

Conclusion

In this blog post, we have covered the ease of deploying a local Kubernetes cluster using Minikube and how to use Kasten K10 to protect your data services. We have also covered the available addons for Minikube and how to use arkade to install and configure Kasten K10. With these tools, you can easily develop and deploy your Kubernetes applications in a local development environment.

The Journey to Speaking at VMworld: Overcoming Fears and Achieving Dreams

As I sat in the packed room at VMworld, waiting for my turn to speak, I couldn’t help but think back to the journey that had brought me here. It was a journey filled with rejection, determination, and ultimately, success.

Ten years ago, I attended my first VMworld conference, awestruck by the leaders and superstars speaking on stage. I knew then and there that I wanted to be up there one day, sharing my own story and expertise with the crowd. But, as I soon found out, the road to getting there was not an easy one.

I submitted my first session proposal two years ago, only to receive a decline email from the submissions team. It was disappointing, but I didn’t let it deter me. I remembered my father’s saying, “If you don’t ask, the answer is always no.” So, I kept trying, submitting twice more with the same result. It seemed like the odds were against me, and I was starting to feel defeated.

But then, I remembered another quote that has always inspired me: “Goonies never say die!” I decided to take a different approach, focusing on a customer success story that I knew would resonate with both the IT community and the review board. I reached out to Sentara Healthcare, a major healthcare organization on the East coast, and their Principal Technical Architect, Chris Poyner, who was part of the original team that started their project over two years ago. With their support and input, I crafted a compelling presentation that highlighted their journey and success with VMware technology.

After what felt like an eternity, the email arrived – my session proposal had been accepted for VMworld 2019 US! It was finally happening – I was going to get on that stage and speak to my colleagues and fellow tech peers at the biggest show in the industry.

The next step was to prepare, and the VMworld committee and review team provided me with an online portal filled with resources and templates to help me get started. I built a simple yet powerful presentation, and practiced until I could deliver it flawlessly.

The night before my flight, I felt like a kid on Christmas morning – excited and nervous at the same time. As I stood on stage, looking out over the chairs filled with eager attendees, my nerves were at an all-time high. But as soon as I started speaking, something magical happened. The words flowed effortlessly, and I found myself in the zone, connecting with the audience and sharing my knowledge and passion for VMware technology.

The session was a success, and I received overwhelming feedback from attendees who appreciated the customer success story and the insights it provided into the future of the industry. It was a moment I will never forget, and one that has opened up new opportunities for me to interact with people and share my expertise on a larger stage.

Looking back, I realize that the journey to speaking at VMworld was not just about overcoming rejection and fear, but also about finding my voice and my purpose as an IT professional. It has taught me to embrace challenges, take risks, and never give up on my dreams. And for that, I am eternally grateful.

Sure, here is a new blog post based on the information provided:

Troubleshooting vCenter Server Agent Installation Failures

As a follow-up to my previous blog post on installing the vCenter Server agent (HA) service, I wanted to share a recent experience I had with a similar issue and the solution I found. Despite the original post being one of the most read articles on my blog, this time around, I couldn’t solve the problem using the same approach. However, I did discover a workaround that is easy to implement and has been successful in multiple attempts.

The symptoms were similar to before: during the installation of the vCenter Server agent (HA) service, the process would fail with an error message stating that the operation finished successfully, but a reboot was not required. Additionally, the VIBs installed and removed were the same as before, including VMware_bootbank_vmware-fdm_7.0.3-19193900.

This time, I noticed that a budget SSD that was holding an empty datastore had ceased to function, but vCenter still marked it as A-ok. To troubleshoot the issue, I attempted to remove the fdm agent from the command line, but encountered a disk access error. After further investigation, I unmounted and deleted the failed disk, which allowed vCenter to reinstall the agent automatically.

The root cause of the issue was that the budget SSD had failed and was still being recognized by vCenter as a healthy disk. This led me to realize that it’s essential to regularly check the health of all disks in your environment, especially those that are holding empty datastores. By doing so, you can identify any potential issues before they cause problems with vCenter or other virtual machines.

To avoid this issue in the future, I recommend taking a few extra steps when installing the vCenter Server agent (HA) service:

1. Verify that all disks are healthy and functioning properly before attempting to install the agent.

2. Check the logs for any errors or warnings related to disk health.

3. Consider using a different storage solution if you’re experiencing issues with budget SSDs or other unreliable storage options.

4. Keep an eye on disk health and regularly check for any signs of failure.

In conclusion, while the original post helped me troubleshoot the issue to some extent, I found that a different approach was needed this time around. The workaround I discovered can help you avoid similar issues in the future, and it’s essential to be proactive in checking disk health to ensure the reliability of your vCenter environment. Thank you for reading, and I hope this helps!