The release of VMware Cloud Director 10.3.2 brings some exciting new features for our Cloud providers. Here I will highlight the most anticipated ones, which I think many of my Cloud Providers will find appealing.

VMware Cloud Director GPU as a Service (GPUaaS)

VMware Cloud Director GPU as a Service (GPUaaS) allows customers to use the processing power of NVIDIA managed vGPU by leveraging the VMware Cloud Director without the need of purchasing dedicated high-end GPUs. The capability is focused on general purpose AI/ML with compatible Nvidia hardware. Cloud Director multi-tenanted vGPU as a Service allows cloud providers to gain more margin using Nvidia MIG (Multi-instance GPU) which achieves multitenancy boundaries between workloads at the physical level inside a single device and is a big deal for multi-tenant environment.

Providers can offer vApp templates pre-configured with all the necessary sizing policies, placement policies, GPU Profiles with the VM and guest OS enabled for vGPU and configured in the templates. This will enable tenants to consume vGPU templates in a self-service fashion.

Cloud Provider admins can meter vGPU consumption per tenant for tenant billing via API and tenants are given usage visibility and management over their vGPU derived workloads. Note that Cloud Providers must own and manage their NVIDIA GPU estate, licensing, management application install and configurations.

This is a great opportunity to our providers as GPU as a Service is a fast growing market market (CAGR of 33.6% from 2020 to 2027). GPU delivers a high-volume parallel processing structure that is far efficient than general-purpose CPU for processing large data blocks that AI and ML (amongst many other applications), rely on. GPUs are accelerating more and more areas where computing horsepower will make a difference.

vRealize Orchestrator update for VMware Cloud Director

vRealize Orchestrator update for VMware Cloud Director – Cloud Director now supports vRealize Orchestrator versions 8.6/8.5/8.4 and orchestration support for the Cloud Director REST API schema in 10.3.1, this has been compiled with support for latest JRE/JDK for Java v11.For organizations that use vRealize suite this has been a long-awaited update enabling them to upgrade to the latest Cloud Director version,

Support has been supplied for basic NSX-T workflows; NSX-T manager, Geneve Network pools, NSX-T backed provider vDC, T0 Gateways, NSX-T backed external networks and NSX-T backed edge gateway. This has been a previous blocker for some customers to advance to NSX-T where automation is necessary to provision networking components via vRealize Orchestrator. This had been requested often by partners and a step in the right direction.

VMware Cloud Director 10.3.2 Networking Updates

Tenant Org VDC customized Segment Policies. Segments are NSX-T entities providing virtual Layer 2 switching for workloads and gateway interfaces, Segment profiles include Layer 2 networking configuration details for the segments such as QoS (Quality of Service), IP Discovery, SpoofGuard, Segment Security and MAC Management. Providers can now create profile templates composed of segment profiles, these profiles can be applied to any segment on creation or as update by the Provider.

This can help address specific use cases that require customized Layer 2 configuration (e.g., Layer 2 security, QoS), decreasing operational configuration time and cost and increasing configuration consistency between NSX-T Managers.

Rate Limiting Quality of Service for Edge gateways. Cloud Providers can now deliver Edge Gateway applied to ingress and egress traffic QoS profiles for customer traffic. These profiles must be setup by the Provider in NSX-T and then can be used to apply on Edge gateways. This will improve customer application experience for key applications that are bandwidth sensitive with controls over burst rates, committed rate and token times providers can preconfigure profiles, ensuring application performance and reducing risk of manual mistakes.

Edge Gateway distributing routing bypass. Although distributed routing provides fast and efficient East-West routing, some scenarios requires the traffic to pass through the Tier-1 Gateway Services Router component. For example, if a tenant wishes to deliver East-West security between organization VDC networks connected to the same Edge Gateway.

In 10.3.2 users now have the option to disable distributed routing when creating or updating a routed organization VDC network. Prior 10.3.2, this was impossible to do since East-West traffic is always distributed, by-passing the NSX-T Service Router node altogether.  This update should help unblock automated migration from NSX-V where DNS forwarding was used at the Edge Gateway level.

<!–
–>