VMTECHIE.blog

Author: vmtechie

  • Security VDC Architecture with VMware Cloud Director

    ​Cloud Director VDCs come with all the features you’d expect from a public cloud, Virtual Data Center is a logical representation of a physical data center, created using virtualization technologies and a virtual data center allows IT administrators to create, provision, and manage virtualized resources such as servers, storage, and networking in a flexible and efficient manner. Recently released new version of VMware Cloud Director 10.4.1 released quite a lot of new features. In this article I want to double click on to external networking…

    External Networks

    An external network is a network that is external to the VCD infrastructure, such as a physical network or a virtual network, external networks are used to connect virtual machines in VCD with the external world, allowing them to communicate with the Internet or with other networks that are not part of the VCD infrastructure

    New Features in Cloud Director 10.4.1 External Networks

    With the release of Cloud Director 10.4.1, External networks that are NSX-T Segment backed (VLAN or overlay) can now be connected directly to Org VDC Edge and does not require routed through Tier-0 or VRF the Org VDC Gateway is connected to. This connection is done via the service interface on the service node of the Tier-1 GW that is backing the Org VDC Edge GW. The Org VDC Edge GW still needs a parent Tier-0/VRF although it can be disconnected from it. here are some of the use cases some of the use cases of the external network we are going to discusses…

    • Transit connectivity across multiple Org VDC Edge Gateways to route between different Org VDCs
    • Routed connectivity via dedicated VLAN to tenant’s co-location physical servers
    • Connectivity towards Partner Service Networks
    • MPLS connectivity to direct connect while internet is accessible via shared provider gateway

    Security VDC Architecture using External Networks (transit connectivity across two Org VDC Edge Gateways)

    A Security VDC is a common strategy for connecting multiple VDCs and security VDC become single egress and ingress points as well as can deploy additional firewall etc, in below section i am showing how that can be achieved using new external network feature:

    • This is using Overlay (Geneve) backed external network
    • ​This Overlay network must be prepared by provider in NSX as well as in Cloud Director
    • ​NSX Tier-1 GW does not provide any dynamic routing capabilities, so routing to such network can be configured only via static routes
    • ​Tier-1 GW has default route (0.0.0.0/0) always pointing towards its parent Tier-0/VRF GW
    • Set default route to the segment backed external network you need to use two more specific routes. For example:
    • Ø0.0.0.0/1 next hop <IP> scope <network>
    • Ø128.0.0.0/1 next hop <IP> scope <network>

    Security VDC Architecture using External Networks – Multi-VDC

    1. Log in to the VMware Cloud Director Service Provider Admin Portal.
    2. From the top navigation bar, select Resources and click Cloud Resources.
    3. In the left pane, click External Networks and click New.

    On the Backing Type page, select NSX-T Segments and a registered NSX Manager instance to back the network, and click Next.

    Enter a name and a description for the new external network

    Select an NSX segment from the list to import and click Next. An NSX segment can be backed either by a VLAN transport zone or by an overlay transport zone

    1. Configure at least one subnet and click Next.
      1. To add a subnet, click New.
      2. Enter a gateway CIDR.
      3. To enable, select the State checkbox.
      4. Configure a static IP pool by adding at least one IP range or IP address.
      5. Click Save.
      6. (Optional) To add another subnet, repeat steps Step A to Step E.

    Review the network settings and click Finish.

    Now provider will need to go to tenant org/vdc and add above configured external network in to tenant tier1 edge and offer net new networking configuration and options.

    Other Patterns

    Routed connectivity via dedicated VLAN to tenant’s co-location physical servers or MPLS

    • This is using vLAN backed external network
    • ​This vLAN backed network must be prepared by provider in NSX as well as in Cloud Director
    • ​NSX Tier-1 GW does not provide any dynamic routing capabilities, so routing to such network can be configured only via static routes
    • ​One VLAN segment, it can be connected to only one Org VDC Edge GW
    • ​Tier-1 GW has default route (0.0.0.0/0) always pointing towards its parent Tier-0/VRF GW
    • Set default route to the segment backed external network. For example:
    • Ø172.16.50.0/24 next hop <10.10.10.1> scope <external network>

    Connectivity towards Partner Service Networks

    • This is using vLAN backed external network
    • ​This vLAN backed network must be prepared by provider in NSX as well as in Cloud Director
    • ​NSX Tier-1 GW does not provide any dynamic routing capabilities, so routing to such network can be configured only via static routes
    • ​One VLAN segment, it can be connected to only one Org VDC Edge GW
    • ​Tier-1 GW has default route (0.0.0.0/0) always pointing towards its parent Tier-0/VRF GW
    • Set static route to the segment backed external network you need to use two more specific routes. For example:
    • Ø<Service Network> next hop <Service Network Router IP> scope <External Network>

    DOWNLOAD PDF from Here

    security-vdc-vcd-10.4Download

    i hope this article helps providers offer net new additional network capabilities to your tenants. please feel free to share feedback.

  • Getting Started with VMware Cloud Director Container Service Extension 4.0

    VMware Cloud Director Container Service Extension brings Kubernetes as a service to VMware Cloud Director, offering multi-tenant, VMware supported, production ready, and compatible Kubernetes services with Tanzu Kubernetes Grid. As a service provider administrator, you can add the service to your existing VMware Cloud Director tenants. By using VMware Cloud Director Container Service Extension, customers can also use Tanzu products and services such as Tanzu® Mission Control to manage their clusters.

    Pre-requisite for Container Service Extension 4.0

    • Provider Specific Organization – Before you can configure VMware Cloud Director Container Service Extension server, it is must to create an organization to hosts VMware Cloud Director Container Service Extension server
    • Organization VDC within Organization – Container Service extension Appliance will be deployed in this organization virtual data center
    • Network connectivity – Network connectivity between the machine where VMware Cloud Director Container Service Extension is installed, and the VMware Cloud Director server. VMware Cloud Director Container Service Extension communicates with VMware Cloud Director using VMware Cloud Director public API endpoint
    • CSE 4.0 CPI automatically creates Load balancer, you must ensure that you have configured  NSX Advanced Load Balancer, NSX Cloud, and NSX Advanced Load Balancer Service Engine Group for tenants who need to create Tanzu Kubernetes Cluster.

    Provider Configuration

    With the release of VMware Cloud Director Container Service Extension 4.0, service providers can use the CSE Management tab in the Kubernetes Container Clusters UI plug-in, which demonstrate step by step process to configure the VMware Cloud Director Container Service Extension server.

    Install Kubernetes Container Clusters UI plug-in for VMware Cloud Director

    You can download the Kubernetes Container Clusters UI plug-in for the VMware Cloud Director Download Page and upload the plug-in to VMware Cloud Director.

    NOTE: If you have previously used the Kubernetes Container Clusters plug-in with VMware Cloud Director, it is necessary to deactivate it before you can activate a newer version, as only one version of the plug-in can operate at one time in VMware Cloud Director. Once you activate a new plug-in, it is necessary to refresh your Internet browser to begin using it.

    Once partner has installed plugin, The Getting Started section with in CSE Management page help providers to learn and set up VMware Cloud Director Container Service Extension in VMware Cloud Director through the Kubernetes Container Clusters UI plug-in 4.0. At very High Level this is Six Step process:

    Lets start following these steps and deploy

    Step:1 – This section links to the locations where providers can download the following two types of OVA files that are necessary for VMware Cloud Director Container Service Extension configuration:

    NOTE- Do not download FIPS enabled templates

    Step:2 – Create a catalog in VMware Cloud Director and upload VMware Cloud Director Container Service Extension OVA files that you downloaded in the step:1 into this catalog

    Step:3 – This section initiates the VMware Cloud Director Container Service Extension server configuration process. In this process, you can enter details such as software versions, proxy information, and syslog location. This workflow automatically creates a Kubernetes Clusters rights bundle, CSE Admin Role role, Kubernetes Cluster Author role, and VM sizing policies. In this process, the Kubernetes Clusters rights bundle and Kubernetes Cluster Author role are automatically published to all tenants as well as following Kubernetes resource versions will be deployed

    Kubernetes ResourcesSupported Versions
    Cloud Provider Interface (CPI)1.2.0
    Container Storage Interface (CSI)1.3.0
    CAPVCD1.0.0

    Step:4 – This section links to the Organization VDCs section in VMware Cloud Director, where you can assign VM sizing policies to customer organization VDCs. To avoid resource limit errors in clusters, it is necessary to add Tanzu Kubernetes Grid VM sizing policies to organization virtual data centers.The Tanzu Kubernetes Grid VM sizing policies are automatically created in the previous step. Policies created are as below:

    Sizing PolicyDescriptionValues
    TKG smallSmall VM sizing policy2 CPU, 4 GB memory
    TKG mediumMedium VM sizing policy2 CPU, 8 GB memory
    TKG largeLarge VM sizing policy4 CPU, 16 GB memory
    TKG extra-largeX-large VM sizing policy8 CPU, 32 GB memory

    NOTE: Providers can create more policies manually based on requirement and publish to tenants

    In VMware Cloud Director UI, select an organization VDC, and from the left panel, under Policies, select VM Sizing and Click Add and then from the data grid, select the Tanzu Kubernetes Grid sizing policy you want to add to the organization, and click OK.

    Step:5 – This section links to the Users section in VMware Cloud Director, where you can create a user with the CSE Admin Role role. This role grants administration privileges to the user for VMware Cloud Director Container Service Extension administrative purposes. You can use this user account as OVA deployment parameters when you start the VMware Cloud Director Container Service Extension server.

    Step:6 – This section links to the vApps section in VMware Cloud Director where you can create a vApp from the uploaded VMware Cloud Director Container Service Extension server OVA file to start the VMware Cloud Director Container Service Extension server.

    • Create a vApp from VMware Cloud Director Container Service Extension server OVA file.
    • Configure the VMware Cloud Director Container Service Extension server vApp deployment lease
    • Power on the VMware Cloud Director Container Service Extension server.

    Container Service Extension OVA deployment

    Enter a vApp name, optionally a description, runtime lease and storage lease (should be no lease so that it does not suspend automatically), and click Next.

    Select a virtual data center and review the default configuration for resources, compute policies, hardware, networking, and edit details where necessary.

    • In the Custom Properties window, configure the following settings:
      • VCD host: VMware Cloud Director URL
      • CSE service account’s username The username: CSE Admin user in the organization
      • CSE service account’s API Token: to generate API Token, login to provider session with CSE user which you created in Step:5 and then go to “User Preferences” and click on “NEW” in “ACCESS Tokens” section (When you generate an API Access Token, you must copy the token, because it appears only once. After you click OK, you cannot retrieve this token again, you can only revoke it. )

    • CSE service account’s org: The organization that the user with the CSE Admin role belongs to, and that the VMware Cloud Director Container Service Extension server deploys to.
    • CSE service vApp’s org: Name of the provider org where CSE app will be deployed

    In the Virtual Applications tab, in the bottom left of the vApp, click Actions > Power > Start. this completes the vApp creation from the VMware Cloud Director Container Service Extension server OVA file. This task is the final step for service providers to perform before the VMware Cloud Director Container Service Extension server can operate and start provisioning Tanzu Kubernetes Clusters.

    CSE 4.0 is packed with capabilities that address and attract developer personas with an improved feature set and simplified cluster lifecycle management. Users can now build and upgrade versions, resize, and delete K8s clusters directly from the UI making it simpler and faster to accomplish tasks than before. This completes provider section of Container Service extension in next blog post i will write about Tenant workflow.

  • Multi-Tenant Tanzu Data Services with VMware Cloud Director

    VMware Cloud Director extension for VMware Data Solutions is a plug-in for VMware Cloud Director (VCD) that enables cloud providers expand their multi-tenant cloud infrastructure platform to deliver a portfolio of on-demand caching, messaging and database software services at massive scale. This brings in new opportunity for our Cloud Providers to offer additional cloud native developer services in addition to the VCD powered Infrastructure-as-a-Service (IaaS).

    VMware Cloud Director extension for Data Solutions offers a simple tenant-facing self-service UI for the lifecycle management of below Tanzu data services with a single view across multiple instances, and with URL to individual instances for service specific management.

    Tenant Self-Service Access to Data Solutions

    Tenant users can access VMware Cloud Director extension for Data Solutions from VMware Cloud Director tenant portal

    before tenant user can deploy any of the above solution, he/she must need to prepare their Tanzu K8s clusters deployed by CSE, basically when you click on Install Operator for a Kubernetes cluster for VMware Cloud Director extension for Data Solutions, Data Solutions operator is automatically installed to this cluster and this Data Solution Operator is for life cycle management of data services, to install operator simple log in to VMware Cloud Director extension for Data Solutions from VMware Cloud Director and then:

    1. Click Settings > Kubernetes Clusters
    2. Select the Kubernetes cluster on which you want to deploy Data Services
    3. and click Install Operator.

    It takes a few minutes for the status of the cluster to change to Active.

    Deploy a Tanzu Data Services instance

    Go to Solutions and choose your required solution and click on “Launch”

    This will take you to “Instances” page there , enter the necessary details.

    • Enter the instance name.
    • Solution should have RabbitMQ selected
    • Select the Kubernetes cluster ( You can only select cluster which has Data Solutions Operator successfully installed
    • Select a solution template (T-Shirt sizes)

    To customize, for example, to configure the instance RabbitMQ Management Console or Expose Load Balancer for AMQP click Show Advanced Settings and select appropriate option.

    Monitor Instance Health using Grafana

    Tanzu Kubernetes Grid provides cluster monitoring services by implementing the open source Prometheus and Grafana projects. Tenant can use the Grafana Portal to get insights about the state of the RabbitMQ nodes and runtime. For this to work, Grafana must be installed on CSE 4 Tanzu Cluster.

    NOTE: Follow this link for Prometheus and Grafana installation on CSE Tanzu K8s clusters.

    Connecting to RabbitMQ

    Since during the deployment, i have exposed RMQ as “Expose Load Balancer for AMQP”, if you take a look in vcd load balancer configuration CSE automatically exposed RMQ as load balancer VIP and a NAT rule get created, so that you can access it from outside.

    Provider Configuration

    Before you start using VMware Cloud Director extension for Data Solutions, you must meet certain prerequisites:

    1. VMware Cloud Director version 10.3.1 or later.
    2. Container Service Extension version 4.0 or later to your VMware Cloud Director.
    3. A client machine with MacOS or Linux, which has a network connectivity to VMware Cloud Director REST endpoint.
    4. Verify that you have obtained a VMware Data Solutions account.

    Detailed instruction of installing VMware Cloud Director extension for VMware Data Solutions detailed Here.

    VMware Cloud Director extension for VMware Data Solutions comes with zero additional cost to our cloud providers. Please note that the extension does not come with a cost, however, cloud providers need to report their service consumption of Data Services which do carry a cost.

  • VMware Cloud Director Charge Back Explained

    VMware Chargeback not only enables metering and chargeback capabilities, but also provides visibility into infrastructure usage through performance and capacity dashboards for the Cloiud Providers as well as tenants.

    To help Cloud Providers and tenants realise more value for every dollar they spend on infrastructure (ROI) (and in turn provide similar value to their tenants), our focus is to not only expand the coverage of services that can be priced in VMware Chargeback, but also to provide visibility into the cost of infrastructure to providers, and billing summary to organizations, clearly highlighting the cost incurred by various business units. but before we dive in further to know what’s new with this release, please note:

    • vRealize Operations Tenant App is now rebranded to VMware Chargeback.
    • VMware Chargeback is also now available as a SaaS offering, The Software-as-a-Service (SaaS) offering will be available as early access, with limited availability, with the purchase or trial of the VMware Cloud Director™ service. See, Announcing VMware Chargeback for Managed Service Providers Blog.

    Creation of pricing policy based on chargeback strategy

    Provider administrator can create one or more pricing policies based on how they want to chargeback their tenants. Based on the vCloud Director allocation models, each pricing policy is of the type, Allocation pool, Reservation pool, or Pay-As-You-Go

    NOTE – The pricing policies apply to VMs at a minimum granularity of five minutes. The VMs that are created and deleted within the short span of five minutes will still be charged.

    CPU Rate

    Provider can charge the CPU rate based on GHz or vCPU Counts

    • Charge Period which indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on Power State indicates the pricing model based on which the charges are applied and values are: Always, Only when powered on, Powered on at least once
    • Default Base Rate any base rate that provider want to charge
    • Add Slab providers can optionally charge different rates depending on the number of vCPUs used
    • Fixed Cost Fixed costs do not depend on the units of charging

    Memory Rate

    • Charge Period which indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on indicates the pricing model based on which the charge is applied, values are: Usage, Allocation and Maximum from usage and allocation
    • Charge Based on Power State indicates the pricing model based on which the charges are applied and values are: Always, Only when powered on, Powered on at least once
    • Default Base Rate any base rate that provider want to charge
    • Add Slab providers can optionally charge different rates depending on the memory allocated
    • Fixed Cost Fixed costs do not depend on the units of charging

    Storage Rate

    You can charge for storage either based on storage policies or independent of it.

    • This way of setting rates will be deprecated in the future release and it is advisable to instead use the Storage Policy option.
    • Select the Storage Policy Name from the drop-down menu.
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on indicates the pricing model based on which the charge is applied. You can charge for used storage or configured storage of the VMs
    • Charge Based on Power State This decides if the charge should be applied based on the power state of the VM and values are: Always, Only when powered on, Powered on at least once
    • Add Slab you can optionally charge different rates depending on the storage allocated

    Network Rate

    Enter the External Network Transmit and External Network Receive rates.

    Note: If your network is backed by NSX-T, you will be charged only for the network data transmit and network data receive.

    • Network Transmit Rate select the Change Period and enter the Default Base Rate as well as using slabs, you can optionally charge different rates depending on the network data consumed
    • Network Receive Rate select the Change Period and enter the Default Base Rate. as well as using slabs, you can optionally charge different rates depending on the network data consumed. Enter valid numbers for Base Rate Slab and click Add Slab.

    Advanced Network Rate

    Under Edge Gateway Size, enter the base rates for the corresponding edge gateway sizes

    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Enter the Base Rate

    Guest OS Rate

    Use the Guest OS Rate to charge differently for different operating systems

    • Enter the Guest OS Name
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on Power State This decides if the charge should be applied based on the power state of the VM and values are: Always, Only when powered on, Powered on at least once
    • Enter the Base Rate

    Cloud Director Availability

    Cloud Director Availability is to set pricing for replications created from Cloud Director Availability

    • Replication SLA Profile – enter a replication policy name
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Enter the Base Rate

    You can also charge for the storage consumed by replication objects in the Storage Usage Charge section.This is used to set additional pricing for storage used by Cloud Director Availability replications in Cloud Director. Please note that the storage usage defined in this tab will be added additionally to the Storage Policy Base Rate

    vCenter Tag Rate

    This section is used for Any additional charges to be applied on the VMs based on their discovered Tags from vCenter. (Typical examples are Antivirus=true, SpecialSupport=true etc)

    • Enter the Tag Category and Tag Value
    • Charge based on Fixed Rate or
    • Charge based on Alternate Pricing Policy – Select the appropriate Pricing Policy
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on Power State This decides if the charge should be applied based on the power state of the VM and values are: Always, Only when powered on, Powered on at least once
    • Enter the Base Rate

    VCD Metadata Rate

    Use the VCD Metadata Rate to charge differently for different metadata set on vApps

    NOTE- Metadata based prices are available in bills only if Enable Metadata option is enabled in vRealize Operations Management Pack for VMware Cloud Director.

    • Enter the Tag Category and Tag Value
    • Charge based on Fixed Rate or
    • Charge based on Alternate Pricing Policy – Select the appropriate Pricing Policy
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
    • Charge Based on Power State This decides if the charge should be applied based on the power state of the VM and values are: Always, Only when powered on, Powered on at least once
    • Enter the Base Rate

    One Time Fixed Cost

    One time fixed cost used to charge for One time incidental charges on Virtual machines, such as creation/Setup charges, or charges for one off incidents like installation of a patch. These costs do not repeat on a recurring basis.

    For values follow VCD METADATA and vCenter Tag section.

    Rate Factors

    Rate factors are used to either bump up or discount the prices either against individual resources consumed by the Virtual Machines, or whole charges against the Virtual Machine. Some examples are:

    • Increase CPU rate by 20% (Factor 1.2) for all VMs tagged with CPUOptimized=true
    • Discount overall charge on VM by 50% (Factor 0.5) for all Vms tagged with PromotionalVM=True
    • VCD Metadata
      • enter the Tag Key and Tag Value
        • Change the price of – Total, vCPU, Memory and Storage
        • By applying a factor of – increase or decrease the price by entering a valid number
    • vCenter Tag
      • enter the Tag Key and Tag Value
        • Change the price of – Total, vCPU, Memory and Storage
        • By applying a factor of – increase or decrease the price by entering a valid number

    Tanzu Kubernetes Clusters

    This section will be used to charge for Tanzu K8s clusters and objects.

    • Cluster Fixed Cost
    • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
      • Fixed Cost Fixed costs do not depend on the units of charging
    • Cluster CPU Rate
      • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
      • Charge Based on this decides if the charge should be applied based on Usage or Allocation
      • Default Base Rate(per ghz)
    • Cluster Memory Rate
      • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
      • Charge Based on this decides if the charge should be applied based on Usage or Allocation
      • Default Base Rate(per gb)

    Additional Fixed Cost

    You can use Additional Fixed Cost section to charge at the Org-VDC level. You can use this for charges such as overall tax, overall discounts, and so on. The charges can be applied to selective Org-VDCs based on Org-VDC metadata.

    • Fixed Cost
      • Charge Period indicates the frequency of charging and values are: Hourly, Daily Monthly
      • Fixed Cost
    • VCD Metadata – enter the Tag Key and Tag Value
    • VCD Metadata One Time – enter the Tag Key and Tag Value

    Apply Policy

    Cloud Director Charge Back provides flexibility to the Service Providers to map the created pricing policies with specific organization vDC. By doing this, the service provider can holistically define how each of their customers can be charged based on resource types.

    Bills

    Every tenant/customer of service provider can see/review their bills using the Cloud Director Charge Back app. Service Provider administrator can generate bills for a tenant by selecting a specific resource and a pricing policy that must be applied for a defined period and can also log in to review the bill details.

    This completes the feature demonstration available with Cloud Director Charge back. Go ahead and deploy and add native charge back power to your Cloud. 

  • NFS DataStore on VMware Cloud on AWS using Amazon FSx for NetApp


    Amazon FSx for NetApp ONTAP integration with VMware Cloud on AWS is an AWS-managed external NFS datastore built on NetApp’s ONTAP file system that can be attached to a cluster in your SDDC. It provides customers with flexible, high-performance virtualized storage infrastructure that scales independently of compute resources.

    PROCESS

    • Make sure SDDC has been deployed on VMware Cloud on AWS with version 1.20
    • The SDDC is added to an SDDC Group. While creating the SDDC Group, a VMware Managed Transit Gateway (vTGW) is automatically deployed and configured
    • A Multi-AZ file system powered by Amazon FSx for NetApp ONTAP is deployed across two AWS Availability Zones (AZs). (You can also deploy in single AZ but not recommended for production)

    DEPLOY VMWARE MANAGED TRANSIT GATEWAY

    To use FSx for ONTAP as an external datastore, an SDDC must be a member of an SDDC group so that it can use the group’s vTGW and to configure you must be logged into the VMC console as a user with a VMC service role of Administrator and follow below steps:

    • Log in to the VMC Console and go on the Inventory page, click SDDC Groups
    • On the SDDC Groups tab, click ACTIONS and select Create SDDC Group
    • Give the group a Name and optional Description, then click NEXT
    • On the Membership grid, select the SDDCs to include as group members.The grid displays a list of all SDDCs in your organization. To qualify for membership in the group, an SDDC must meet several criteria:
      • It must be at SDDC version 1.11 or later. Members of a multi-region group must be at SDDC version 1.15 or later.
      • Its management network CIDR block cannot overlap the management CIDR block of any other group member.
      • It cannot be a member of another SDDC Group.
      When you have finished selecting members, click NEXT. You can edit the group later to add or remove members.
    • Acknowledge that you understand and take responsibility for the costs you incur when you create an SDDC group, then click CREATE GROUP to create the SDDC Group and its VMware Transit Connect network.

    ATTACH VPC TO VMWARE MANAGED TRANSIT GATEWAY

    After the SDDC Group is created, it shows up in your list of SDDC Groups. Select the SDDC Group, and then go to the External VPC tab and click on ADD ACCOUNT button, then provide the AWS account that will be used to provision the FSx file system, and then click Add.

    Now it’s time for you to go back to the AWS console and sign in to the same AWS account where you will create Amazon FSx file system. Here navigate to the Resource Access Manager service page and

    click on the Accept resource share button.

    Next, we need to attach VMC Transit Gateway to the FSX VPC, for that you need to go to:

    ATTACH VMWARE MANAGED TRANSIT GATEWAY TO VPC

    • Open the Amazon VPC console and navigate to Transit Gateway Attachments.
    • Choose Create transit gateway attachment
    • For Name tag, optionally enter a name for the transit gateway attachment.
    • For Transit gateway ID, choose the transit gateway for the attachment, make sure you choose a transit gateway that was shared with you.
    • For Attachment type, choose VPC.
    • For VPC ID, choose the VPC to attach to the transit gateway.This VPC must have at least one subnet associated with it.
    • For Subnet IDs, select one subnet for each Availability Zone to be used by the transit gateway to route traffic. You must select at least one subnet. You can select only one subnet per Availability Zone.
    • Choose Create transit gateway attachment.

    Accept the Transit Gateway attachment as follows:

    • Navigating back to the SDDC Group, External VPC tab, select the AWS account ID used for creating your FSx NetApp ONTAP, and click Accept. This process takes some time..
    • Next, you need to add the routes so that the SDDC can see the FSx file system. This is done on the same External VPC tab, where you will find a table with the VPC. In that table, there is a button called Add Routes. In the Add Route section, add the CIDR of your VPC where the FSX will be deployed.

    In the AWS console, create the route back to the SDDC by locating VPC on the VPC service page and navigating to the Route Table as seen below.

    also ensure that you have the correct inbound rules for the SDDC Group CIDR to allow the inbound rules for SDDC Group CIDR. it this case i am using entire SDDC CIDR, Further to this Security Group, the ENI Security Group also needs the NFS port ranges adding as inbound and outbound rules to allow communication between VMware Cloud on AWS and the FSx service.

    Deploy FSx for NetApp ONTAP file system in your AWS account

    Next step is to create an FSx for NetApp ONTAP file system in your AWS account. To connect FSx to VMware cloud on AWS SDDC, we have two options:

    • Either create a new Amazon VPC under the same connected AWS account and connect it using VMware Transit Connect.
    • or Create a new AWS account in the same region as well as VPC, connect it using VMware Transit Connect.

    In this blog, i am deploying in the same connected VPC and for it to deploy, Go to Amazon FSx service page, click on Create File System and on the Select file system type page, select Amazon FSx for NetApp ONTAP,

    On Next page, select the Standard create method and enter require details like:

    • Select Deployment type (Multi-AZ) and Storage capacity
    • Select correct VPC, Security group and Subnet

    After the file system is created, check the NFS IP address under the Storage virtual machines tab. The NFS IP address is the floating IP that is used to manage access between file system nodes, and this IP we will use to configuring in VMware Transit Connect to allow access volume from SDDC.

    we are done with creating the FSx for NetApp ONTAP file system.

    MOUNT NFS EXTERNAL STORAGE TO SDDC Cluster

    Now it’s time for you to go back to the VMware Cloud on AWS console and open the Storage tab of your SDDC. Click ATTACH DATASTORE and fill in the required values.

    • Select a cluster. Cluster-1 is preselected if there are no other clusters.
    • Choose Attach a new datastore
    • The NFS IP address shown in the Endpoints section of the FSx Storage Virtual Machine tab. Click VALIDATE to validate the address and retrieve the list of mount points (NFS exports) from the server.

    • Pick one from the list of mount points exported by the server at the NFS server address. Each mount point must be added as a separate datastore
    • AWS FSx ONTAP
    • Give the datastore a name. Datastore names must be unique within an SDDC.
      • Click on ATTACH DATASTORE

    VMware Cloud on AWS supports external storage starting with SDDC version 1.20. To request an upgrade to an existing SDDC, please contact VMware support or notify your Customer Success Manager.

  • Cross-Cloud Disaster Recovery with VMware Cloud on AWS and Azure VMware Solution

    Disaster Recovery is an important aspect of any cloud deployment. It is always possible that an entire cloud data center or region of the cloud provider goes down. This has already happened to most cloud providers like Amazon AWS, Microsoft Azure, Google Cloud and will surely happen again in future. Cloud providers like Amazon AWS, Microsoft Azure and Google Cloud will readily suggest that you have a Disaster Recovery and Business Continuity strategy that spans across multiple regions, so that if a single geographic region goes down, business can continue to operate from another region. This only sounds good in theory, but there are several issues in the methodology of using the another region of a single cloud provider. Some of the key reasons which I think that single cloud provider’s Cross-Region DR will not be that effective.

    • A single Cloud Region failure might cause huge capacity issues for other regions used as DR
    • Cloud regions are not fully independent , like AWS RDS allows read replicas in other regions but one wrong entry will get replicated across read replicas which breaks the notion of “Cloud regions are independent“
    • Data is better protected from accidental deletions when stored across clouds. For Example what if any malicious code or an employee or cloud providers employee runs a script which deletes all the data but in most cases this will not impact cross cloud.

    In this blog post we will see how VMware cross cloud disaster recovery solution can help customers/partners to overcome BC/DR challenges.

    Deployment Architecture

    Here is my deployment architecture and connectivity:

    • One VMware Cloud on AWS SDDC
    • One Azure VMware Solution SDDC
    • Both SDDC’s are connected over MegaPort MCR

    Activate VMware Site Recovery on VMware Cloud on AWS

    To configure site recovery on VMware Cloud on AWS SDDC, go to SDDC page, click on the Add Ons tab and under the Site Recovery Add On, Click the ACTIVATE button

    In the pop up window Click ACTIVATE again

    This will deploy SRM on SDDC, wait for it to finish.

    Deploy VMware Site Recovery Manager on Azure VMware Solution

    In your Azure VMware Solution private cloud, under Manage, select Add-ons > Disaster recovery and click on “Get Started”

    From the Disaster Recovery Solution drop-down, select VMware Site Recovery Manager (SRM) and provide the License key, select agree with terms and conditions, and then select Install

    After the SRM appliance installs successfully, you’ll need to install the vSphere Replication appliances. Each replication server accommodates up to 200 protected VMs. Scale in or scale out as per your needs.

    Move the vSphere server slider to indicate the number of replication servers you want based on the number of VMs to be protected. Then select Install

    Once installed, verify that both SRM and the vSphere Replication appliances are installed.After installing VMware SRM and vSphere Replication, you need to complete the configuration and site pairing in vCenter Server.

    1. Sign in to vCenter Server as cloudadmin@vsphere.local.
    2. Navigate to Site Recovery, check the status of both vSphere Replication and VMware SRM, and then select OPEN Site Recovery to launch the client.

    Configure site pairing in vCenter Server

    Before starting site pair, make sure firewall rules between VMware cloud on AWS and Azure VMware solution has been opened as described Here and Here

    To start pairing select NEW SITE PAIR in the Site Recovery (SR) client in the new tab that opens.

    Enter the remote site details, and then select FIND VCENTER SERVER INSTANCES and select then select Remote vCenter and click on NEXT, At this point, the client should discover the VRM and SRM appliances on both sides as services to pair.

    Select the appliances to pair and then select NEXT.

    Review the settings and then select FINISH. If successful, the client displays another panel for the pairing. However, if unsuccessful, an alarm will be reported.

    After you’ve created the site pairing, you can now view the site pairs and other related details as well as you are ready to plan for Disaster Recovery.

    Planning

    Mappings allow you to specify how Site Recovery Manager maps virtual machine resources on the protected site to resources on the recovery site, You can configure site-wide mappings to map objects in the vCenter Server inventory on the protected site to corresponding objects in the vCenter Server inventory on the recovery site.

    • Network Mapping
    • IP Customization
    • Folder Mapping
    • Resource Mapping
    • Storage Policy Mapping
    • Placeholder Datastores

    Creating Protection Groups

    A protection group is a collection of virtual machines that the Site Recovery Manager protects together. Protection group are per SDDC configuration and needs to be created on each SDDC if VMs are replicated in bi-directionally.

    Recovery Plan

    A recovery plan is like an automated run book. It controls every step of the recovery process, including the order in which Site Recovery Manager powers on and powers off virtual machines, the network addresses that recovered virtual machines use, and so on. Recovery plans are flexible and customizable.

    A recovery plan runs a series of steps that must be performed in a specific order for a given workflow such as a planned migration or re-protection. You cannot change the order or purpose of the steps, but you can insert your own steps that display messages and run commands.

    A recovery plan includes one or more protection groups. Conversely, you can include a protection group in more than one recovery plan. For example, you can create one recovery plan to handle a planned migration of services from the protected site to the recovery site for the whole SDDC and another set of plans per individual departments. Thus, having multiple recovery plans referencing one protection group allows you to decide how to perform recovery.

    Steps to add a VM for replication:

    there are multiple ways, i am explaining here one:

    • Choose VM and right click on it and select All Site Recovery actions and click on Configure Replication
    • Choose Target site and replication server to handle replication
    • VM validation happens and then choose Target datastore
    • under Replication setting , choose RPO, point in time instances etc..
    • Choose protection group to which you want to add this VM and check summary and click Finish

    Cross-cloud disaster recovery ensures one of the most secure and reliable solutions for service availability, reason cross-cloud disaster recovery is often the best route for businesses is that it provides IT resilience and business continuity. This continuity is of most important when considering how companies operate, how customers and clients rely on them for continuous service and when looking at your company’s critical data, which you do not want to be exposed or compromised.

    Frankly speaking IT disasters happen and happens everywhere including public clouds and much more frequently than you might think. When they occur, they present stressful situations which require fast action. Even with a strategic method for addressing these occurrences in place, it can seem to spin out of control. Even when posed with these situations, IT leaders must keep face, remain calm and be able to fully rely on the system they have in place or partner they are working with for disaster recovery measures.

    Customer/Partner with VMware Cloud on AWS and Azure VMware Solution can build cross cloud disaster recovery solution to simplify disaster recovery with the only VMware-integrated solution that runs on any cloud. VMware Site Recovery Manager (SRM) provides policy-based management, minimizes downtime in case of disasters via automated orchestration, and enables non-disruptive testing of your disaster recovery plans.

  • AI/ML with VMware Cloud Director

    AI/ML—short for artificial intelligence (AI) and machine learning (ML)—represents an important evolution in computer science and data processing that is quickly transforming a vast array of industries.

    Why is AI/ML important?

    it’s no secret that data is an increasingly important business asset, with the amount of data generated and stored globally growing at an exponential rate. Of course, collecting data is pointless if you don’t do anything with it, but these enormous floods of data are simply unmanageable without automated systems to help.

    Artificial intelligence, machine learning and deep learning give organizations a way to extract value out of the troves of data they collect, delivering business insights, automating tasks and advancing system capabilities. AI/ML has the potential to transform all aspects of a business by helping them achieve measurable outcomes including:

    • Increasing customer satisfaction
    • Offering differentiated digital services
    • Optimizing existing business services
    • Automating business operations
    • Increasing revenue
    • Reducing costs

    As modern applications become more prolific, Cloud Providers need to address the increasing customer demand for accelerated computing that typically requires large volumes of multiple, simultaneous computation that can be met with GPU capability.

    Cloud Providers can now leverage vSphere support for NVIDIA GPUs and NVIDIA AI Enterprise (a cloud-native software suite for the development and deployment of AI and has been optimized and certified for VMware vSphere), This enables vSphere capabilities like vMotion from within Cloud Director to now deliver multi-tenancy GPU services which are key to maximizing GPU resource utilization. With Cloud Director support for the NVIDIA AI Enterprise software suite, customers now have access to best-in-class, GPU optimized AI frameworks and tools and to deliver compute intensive workloads including artificial intelligence (AI) or machine learning (ML) applications within their datacenters.

    This solution with NVIDIA takes advantage of NVIDIA MIG (Multi-instance GPU) which supports spatial segmentation between workloads at the physical level inside a single device and is a big deal for multi-tenant environments driving better optimization of hardware and increased margins. Cloud Director is reliant on host pre-configuration for GPU services included in NVIDIA AI Enterprise which contains vGPU technology to enable deployment/configuration on hosts and GPU profiles.

    Customers can self serve, manage and monitor their GPU accelerated hosts and virtual machines within Cloud Director. Cloud Providers are able to monitor (through vCloud API and UI dashboard) NVIDIA vGPU allocation, usage per VDC and per VM to optimize utilization and meter/bill (through vCloud API) NVIDIA vGPU usage averaged over a unit of time per tenant for tenant billing.

    Provider Workflow

    • Add GPU devices to ESXi hosts in vCenter and install required drivers. 
    • Verify vGPU profiles are visible by going in to vCD provider portal → Resources → Infrastructure Resources → vGPU Profiles
    • Edit vGPU profiles to provide necessary tenant facing instructions and a tenant facing name to each vGPU profile. (Optional)
    • Create a PVDC backed by one or more clusters having GPU hosts in vCenter.
    • In provider portal → Cloud Resources → vGPU Policies → Create a new vGPU policy by following the wizards steps.

    Tenant Workflow

    When you create a vGPU policy, it is not visible to tenants. You can publish a vGPU policy to an organization VDC to make it available to tenants.

    Publishing a vGPU policy to an organization VDC makes the policy visible to tenants. The tenant can select the policy when they create a new standalone VM or a VM from a template, edit a VM, add a VM to a vApp, and create a vApp from a vApp template. You cannot delete a vGPU policy that is available to tenants.

    • Publish the vGPU policy to one or more tenant VDCs similar to the way we publish sizing and placement policies.
    • Create a new VM or instantiate a VM from template. In vGPU enabled VDCs, tenants can now select a vGPU policy

    Cloud Director not only allows for VMs but providers can also leverage cloud director’s Container Service Extension to offer GPU enabled Tanzu Kubernetes Clusters.

    Step-by-Step Configuration

    Below video covers step-by-step process of configuring provider and tenant side of configuration as well as deploying Tensor flow GPU in to a VM.

  • Persistent Volumes for Tanzu on VMware Cloud on AWS using Amazon FSx for NetApp ONTAP

    Amazon FSx for NetApp ONTAP provides fully managed shared storage in the AWS Cloud with the popular data access and management capabilities of ONTAP and this blog post we are going to use these volumes mount as Persistent Volumes on Tanzu Kubernetes Clusters running on VMware Cloud on AWS

    With Amazon FSx for NetApp ONTAP, you pay only for the resources you use. There are no minimum fees or set-up charges. There are five Amazon FSx for NetApp ONTAP components to consider when storing and managing your data: SSD storage, SSD IOPS, capacity pool usage, throughput capacity, and backups.

    The Amazon FSx console has two options for creating a file system – Quick create option and Standard create option. To rapidly and easily create an Amazon FSx for NetApp ONTAP file system with the service recommended configuration, I use the Quick create option.

    The Quick create option creates a file system with a single storage virtual machine (SVM) and one volume. The Quick create option configures this file system to allow data access from Linux instances over the Network File System (NFS) protocol.

    In the Quick configuration section, for File system name – optional, enter a name for your file system.

    For Deployment type choose Multi-AZ or Single-AZ.

    • Multi-AZ file systems replicate your data and support failover across multiple Availablity Zones in the same AWS Region.
    • Single-AZ file systems replicate your data and offer automatic failover within a single Availability Zone, for this post i am creating in Single AZ
    • SSD storage capacity, specify the storage capacity of your file system, in gibibytes (GiBs). Enter any whole number in the range of 1,024–196,608.
    • For Virtual Private Cloud (VPC), choose the Amazon VPC that is associate with your VMware Cloud on AWS SDDC.

    Review the file system configuration shown on the Create ONTAP file system page. For your reference, note which file system settings you can modify after the file system is created.

    Choose Create file system.

    Quick create creates a file system with one SVM (named fsx) and one volume (named vol1). The volume has a junction path of /vol1 and a capacity pool tiering policy of Auto.

    For us to use this SVM, we need to get the IP address of SVM for NFS , Click on SVM ID and take a note of this IP, we will use this IP in our NFS configurations for Tanzu.

    Kubernetes NFS-Client Provisioner

    NFS subdir external provisioner is an automatic provisioner that use your existing and already configured NFS server to support dynamic provisioning of Kubernetes Persistent Volumes via Persistent Volume Claims. Persistent volumes are provisioned as ${namespace}-${pvcName}-${pvName}.

    More Details – Explained here in detail https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner 

    I am deploying this on my Tanzu Kubernetes cluster which is deployed on VMware Cloud on AWS.

    • Add the helm repo – 
    #helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
    • Install using as below:
    #helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=<IP address of Service> \
    --set nfs.path=/<Volume Name>
#My command will be like this#
#helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=172.31.1.234 \
    --set nfs.path=/vol1

    Post installation of chart, you can check the status of Pod, it is not in running state then describe and see where it stuck

    Finally, Test Your Environment!

    Now we’ll test your NFS subdir external provisioner by creating a persistent volume claim and a pod that writes a test file to the volume. This will make sure that the provisioner is provisioning and that the Amazon FSx for NetApp ONTAP service is reachable and writable.

    As you can see deployed application created an PV and PVC successfully on Amazon FSx for NetApp ONTAP

    Describe the Persistent Volume to see the source of it, as you can see below it is created on NFS running on SVM having IP – 172.31.1.234

    This is the power of VMware Cloud on AWS and AWS native services, customers can use any AWS native service without worrying about egress charges as well as security as everything is being configured and accessed over the private connections.

  • Building Windows Custom Machine Image for Creating Tanzu Workload Clusters

    If your organisation is building an application based on Windows components (such as .NET Framework) and willing to deploy Windows containers on VMware Tanzu, this blog post is on how to build a Windows custom machine image and deploy windows Kubernetes cluster.

    Windows Image Prerequisites 

    • vSphere 6.7 Update 3 or greater
    • A macOS or Linux workstation, Docker Desktop and Ansible must be installed on workstation
    • Tanzu Kubernetes Grid v1.5.x or greater
    • Tanzu CLI
    • A Recent Image of Windows 2019 (newer than April 2021) and must be downloaded from Microsoft Developer Network (MSDN) or Volume Licensing (VL) account.
    • The latest VMware Tools Windows ISO image. Download from VMware Tools
    • on vCenter, Inside a data store create a folder such as iso and upload windows ISO and VMware Tools iso

    Build a Windows Image 

    • Deploy Tanzu Management Cluster with Ubuntu 2004 Kubernetes v1.22.9 OVA
    • Create a YAML file named builder.yaml with the following configuration, On my local system I have saved this yaml as builder.yaml
    apiVersion: v1
kind: Namespace
metadata:
 name: imagebuilder
---
apiVersion: v1
kind: Service
metadata:
 name: imagebuilder-wrs
 namespace: imagebuilder
spec:
 selector:
   app: image-builder-resource-kit
 type: NodePort
 ports:
 - port: 3000
   targetPort: 3000
   nodePort: 30008
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: image-builder-resource-kit
 namespace: imagebuilder
spec:
 selector:
   matchLabels:
     app: image-builder-resource-kit
 template:
   metadata:
     labels:
       app: image-builder-resource-kit
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
     - name: windows-imagebuilder-resourcekit
       image: projects.registry.vmware.com/tkg/windows-resource-bundle:v1.22.9_vmware.1-tkg.1
       imagePullPolicy: Always
       ports:
         - containerPort: 3000

    Connect the Kubernetes CLI to your management cluster by running:

    #kubectl config use-context MY-MGMT-CLUSTER-admin@MY-MGMT-CLUSTER

    Apply the builder.yaml file as below:

    To ensure the container is running run below command:

    List the cluster’s nodes, with wide output and take note of Internal IP address value of the node with ROLE listed as control-plane,master

    #kubectl get nodes -o wide

    Retrieve the containerd component’s URL and SHA, Query the control plane’s  nodePort  endpoint:

    #curl http://CONTROLPLANENODE-IP:30008

    Take note of containerd.path and containerd.sha256 values. The containerd.path value ends with something like containerd/cri-containerd-v1.5.9+vmware.2.windows-amd64.tar.

    Create a JSON file in an empty folder named windows.json with the following configuration:

    {
 "unattend_timezone": "WINDOWS-TIMEZONE",
 "windows_updates_categories": "CriticalUpdates SecurityUpdates UpdateRollups",
 "windows_updates_kbs": "",
 "kubernetes_semver": "v1.22.9",
 "cluster": "VSPHERE-CLUSTER-NAME",
 "template": "",
 "password": "VCENTER-PASSWORD",
 "folder": "",
 "runtime": "containerd",
 "username": "VCENTER-USERNAME",
 "datastore": "DATASTORE-NAME",
 "datacenter": "DATACENTER-NAME",
 "convert_to_template": "true",
 "vmtools_iso_path": "VMTOOLS-ISO-PATH",
 "insecure_connection": "true",
 "disable_hypervisor": "false",
 "network": "NETWORK",
 "linked_clone": "false",
 "os_iso_path": "OS-ISO-PATH",
 "resource_pool": "",
 "vcenter_server": "VCENTER-IP",
 "create_snapshot": "false",
 "netbios_host_name_compatibility": "false",
 "kubernetes_base_url": "http://CONTROLPLANE-IP:30008/files/kubernetes/",
 "containerd_url": "CONTAINERD-URL",
 "containerd_sha256_windows": "CONTAINERD-SHA",
 "pause_image": "mcr.microsoft.com/oss/kubernetes/pause:3.5",
 "prepull": "false",
 "additional_prepull_images": "mcr.microsoft.com/windows/servercore:ltsc2019",
 "additional_download_files": "",
 "additional_executables": "true",
 "additional_executables_destination_path": "c:/k/antrea/",
 "additional_executables_list": "http://CONTROLPLANE-IP:30008/files/antrea-windows/antrea-windows-advanced.zip",
 "load_additional_components": "true"
}

    update the values in file as below:

    Add the XML file that contains the Windows settings by following these steps:

    • Go to the autounattend.xml file on VMware {code} Sample Exchange.
    • Select Download.
    • If you are using the Windows Server 2019 evaluation version, remove <ProductKey>...</ProductKey>.
    • Name the file autounattend.xml.
    • Save the file in the same folder as the windows.json file and change permission of file to 777.

    From your client VM run following command from folder containing your windows.json and autounattend.xml file:

    #docker run -it --rm --mount type=bind,source=$(pwd)/windows.json,target=/windows.json --mount type=bind,source=$(pwd)/autounattend.xml,target=/home/imagebuilder/packer/ova/windows/windows-2019/autounattend.xml -e PACKER_VAR_FILES="/windows.json" -e IB_OVFTOOL=1 -e IB_OVFTOOL_ARGS='--skipManifestCheck' -e PACKER_FLAGS='-force -on-error=ask' -t projects.registry.vmware.com/tkg/image-builder:v0.1.11_vmware.3 build-node-ova-vsphere-windows-2019

    NOTE: Before you run below command, make sure your workstation is running “Docker Desktop” as well “Ansible”

    To ensure the Windows image is ready to use, select your host or cluster in vCenter, select the VMs tab, then select VM Templates to see the Windows image listed.

    Use a Windows Image for a Workload Cluster

    Use a Windows Image for a Workload Cluster, below yaml shows you how to deploy a workload cluster that uses your Windows image as a template. (This windows cluster is using NSX Advance LB)

    #! ---------------------------------------------------------------------
#! non proxy env configs
#! ---------------------------------------------------------------------
CLUSTER_CIDR: 100.96.0.0/11
CLUSTER_NAME: tkg-workload02
CLUSTER_PLAN: dev
ENABLE_CEIP_PARTICIPATION: 'true'
IS_WINDOWS_WORKLOAD_CLUSTER: "true"
VSPHERE_WINDOWS_TEMPLATE: windows-2019-kube-v1.22.5
ENABLE_MHC: "false"

IDENTITY_MANAGEMENT_TYPE: oidc

INFRASTRUCTURE_PROVIDER: vsphere
SERVICE_CIDR: 100.64.0.0/13
TKG_HTTP_PROXY_ENABLED: false
DEPLOY_TKG_ON_VSPHERE7: 'true'
VSPHERE_DATACENTER: /SDDC-Datacenter
VSPHERE_DATASTORE: WorkloadDatastore
VSPHERE_FOLDER: /SDDC-Datacenter/vm/tkg-vmc-workload
VSPHERE_NETWORK: /SDDC-Datacenter/network/tkgvmc-workload-segment01
VSPHERE_PASSWORD: <encoded:T1V3WXpkbStlLUlDOTBG>
VSPHERE_RESOURCE_POOL: /SDDC-Datacenter/host/Cluster-1/Resources/Compute-ResourcePool/Tanzu/tkg-vmc-workload
VSPHERE_SERVER: 10.97.1.196
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa....loudadmin@vmc.local

VSPHERE_USERNAME: cloudadmin@vmc.local
WORKER_MACHINE_COUNT: 3
VSPHERE_INSECURE: 'true'
ENABLE_AUDIT_LOGGING: 'true'
ENABLE_DEFAULT_STORAGE_CLASS: 'true'
ENABLE_AUTOSCALER: false
AVI_CONTROL_PLANE_HA_PROVIDER: 'true'
OS_ARCH: amd64
OS_NAME: photon
OS_VERSION: 3

WORKER_SIZE: small
CONTROLPLANE_SIZE: large
REMOVE_CP_TAINT: "true"

    if your cluster yaml file is correct, you should see that new windows cluster has been started to deploy.

    and after some time if should deploy cluster sucessfully.

    In case if you are using NSX-ALB AKO or Pinniped and see that those pods are not running, please refer Here

    NOTE – if you see this error during image build process : Permission denied: ‘./packer/ova/windows/windows-2019/autounattend.xml, check the permission of file autounattend.yaml

  • Cloud Director OIDC Configuration using OKTA IDP

    OpenID Connect (OIDC) is an industry-standard authentication layer built on top of the OAuth 2.0 authorization protocol. The OAuth 2.0 protocol provides security through scoped access tokens, and OIDC provides user authentication and single sign-on (SSO) functionality. For more refer here (https://datatracker.ietf.org/doc/html/rfc6749). There are two main types of authentication that you can perform with Okta:

    • The OAuth 2.0 protocol controls authorization to access a protected resource, like your web app, native app, or API service.
    • The OpenID Connect (OIDC) protocol is built on the OAuth 2.0 protocol and helps authenticate users and convey information about them. It’s also more opinionated than plain OAuth 2.0, for example in its scope definitions.

    So If you want to import users and groups from an OpenID Connect (OIDC) identity provider to your Cloud Director system (provider) or Tenant organization, you must configure provider/tenant organization with this OIDC identity provider. Imported users can log in to the system/tenant organization with the credentials established in the OIDC identity provider.

    We can use VMware Workspace ONE Access (VIDM) or any public identity providers, but make sure OAuth authentication endpoint must be reachable from the VMware Cloud Director cells.in this blog post we will use OKTA OIDC and configure VMware Cloud to use this OIDC for authentication.

    Step:1 – Configure OKTA OIDC

    For this blog post, i created an developer account on OKTA at this url –https://developer.okta.com/signup and once account is ready, follow below steps to add cloud director as an application in OKTA console:

    • In the Admin Console, go to Applications > Applications.
    • Click Create App Integration.
    • To create an OIDC app integration, select OIDC – OpenID Connect as the Sign-in method.
    • Choose what type of application you plan to integrate with Okta, in Cloud Director case Select Web Application.
    • App integration name: Specify a name for Cloud Director
    • Logo (Optional): Add a logo to accompany your app integration in the Okta org
    • Grant type: Select from the different grant type options
    • Sign-in redirect URIs: The Sign-in redirect URI is where Okta sends the authentication response and ID token for the sign-in request, in our case for provider https://<vcd url>/login/oauth?service=provider and incase if you are doing it for tenant then use https://<vcd url>/login/oauth?service=tenant:<org name>
    • Sign-out redirect URIs: After your application contacts Okta to close the user session, Okta redirects the user to this URI.
    • Assignments: Controlled access: The default access option assigns and grants login access to this new app integration for everyone in your Okta org or you can choose to Limit access to selected groups

    Click Save. This action creates the app integration and opens the settings page to configure additional options.

    The Client Credentials section has the Client ID and Client secret values for Cloud Director integration, Copy both the values as we enter these in Cloud Director.

    The General Settings section has the Okta Domain, for Cloud Director integration, Copy this value as we enter these in Cloud Director.

    Step:2 – Cloud Director OIDC Configuration

    Now I am going to configure OIDC authentication for provider side of cloud provider and with very minor changes (tenant URL) it can be configured for tenants too.

    Let’s go to Cloud Director and from the top navigation bar, select Administration and on the left panel, under Identity Providers, click OIDC and click CONFIGURE

    General: Make sure that OpenID Connect  Status is active, and enter the client ID and client secret information from the OKTA App registration which we captured above.

    To use the information from a well-known endpoint to automatically fill in the configuration information, turn on the Configuration Discovery toggle and enter a URL, for OKTA the URL would look this – https://<domain.okta.com>/.well-known/openid-configuration and click on NEXT

    Endpoint: Clicking on NEXT will populate “Endpoint” information automatically, it is however, essential that the information is reviewed and confirmed. 

    Scopes: VMware Cloud Director uses the scopes to authorize access to user details. When a client requests an access token, the scopes define the permissions that this token has to access user information.enter the scope information, and click Next.

    Claims: You can use this section to map the information VMware Cloud Director gets from the user info endpoint to specific claims. The claims are strings for the field names in the VMware Cloud Director response

    This is the most critical piece of configuration. Mapping of this information is essential for VCD to interpret the token/user information correctly during the login process.

    For OKTA developer account, user name is email id, so i am mapping Subject to email as below

    Key Configuration:

    OIDC uses a public key cryptography mechanism.A private key is used by the OIDC provider to sign the JWT Token and it can be verified by a 3rd party using the public keys published on the OIDC provider’s well-known URL.These keys form the basis of security between the parties. For security to be maintained, this is required to keep the private keys protected from any cyber-attacks.One of the best practices that has been identified to secure the keys from being compromised is known as key rollover or key Refresh.

    From VMware Cloud Director 10.3.2 and above, if you want VMware Cloud Director to automatically refresh the OIDC key configurations, turn on the Automatic Key Refresh toggle.

    • Key Refresh Endpoint should get populated automatically as we choose auto discovery.
    • Select a Key Refresh Strategy.
      • Add – Preferred option, add the incoming set of keys to the existing set of keys. All keys in the merged set are valid and usable.
      • Replace – Replace the existing set of keys with the incoming set of keys.
      • Expire After – You can configure an overlap period between the existing and incoming sets of keys. You can configure the overlapping time using the Expire Key After Period, which you can set in hourly increments from 1 hour up to 1 day.

    If you did not use Configuration Discovery in Step 6, upload the private key that the identity provider uses to sign its tokens and click on SAVE

    Now go to Cloud Director, under Users, Click on IMPORT USERS and choose Source as “OIDC” and add user which is there in OKTA and Assign Role to that user, thats it.

    Now you can logout from the vCD console and try to login again, Cloud Director automatically redirects to OKTA and asks for credential to validate.

    Once the user is authenticated by Okta, they will be redirected back to VCD and granted access per rights associated with the role that was assigned when the user was provisioned.

    Verify that the Last Run and the Last Successful Run are identical. The runs start at the beginning of the hour. The Last Run is the time stamp of the last key refresh attempt. The Last Successful Run is the time stamp of the last successful key refresh. If the time stamps are different, the automatic key refresh is failing and you can diagnose the problem by reviewing the audit events. (This is only applicable if Automatic Key Refresh is enabled. Otherwise, these values are meaningless)

    Bring on your Own OIDC – Tenant Configuration

    For tenant configuration, i have created a video, please take a look here, Tenant can bring their own OIDC and self service in cloud director tenant portal.

    This concludes the OIDC configuration with VMware Cloud Director. I would like to Thank my colleague Ankit Shah, for his guidance and review of this document.