VCDR: The Future of Disaster Recovery in the Cloud

Disaster recovery (DR) has always been an essential aspect of any organization’s IT strategy. With the increasing adoption of cloud computing, DR has evolved to become a critical component of cloud-based infrastructure. VMware Cloud Disaster Recovery (VCDR) is one such solution that offers a robust and reliable platform for protecting virtual machines (VMs) in the cloud. In this blog post, we will explore VCDR’s features, deployment process, and configuration options.

Overview of VCDR

—————–

VCDR is a cloud-based disaster recovery solution that provides seamless protection for VMs running on vSphere. It offers two main recovery options: Quick Witness Failover (QWF) and Virtual Machine Recovery (VMR). QWF provides an instant failover of the protected VMs to a standby instance in the cloud, while VMR enables the restore of the last known good state of the VMs.

Key Features of VCDR

————————-

1. Cloud File System (CFS): VCDR uses AWS S3 as its CFS, which provides secure and highly available storage for VM snapshots.

2. Encryption: All data stored in the CFS is encrypted to ensure security and privacy.

3. AZ/Region Redundancy: VCDR forces you to select a different AZ or Region for protecting on-premises environments, ensuring that the DR site is not located in the same AZ as the production environment.

4. SDDC Support: VCDR supports AWS SDDCs, allowing you to protect your VMs running on vSphere in the cloud.

5. Connector: VCDR uses a connector to communicate with vCenter, which can be deployed on-premises or in the cloud.

6. User Management: VCDR provides a phyon script that creates a user with specific permissions for the connector, eliminating the need for admin rights.

7. Pairing: VCDR allows you to pair your vCenter with the CFS in the cloud, enabling DR scenarios.

Deployment Process

——————–

Deploying VCDR is relatively straightforward. Here are the basic steps involved in deploying VCDR:

1. Deploy the Connector VM: The first step is to deploy the VCDR connector VM in your vCenter.

2. Download and Deploy the CFS: Once the connector is deployed, you can download and deploy the CFS in your AWS account.

3. Pair the vCenter with the CFS: After deploying the CFS, you need to pair your vCenter with the CFS in the cloud.

4. Configure Protection Groups and Recovery Plans: Once paired, you can configure protection groups and recovery plans for your VMs.

Configuration Options

————————-

VCDR offers several configuration options that enable you to tailor the solution to your specific needs. Here are some key configuration options to consider:

1. Custom Accounts: If you want to use a custom account for VCDR, you need to create a user with specific permissions.

2. Failback: VCDR supports failback scenarios, which enable you to fail back to your on-premises environment after a DR event.

3. Recovery Plans: You can create recovery plans that specify the order in which VMs should be recovered after a DR event.

4. Protection Groups: Protection groups allow you to group VMs based on business priorities, enabling you to protect the most critical VMs first.

Key Takeaways

——————

1. VCDR is a cloud-based disaster recovery solution that provides seamless protection for VMs running on vSphere.

2. It offers two main recovery options: QWF and VMR.

3. VCDR uses AWS S3 as its CFS, which provides secure and highly available storage for VM snapshots.

4. All data stored in the CFS is encrypted to ensure security and privacy.

5. VCDR forces you to select a different AZ or Region for protecting on-premises environments.

6. It supports AWS SDDCs, allowing you to protect your VMs running on vSphere in the cloud.

7. VCDR provides a phyon script that creates a user with specific permissions for the connector, eliminating the need for admin rights.

8. Pairing your vCenter with the CFS in the cloud enables DR scenarios.

In conclusion, VMware Cloud Disaster Recovery (VCDR) is an essential solution for organizations looking to protect their virtual machines running on vSphere in the cloud. With its robust features, ease of deployment, and configuration options, VCDR offers a reliable and secure platform for disaster recovery scenarios. In the next blog post, we will explore how to configure protection groups and recovery plans using VCDR.

