VSphere — Page 3

VMware vRealize Automation (vRA) and Terraform target different infrastructure workflows. This comparison covers SDDC automation, user experience, VMware integration, security, compliance, and support. End-to-End Automation: vRA automates the entire software-defined data center (SDDC) lifecycle, from provisioning to decommissioning. Terraform is more limited, focusing only on infrastructure provisioning. User Experience: vRA provides a user-friendly interface, making it easier for non-technical users to request and manage infrastructure. Terraform, on the other hand, requires more technical expertise to use effectively. Integration with VMware: vRA integrates with other VMware products, such as vSphere, NSX, and vSAN, allowing for a seamless experience. Terraform can also integrate with VMware, but it requires more manual effort to set up the integration. Enterprise-Grade Security: vRA includes enterprise-grade security features, such as role-based access control and multi-factor authentication. Terraform does not have built-in security features, requiring additional tools or manual effort to secure the environment. Robust Compliance Features: vRA includes compliance features, such as blueprints that enforce specific policies and standards, making it easier to meet regulatory requirements. Terraform does not have built-in compliance features, leaving it up to the user to ensure compliance. Strong Support: vRA has a large, global community of users and is backed by VMware, a well-established company in the tech industry. Terraform is a relatively new tool with a smaller community, making support and resources more limited. vRA fits an SDDC workflow that needs VMware integrations, a self-service interface, and policy controls in one platform. Terraform fits infrastructure provisioning when the team is comfortable managing state and adding separate controls. I compared both approaches in the three-tier application walkthrough.

vSphere Resource Management with vRealize Operations (vROPs) DRS across multiple data centers is a critical requirement for managing large-scale virtualized environments. In this blog, we’ll discuss the requirements for using DRS in vROPs across multiple data centers. Cross vCenter vMotion (CVC-vMotion) Support: CVC-vMotion enables vMotion of virtual machines across multiple vCenter servers. This capability is a pre-requisite for vROPs DRS across multiple data centers. vCenter Server 6.7 Update 1 or later: vROPs DRS across multiple data centers requires vCenter Server 6.7 Update 1 or later. This ensures that the necessary APIs are available to enable vROPs to manage resources across multiple vCenter servers. Network Connectivity: All data centers should have a reliable and high-speed network connectivity, with the necessary firewall ports opened for communication between vCenter servers and vROPs instances. vROPs Replication: vROPs instances in different data centers must be able to communicate with each other. vROPs replication can be used to keep the data in all vROPs instances in sync, ensuring that the vROPs DRS decisions are based on consistent data. Same vROPs version: All vROPs instances must be running the same version of vROPs to ensure compatibility and prevent any issues with data consistency. Same vROPs license: All vROPs instances must be licensed with the same vROPs license, and the license should include the vROPs DRS capability. Cluster Configuration: The virtual machines that need to be managed by vROPs DRS must be in a vSphere cluster that spans across multiple vCenter servers. The vSphere cluster must be configured with the appropriate DRS settings, such as automated DRS, to ensure that vROPs DRS can make effective resource management decisions. In conclusion, vROPs DRS across multiple data centers is a powerful tool for managing virtualized environments at scale. By following these requirements, organizations can ensure that their vROPs DRS implementation is effective, efficient, and reliable.

The Distributed Resource Scheduler (DRS) is a key component of the vSphere platform, and is used to manage resource allocation and workload distribution within virtualized data centers. DRS works by analyzing resource utilization and workload demands of virtual machines (VMs) and making recommendations for placement and resource allocation based on a set of rules. DRS Rules in vROps In the context of vRealize Operations Manager (vROps), DRS rules play an important role in ensuring optimal performance and utilization of virtualized resources. By using vROps, administrators can monitor resource utilization and workload demands in real-time, and make informed decisions about resource allocation based on this data. ...

In this blog post I will go over the steps I took in order to to be able to query my vCenter components from SaltStack using the SDDC SaltStack Modules. The SDDC SaltStack Modules were introduced in 2011. You can find the technical release blog here. The modules can be found on GitHub here. There is also a getting quick start guide that can be found here. Installing the SaltStack VMware Modules I am using the pre packaged ova for deployment which includes most of the components however it does have some outdated packages. The first step for was to upgrade pip: ...

This historical lab procedure updated an ESXi 7.0 host to ESXi 7.0 Update 3f, build 20036589, using esxcli. The target profile and release notes are for 7.0 U3f, not 7.0 U1. More details about that release are available in the ESXi 7.0 U3f release notes. Broadcom’s build-number table records later ESXi 7 releases through Update 3w, build 24784741. Broadcom also states that vSphere 7 reached End of General Support on October 2, 2025. Use this page only as a record of the pinned lab change, not as a current release recommendation. ...

I recently ran through an issue where I wanted to automatically delete snapshots after 5 days instead of the default 7 days that comes out of box in automation central. I wanted to change delete old snapshot restriction from 7 days to 5 days. It seems like the restriction comes from the Reclaim Settings. In order to change it we can go to Optimize -> Reclaim -> Settings ...

I recently upgraded my vCenter to 7.0.3 18700403 and I noticed that when I went to Lifecycle Manager I was welcomed with this error. “Authentication failed, Lifecycle Manager server could not be contacted.” Im not aware of a fix for this issue however using the administrator@vsphere.local seems to be working.

While doing maintenance on my vSAN cluster recently I had the need to disable the vCLS in order to fully shut down the cluster. Doing some reasearch I found kb article 80472 that talk about temporarily disabling the service in order to perform maintenance. The steps are fairly easy First we need to get the Cluster id from vSphere. To do so all we need to do is select the cluster and look at the url. For example ...

I have the need to completely shut down some of my vSAN clusters for various clusters and ive been having a hard time finding the proper procedure. As of 2/16/2021 VMware released guidance here Here are the steps I took to do it on my end. If you have the vCLS service enabled follow my other instructions here prior to starting the rest of this guide. Disable cluster member updates from vCenter on each ESXi host in the cluster by running ...

While I was trying to perform an upgrade to my ESXi installation I ran in to the below error: The fix was pretty simple. The hypervisor doesn’t have enough space to download and install the package so we need to enable one of the available datastores for the function. For vCenter go to the host in question to Configure -> System -> System Swap ...