WilliamLam.com

Search Results for: guest operations

Custom vCenter Server Role using vSphere Terraform Provider on VMware Cloud on AWS

by // Leave a Comment

In a VMware Cloud on AWS (VMC-A) environment, a default CloudAdmin vCenter Server Role is provided to customers to manage and deploy workloads in vCenter Server. Typically, this vCenter Server Role is only granted to limited number of Cloud Administrators within your organization, which you get to control as an end user.

VMware also supports customers in creating additional custom vCenter Server Roles that limits the privileges for other usage such as auditing or workload provisioning. If you create a custom vCenter Server Role for VM provisioning and you are using vSphere Automation Tools that VMware supports including PowerCLI or even the popular vSphere Terraform Provider, you may come across the following error message during the VM deployment:

System.Read privilege required for config.distributedVirtualSwitch


As you can see from the error message, the current user does not have the Read-only privilege assigned to the Virtual Distributed Switch (VDS) which is required by the automation client, in this case the vSphere Terraform Provider, to be able to properly provisioned a VM.

Note: When using the default CloudAdmin role, VMware automatically applies the correct privileges to all applicable vSphere Inventory objects and this is the reason you do not see this problem when using an account with the default CloudAdmin role. For custom vCenter Server Roles that are created by customers, we can not apply this automation as the intention of the custom role(s) are unknown to VMware.

We can quickly fix this issue by following the instructions below which will guide you in properly assigning the correct vSphere permissions to enable VM provisioning when using a non-CloudAdmin role.

[Read more...]

Beta for VMware Cloud Consumption Interface (CCI) formally Project Cascade

by // Leave a Comment

When Project Pacific was first announced back in 2019, most of the focus was on Kubernetes and how it would be re-architected into vSphere, basically the "how" or the implementation details. As much as I enjoy diving into the tech, what really stood out to me about Project Pacific was the implication it would have on workload evolution for vSphere.

In fact, I wrote about this very topic in this blog post: Project Pacific - Workload Evolution in vSphere because I felt that most of the focus was only on the "how" but not the "why". Here is a quote from the blog that summarizes why I was excited for Project Pacific:

However, Project Pacific is actually more than just Kubernetes but with all the new lingo like Supervisor and Guest Clusters, one can easily get lost in the implementation or what I would refer to as the "how" part of Project Pacific. If you ask me, the "why" part is much more significant and Project Pacific is fundamentally re-defining what and how to deploy a workload in vSphere.

Fast forward to today, vSphere with Tanzu has been delivering on the vision of Project Pacific since its introduction with vSphere 7 back in 2020. Developers, DevOps and Platform Engineering teams can easily deploy workloads like Tanzu Kubernetes Grid Clusters (TKC) or Virtual Machines into a vSphere Cluster that has been enabled with vSphere with Tanzu, also known as a Supervisor Cluster.

While the current vSphere with Tanzu experience works well for most environments with a handful of Supervisor Clusters, but what happens when you need to support more users, teams and an increased number of Supervisor Clusters across different locations? How do you manage access control for these users and the compute resources that they can consume while providing a simple and intuitive developer ready interface? This is where VMware Cloud Consumption Interface (CCI), formally known as Project Cascade comes in!

[Read more...]

Intel NUC with 512GB memory

by // 11 Comments

Yes, you read that correctly. 512 gigabytes of memory on an Intel NUC. Not only is this pretty ? but this is actually possible today with an already released Intel NUC!

A few months back, I was made aware of some really cool technology from Intel called Intel Memory Drive Technology (IMDT) which leverages Intel Optane SSDs to extend memory of a system beyond its physical memory (DRAM) capacity. This technology is made possible with their IMDT software, which is a purpose built Hypervisor whose sole purpose is to just manage memory and this Hypervisor runs on top of the Intel Optane SSD. You can think of this like a Software-Defined Memory (SDM) solution. In fact, SDM was actually coined in this performance white paper evaluating IMDT with scientific-based applications back in 2018.

Note: This should not be confused with Intel Optane and its Datacenter Persistent Memory (PMEM) solution which vSphere already supports today.

The target use case for this type of technology is for memory intensive applications such as SAP HANA, Oracle, Redis, Memcache and Apache Spark to just name a few. These workloads can easily gobble up 10's of terabytes of memory that can bring a number of challenges when needing to scale up these solutions. High capacity memory DIMMS are not only expensive, but once you exhaust the number of physical DIMM slots, your only option for scale up is to add additional servers which is very costly.

Using IMDT, customers can expand their physical DRAM capacity from 8x to 15x, which can significantly improve cost, performance but also the operational overhead in managing  additional systems. Putting aside the in-memory based workloads, I think there is also huge potential for general purpose workloads that can also get the exact same benefits, especially when you think about constraints like power, cooling and location such as Edge or ROBO locations. Since this solution works on an Intel NUC, a really interesting use case for this technology that immediately came to mind was for a vSphere/NSX/vSAN homelab environment.

[Read more...]