This is a blog post about how to configure micro-segmentation on VMware Cloud on AWS (VCD) using NSX-T. The author has extensive experience in VMware, networking, and network security, and has served as a consultant and administrator. The post provides step-by-step instructions for configuring micro-segmentation on VCD using NSX-T, including creating tags and dynamic security groups, configuring firewall rules, and validating the enforcement of security policies using the NSX-T feature of trace flow. The author emphasizes that all content on their blog represents their personal beliefs and opinions, and not those of their employer.

The post covers the following topics:

1. Overview of micro-segmentation on VCD using NSX-T

2. Preparing the environment for micro-segmentation

3. Creating tags and dynamic security groups

4. Configuring firewall rules

5. Validating the enforcement of security policies using trace flow

The author provides detailed instructions and screenshots for each step, as well as best practices and tips for implementing micro-segmentation on VCD using NSX-T. They also discuss gateway firewalling, which will be covered in future blog posts. The post is intended for IT professionals who are interested in implementing micro-segmentation on VCD using NSX-T, and want to learn how to do so in a step-by-step manner.

Troubleshooting TMC Self-Managed Deployment Issues in VCD: Part II

Welcome back to another troubleshooting post for TMC self-managed deployment in VCD. In the previous post, I discussed how to fix the issue of deploying TMC self-managed and publish the solution to tenants. However, there’s another issue that you might encounter when publishing the solution to tenants, which is the task getting stuck during the process. In this post, I will guide you through the steps to troubleshoot and resolve this issue.

Before we begin, please note that these steps are for troubleshooting purposes only and should not be performed in a production environment without consulting the GSS team first.

Step 1: Obtain VCD Auth Token

To start troubleshooting, you need to obtain an auth token from VCD. You can do this by executing the following command in your terminal or command prompt:

vcd-auth login –org –user

Replace with your organization name and with your VCD username.

Step 2: Fetch TMC-SM Solution Add-On Instance UUID

Once you have obtained the auth token, execute the following command to fetch the UUID of the TMC Self-Managed solution add-on installed in your VCD environment:

vcd-api –auth-token call /api/v1/solution-addons?q=tmc-sm

In the response output, locate the UUID of the TMC Self-Managed solution add-on.

Step 3: Update ACL of Entity with VCD System Admin User

Next, you need to update the ACL (Access Control List) of the entity with the VCD System Admin user. To do this, execute the following command:

vcd-api –auth-token put /api/v1/entities/{entity_id}/acl –body ‘{“entity”: {“uuid”: “{entity_uuid}”,”type”: “solution-addon”, “status”: “READY”}}’

Replace {entity_id} with the ID of the entity you want to update, and {entity_uuid} with the UUID of the TMC Self-Managed solution add-on.

Step 4: Get Solution Add-On Instance with Encryption Key

Now, execute the following command to get the solution add-on instance with its encryption key:

vcd-api –auth-token get /api/v1/solution-addons/{solution_addon_id}?fields=encryptionKey

Replace {solution_addon_id} with the ID of the solution add-on instance you want to retrieve.

Step 5: Update Payload with Entity Status and Patch

In the response output of the above API call, ensure that the encryption key is not “******” but has an actual value. If it has an actual value, proceed to update the payload with entity status and patch. You need the full JSON that you obtained in response output.

To update the payload, execute the following command:

vcd-api –auth-token put /api/v1/entities/{entity_id}/patch –body ‘{“op”: “replace”, “path”: “/status”, “value”: “READY”}’

Replace {entity_id} with the ID of the entity you want to update, and {entity_uuid} with the UUID of the TMC Self-Managed solution add-on.

That’s it! By following these steps, you should be able to troubleshoot and resolve the issue of the task getting stuck during publishing of the TMC Self-Managed solution to tenants in VCD. Remember to consult the GSS team before performing any actions in a production environment.

Windows 11 on VMware Horizon: A Step-by-Step Guide to Download and Install

As a consultant, I’m always excited about new features and versions of Windows. The latest version, Windows 11, was recently announced by Microsoft and has been creating quite a buzz in the tech community. In this blog post, I will guide you through the steps to download and install Windows 11 on VMware Horizon, including the rollout with Instant Clone technology.

Downloading Windows 11

At the moment, you cannot download a standalone ISO file of Windows 11 from Microsoft’s website. Instead, you can consider an in-place upgrade of Windows 10. To do this, follow these steps:

1. Open the Settings app on your Windows 10 machine.

2. Click on “Update & Security” and then select “Windows Insider.”

3. Click on “Get started” to sign up for the Windows Insider program.

4. Once you’ve signed up, click on “Settings” and then select “Upgrade to Windows 11.”

5. Follow the on-screen instructions to complete the in-place upgrade.

Alternatively, you can use a script provided by the website to download the necessary files and convert them to a single ISO file. To do this, follow these steps:

1. Go to and click on “Download Windows 11.”

2. Select the edition of Windows 11 you want to download (Home, Pro, or Enterprise).

3. Choose the language and architecture (x86 or x64) for your installation.

4. Click on “Start Download” to begin downloading the files.

5. Once the download is complete, use a tool like Rufus () to create a bootable USB drive with the downloaded files.

6. Insert the bootable USB drive into your machine and restart it.

7. Press F2 or F12 (depending on your machine) to enter the BIOS setup.

8. Set the USB drive as the first boot device, save your changes, and exit the BIOS setup.

9. Your machine should now boot from the USB drive and begin the installation of Windows 11.

Installing Windows 11 on Horizon with Instant Clone

Once you have installed Windows 11 on your machine, you can use VMware Horizon to deploy it as a virtual desktop. To do this, follow these steps:

1. Open the VMware Horizon Client and select “New Desktop” from the home screen.

2. Choose “Windows 11” as the operating system and select the appropriate edition (Home, Pro, or Enterprise).

3. Select the desired configuration for your virtual desktop, such as the number of CPU cores and memory.

4. Click on “Next” to begin the deployment process.

5. Once the deployment is complete, you can start your virtual desktop and begin using Windows 11 with Instant Clone technology.

Troubleshooting VMware DEM

VMware DEM (Dynamic Environment Manager) is a powerful tool for managing virtual desktops, but it may require some troubleshooting to get everything working correctly. Here are some common issues and their solutions:

1. Errors during installation: Make sure you have the latest versions of VMware Horizon and DEM installed. Also, ensure that your machine meets the system requirements for Windows 11 and Horizon.

2. Desktops not showing up: Check that the DEM service is running and that you have the correct IP address for your Horizon server.

3. Performance issues: Make sure you have enough resources (CPU, memory, and storage) assigned to your virtual desktops. You can also optimize your Horizon environment by using features like GPU passthrough and USB redirection.

4. Connection issues: Ensure that your network configuration is correct and that you have the necessary network adapters installed.

Conclusion

Windows 11 on VMware Horizon offers a great combination of performance, security, and ease of use. With the help of this guide, you should now be able to download and install Windows 11 on your virtual desktops using Instant Clone technology. If you encounter any issues during the deployment or troubleshooting process, I hope these tips will help you resolve them quickly and easily. Happy virtualizing!

VCDR: Understanding Cloud File System and Recovery Options

VMware Cloud Disaster Recovery (VCDR) is a powerful tool for disaster recovery and business continuity, offering flexibility and ease of use. In this blog post, we’ll delve into the basics of VCDR, its recovery options, and the process of deploying and configuring it.

Cloud File System (CFS) and Recovery Options

VCDR uses the Cloud File System (CFS) to store VM snapshots securely in AWS S3. The CFS is deployed with AWS S3 and stores all your VM snapshots securely and encrypted. You have two main recovery options:

1. VADP (VMware APIs for Data Protection): This option uses the same APIs as most backup vendors, making it familiar for those who already use backups.

2. CFS-based recovery: This option uses the Cloud File System to recover VMs directly from S3.

Regardless of the option you choose, the CFS and the SDDC used will reside in the same AWS AZ, which helps with speed as the data is more local to the SDDC.

Deploying and Configuring VCDR

To protect a VMConAWS SDDC, you must select a different AZ or Region, as if the SDDC and the AZ were to go down, it would be challenging to recover. VCDR forces you to pick a different area, ensuring that your DR is not in the same AZ.

To deploy and configure VCDR, follow these steps:

1. Deploy a connector: Regardless of whether you’re protecting an on-prem environment or SDDC, you need to deploy a connector. This is made easy for you, and the process is straightforward.

2. Download and deploy the connector: Once the connector is deployed, download it and deploy it into your vCenter.

3. Configuration process: The label should be the same name as the name you have given within vCenter for the VM. The Connector VM previously needed admin rights into the vCenter, but now a phyon script is available to create a user with specific permissions.

Key things to remember when deploying and configuring VCDR include:

1. The Connector VM is 8 vCPUs (reserved), 12GB of RAM (reserved), and 100GB of disk space.

2. Use the default login details of admin/vmware#1.

3. Be careful when using the phyon script, as it gives all permissions but will not work for failback. Pairing it up is easy, done in the cloud console.

In the next blog post, we’ll dive deeper into configuring protection groups and recovery plans with VCDR. Stay tuned!

22Four Brewing Co: A Journey of Friendship, Beer, and Growth

==================================================================

Introduction

————

22Four Brewing Co is a small starting brewery founded by three friends who shared a passion for beer. They started as hobbyists, experimenting with different recipes and techniques until they finally established their own brewery. This is the story of how they overcame obstacles, grew as friends and business partners, and created a successful craft beer brand in the process.

The Early Days

—————–

In 2019, Rob, Johan, and I (Joe) started discussing the idea of brewing our own beer. We were all avid homebrewers and had been experimenting with different recipes for years. Our shared love for craft beer and the challenge of creating something unique drove us to take the next step and start a brewery.

We began by researching the basics of brewing and experimenting with different ingredients and techniques. We quickly realized that we needed more knowledge and experience to create the perfect beer, so we started visiting local breweries to learn from them. We attended brewing workshops and seminars, and even visited some of the best breweries in Belgium to learn from their experts.

Our First Beer: Joehoee

—————————–

After months of research, experimentation, and fine-tuning our recipes, we finally brewed our first beer, “Joehoee”. It was a hoppy, golden ale with a hint of citrus and a smooth finish. We were thrilled with the result and couldn’t wait to share it with our friends and family.

We started small, sharing our beer with local bars, restaurants, and pubs. We also attended beer festivals and events to gain more exposure for our brand. Our beer was well-received, and we quickly gained a following of loyal customers who appreciated our unique flavor profiles and dedication to quality.

Growing Pains

—————-

As our popularity grew, so did our production. We soon found ourselves in need of more equipment and a larger space to brew and store our beer. We faced several challenges, including limited financing options, lack of resources, and the struggle to maintain quality while scaling up.

However, we didn’t let these obstacles discourage us. Instead, we worked together as friends and business partners to find solutions that would allow us to continue growing and improving our craft. We invested in new equipment, expanded our team, and implemented stricter quality control measures to ensure consistency across all batches.

Our Second Beer: Keep It Up!

——————————-

After the success of Joehoee, we knew we had to follow up with another beer that would showcase our creativity and skill. We wanted a summer beer that combined the hoppiness of an IPA with the sweetness of a wheat beer. After months of experimentation, we finally settled on “Keep It Up!”, a hoppy wheat beer with a hint of citrus and a smooth finish.

The Collaboration with Westlandpeppers

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

We were thrilled when we were approached by Westlandpeppers, one of the best pepper producers in the Netherlands, who wanted to collaborate on a limited edition beer that would showcase their world-famous peppers. We quickly agreed, knowing this was an opportunity to create something truly special.

The Promotion and National Attention

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

We were blown away when De Telegraaf, one of the Netherlands’ largest newspapers, contacted us about doing an article on our story. This was a dream come true for us, as we had no idea how to take our brewery to the next level. We worked with the journalist to craft an engaging narrative that would showcase our passion, dedication, and creativity.

The Future

——————

Today, 22Four Brewing Co is one of the most popular craft beer brands in The Netherlands. We’ve expanded our team, invested in new equipment, and explored new markets to share our passion with a larger audience. We remain committed to our core values of quality, creativity, and friendship, knowing these principles will allow us to continue making the world’s best beer for years to come.

Upgrading ESXi to Version 7.0: A Personal Experience and Lessons Learned

As part of my ongoing efforts to ensure the reliability and performance of my NUC cluster, I recently upgraded from ESXi version 6.7 to 7.0. While the upgrade process was generally smooth, I encountered an issue related to available space on the system disk(s). In this blog post, I will share my personal experience with the upgrade process and provide some lessons learned that may be helpful to others.

Background and Reasoning

I have chosen to install ESXi on a USB device because I needed to use both internal disks (2) for vSAN when required. This setup allows me to have a separate boot drive for the ESXi installation, which is recommended by VMware to ensure better performance and reliability. However, this configuration also introduced some challenges during the upgrade process.

Issue with Available Space on System Disks

During the upgrade process, I encountered an error message indicating that there was not enough available space on the system disks to complete the installation. This was a bit surprising, as I had plenty of free space on both disks. However, after some investigation, I realized that the issue was related to the fact that the USB device containing ESXi was also used as a data store for vSAN.

Solution and Lessons Learned

To resolve this issue, I performed the following steps:

1. Removed all vSAN data stores from the USB device.

2. Upgraded ESXi to version 7.0.

3. Added the USB device as a new vSAN data store.

Here are some lessons learned from this experience:

1. Always ensure that you have enough available space on your system disks before attempting an upgrade. This includes both the ESXi installation disk and any other data stores used by vSAN.

2. When upgrading from version 6.7 to 7.0, removing “store.old” is not necessary, as the new version will overwrite the existing filesystem and remove the old store.old folder automatically.

3. If you are using a USB device for both ESXi installation and vSAN data storage, make sure to remove all vSAN data stores from the device before upgrading ESXi. This will ensure that there is enough space available on the system disks to complete the upgrade.

4. After the upgrade, re-add the USB device as a new vSAN data store to ensure continued performance and reliability.

5. When encountering issues during an upgrade process, consult the official VMware documentation and community forums for assistance. This can help you identify and resolve any potential issues before they become critical.

Conclusion and Future Plans

In conclusion, upgrading ESXi from version 6.7 to 7.0 can be a bit challenging, especially when using a USB device for both installation and vSAN data storage. However, with careful planning, attention to detail, and the right troubleshooting skills, it is possible to resolve any issues that may arise.

For my future plans, I have decided to install ESXi directly on the disks of my NUC cluster, rather than using a USB device. This will ensure better performance and reliability, as well as eliminate any potential issues related to available space on the system disks. Additionally, I plan to re-evaluate my vSAN configuration to ensure that I am using the most optimal storage layout for my needs.

In summary, upgrading ESXi to version 7.0 can be a bit challenging, but with careful planning and attention to detail, it is possible to overcome any issues that may arise. By sharing my personal experience and lessons learned, I hope to help others who may encounter similar challenges in the future.

NSX ALB Virtual Service Migrator v1.3: Enhanced Capabilities and New Release

In my previous articles, I have discussed the NSX ALB Virtual Service Migrator tool that I have developed to migrate virtual services from one NSX ALB cloud account to another. The tool has been continuously enhanced to support new features and address user feedback. In this article, I would like to highlight the latest enhancements and changes in version 1.3 of the tool.

Enhancements in v1.3

——————-

The main enhancement in version 1.3 is the ability to migrate Virtual Services Hosting (TLS SNI and EVH) with parent-child virtual service relationships to any supported target NSX ALB cloud accounts. This feature was highly requested by users who need to migrate complex virtual service configurations.

To enable this feature, a new migration mode switch “–virtual_hosted_vs (or -q)” has been added to the tool. When this switch is used, the tool will now select TLS-SNI or EVH virtual services that need to be migrated to the target cloud account.

Other changes and enhancements in version 1.3 include:

* Improved error handling and messaging for better user experience

* Bug fixes and performance optimizations

* Enhanced documentation and release notes

Availability and Download

————————

The NSX ALB Virtual Service Migrator tool is available for download from my Github repository. The repository includes the tool, release notes, and other artifacts. To access the repository, please visit the following link:

Please note that the tool is provided as-is, and users are advised to review the release notes and documentation before using it in production environments.

Previous Articles and Resources

——————————-

If you missed my previous articles related to NSX ALB Virtual Service migrator, please check out the following links:

* Overview of the tool and its capabilities:

* Usage instructions and migration workflow:

* Limitations and open issues:

* Migration demos and examples:

Feedback and Collaboration

————————-

I would like to thank all users who have provided valuable feedback on the tool. Your input has been instrumental in shaping the tool and its capabilities. If you wish to collaborate or provide feedback, please leave me a message at hari@vxplanet.com.

Finally, if you would like to support my work and contribute to the development of the NSX ALB Virtual Service Migrator tool, you can use the following BuyMeaCoffee button:

Thank you for your time, and I hope you find the NSX ALB Virtual Service Migrator tool helpful in your NSX ALB deployments.

vRealize Log Insight (vRLI) Certificate Management with vRSLCM

In a standard vSphere environment, managing certificates for vRealize Log Insight (vRLI) can be a daunting task. However, with the help of vRealize Lifecycle Manager (vRSLCM), you can easily generate and replace vRLI certificates. In this blog post, we will explore the various options and corresponding tasks to generate and replace vRLI certificates using vRSLCM.

vRSLCM is great in many ways for managing vRealize products. The Locker functionality of vRSLCM can be used to manage Passwords, Licenses, and Certificates. Specifically, the Locker can be used to generate Certificates and Certificate Signing Requests (CSR).

To generate a certificate or CSR using vRSLCM, follow these steps:

1. Open the vRSLCM web interface and navigate to the Locker section.

2. Click on the “Certificates” tab and select the “Generate” option.

3. Choose whether you want to generate a certificate or a CSR.

4. If you choose “generate CSR”, you will be asked where to save the CSR file. Save the file somewhere safe, as you will need it later for certificate replacement.

5. If you choose “generate Certificate”, the certificate will be stored in the vRSLCM Locker and can be directly used for product deployments or certificate replacements.

Alternatively, if you do not have vRSLCM deployed, you can generate a certificate or CSR using the openssl tool. The openssl tool is installed by default on vRLI and most other vRealize products, but can also be downloaded and installed on Linux, Mac, or Windows.

To generate a certificate or CSR using openssl, follow these steps:

1. SSH to one of the vRLI nodes.

2. Use the following commands to view the contents of the private key and certificate:

“`

cat /path/to/privatekey.pem

cat /path/to/certificate.crt

“`

3. Use the following command to generate a CSR:

“`

openssl req -new -key /path/to/privatekey.pem -out /path/to/csr.pem -subj “/C=,ST=,L=,O=,CN=“

“`

4. Use the following command to view a more detailed view of the certificate:

“`

openssl x509 -noout -text -in /path/to/certificate.crt

“`

5. On Windows, you can use the certutil tool to view a more detailed view of the certificate:

“`

certutil -decode /path/to/certificate.crt

“`

To replace an existing vRLI certificate with a new one, follow these steps:

1. Open the vRSLCM web interface and navigate to the Locker section.

2. Click on the “Certificates” tab and select the existing certificate you want to replace.

3. Click on the “Replace” button and select the new certificate file you want to use.

4. The replacement process should finish quite fast. Start or refresh a vRLI browser tab/window and double-check if the certificate replacement has taken place.

If your vRLI is deployed from or imported to vRSLCM, it is easy to replace the certificates. You can use either of the two options described below:

Option 1: Use the “Locker, Certificates, Import” option to import the new certificate file.

Option 2: Use the “Lifecycle, SSL, Choose File” option to select the new certificate file and replace the existing certificate.

In conclusion, managing certificates for vRLI using vRSLCM is a straightforward process that can be done using either the vRSLCM web interface or the openssl tool. By following the steps outlined in this blog post, you can easily generate and replace vRLI certificates, ensuring the security and integrity of your vSphere with Tanzu environment.

Sure, I’m glad that my explanation was helpful! If you have any more questions or need further clarification, please don’t hesitate to ask. I’m here to help. Good luck with your NSX Malware Prevention deployment!