Category: NSX

  • From Virtualization to Cloud Service Delivery with VMware Cloud Foundation & VCSPs

    From Virtualization to Cloud Service Delivery with VMware Cloud Foundation & VCSPs

    The IT landscape is undergoing a massive transformation. Traditional virtualization, which once revolutionized data centers, is now evolving into full-fledged cloud service delivery. Organizations are no longer just managing VMs; they are delivering scalable, secure, and AI-ready cloud platforms.

    The Shift from Virtualization to Cloud Services

    Virtualization has been the backbone of IT infrastructure for over a decade, enabling efficiency, consolidation, and improved resource utilization. However, as digital transformation accelerates, enterprises require more than just virtual machines. They need scalable, automated, and AI-powered cloud platforms that can meet the growing demands of modern workloads.

    This shift is being powered by VMware Cloud Foundation (VCF)—the cornerstone of modern cloud infrastructure. With VCF, enterprises and Cloud Service Providers (CSPs) can move beyond virtualization to build multi-cloud, hybrid, and sovereign cloud environments with automation, security, and AI-driven capabilities at their core.

    Key Benefits of VMware Cloud Foundation

    Unified Platform: Compute, storage, networking, and management are integrated into a single solution.
    Hybrid & Multi-Cloud Operations: Seamlessly run workloads across private, public, and hybrid cloud environments.
    Built-in Security & Compliance: Ensure data sovereignty and regulatory compliance with sovereign cloud initiatives.
    AI-Ready Infrastructure: GPU acceleration and private AI capabilities empower AI/ML workloads.
    Accelerated Cloud Service Delivery: Enable Cloud Providers & VMware Cloud Service Providers (VCSPs) to deliver next-gen cloud offerings.

    The Significance of VMware Cloud Providers (VCSPs)

    VMware Cloud Providers (VCSPs) play a pivotal role in enabling organizations to seamlessly transition from virtualization to cloud services. They extend the capabilities of VMware Cloud Foundation by offering:

    🔹 Managed Cloud Services: Helping enterprises offload infrastructure management with fully managed VMware-based cloud environments.
    🔹 Sovereign and In-Country Cloud Solutions: Ensuring compliance with regional data sovereignty laws while delivering cloud scalability.
    🔹 Multi-Tenant Cloud Platforms: Empowering service providers to offer flexible, cost-effective cloud solutions with secure tenant isolation.
    🔹 AI and GPU-Powered Cloud Services: Providing enterprises with AI-ready infrastructure to support next-gen workloads.
    🔹 Disaster Recovery & Business Continuity: Offering reliable DRaaS (Disaster Recovery as a Service) to ensure business resilience.

    Future of Cloud with VMware Cloud Foudation

    As enterprises and service providers embrace cloud-first and AI-driven strategies, VCF is enabling them to deliver next-generation cloud services with agility, resilience, and efficiency. This evolution is not just about technology; it’s about unlocking new business opportunities, enhancing innovation, and driving digital transformation at scale.

    With cloud-native applications, AI/ML workloads, and security-first cloud strategies becoming the new normal, the role of VMware Cloud Foundation is more critical than ever.

    VMware Cloud Foundation is transforming the way cloud services are delivered, from the traditional virtualization model to highly flexible, customer-tailored cloud services. With the support of VCSPs, businesses are empowered to adopt cutting-edge cloud solutions faster and more efficiently than ever before.

  • Enhancing Firewall Flexibility in VMware Cloud Director 10.6.1

    With VMware Cloud Director 10.6.1, service providers gain greater flexibility and control over firewall configurations, ensuring compliance with licensing entitlements while delivering scalable, high-value security services. This update aligns with VMware Cloud Foundation (VCF) networking licensing, enabling providers to selectively offer the VMware Advanced Networking & Security (ANS) Add-On to customers based on their needs and cost agreements.

    Impact of VMware NSX Licensing Changes

    Recent changes to VMware’s NSX licensing model have significantly altered how firewall features are provisioned. Under the new structure:

    • Stateless Firewall is included in the VMware Cloud Foundation (VCF)
    • Stateful Firewall now requires an additional, separate license documented Here

    This change impacts how service providers manage network security within VMware Cloud Director environments. To address these shifts, Cloud Director 10.6.1 introduces new controls that give providers flexibility in defining which firewall type—stateless or stateful—is available to their tenants. This ensures security policies align with business needs while optimizing costs associated with VMware licensing.

    VMware Cloud Director with NSX supports both stateful and stateless firewalls, each serving different security needs:

    What is a Stateless Firewall?

    A stateless firewall inspects traffic on a per-packet basis without maintaining the state of active connections. Unlike stateful firewalls, which track the context of traffic flow, stateless firewalls apply predefined rules to each packet independently.

    💡 Key Benefits:
    ✔ Faster packet processing for high-performance workloads.
    ✔ Ideal for perimeter protection and edge security use cases.
    ✔ Lower resource consumption compared to stateful firewalls.

    Stateful vs. Stateless Firewalls in Cloud Director

    FeatureStateful FirewallStateless Firewall
    Connection Tracking✅ Maintains connection state❌ No connection awareness
    Security Context✅ Applies rules based on traffic flow❌ Evaluates each packet independently
    PerformanceHigher resource usageLightweight, optimized for speed

    Configuring in Cloud Director

    This feature is designed to help cloud service providers who wish to control which tenants can access Stateless/Stateful Firewall services. The goal is to enforce better governance over the consumption of advanced network services, such as Stateful Firewall and Distributed Firewall.

    The license selection is made at the Edge Cluster level in VCD. The service provider determines which type of firewall can be applied to a specific Edge Cluster. Consequently, all Provider/Organization and vApp Edge Gateways utilizing that cluster will have firewall rules configured as either stateful or stateless, depending on the selection.

    This will have corresponding changes in NSX, while The firewall rule configuration remains the same in vCD. below is the VMware Cloud Director (VCD) view of the Org VDC Edge Gateway firewall configuration deployed on an Edge Cluster designated with the stateless firewall option inside NSX Manager.

    NOTE : Changing an Edge Cluster from Stateful to Stateless or vice versa will not impact existing deployed Gateways.

    Gateway Firewall Enforcement Control in VCD

    One key use case is when a service provider or tenant is using an appliance-based third-party firewall instead of the NSX-integrated firewall in Cloud Director. In such cases, they may not require NSX-based firewall enforcement and prefer to manage security through their own solution. This feature allows them to disable the NSX firewall, ensuring flexibility in security architecture without unnecessary conflicts.

    Now with this release both service providers and tenants can disable or enable the firewall at the Provider or Org Gateway level without removing existing firewall rules. A new “Active” switch has been introduced in the Firewall UI (top right corner), allowing users to toggle firewall enforcement as needed while preserving the configured rules.

    Conclusion

    The new firewall flexibility in Cloud Director 10.6.1 ensures that service providers can:

    Optimize licensing costs by choosing stateless or stateful firewall options.
    Align security offerings with customer needs.
    Enhance governance and compliance around advanced network security services.
    Seamlessly integrate third-party firewall solutions into their cloud environments.

    By leveraging these new capabilities, Cloud Director providers can deliver scalable, efficient, and cost-effective security solutions while adapting to the evolving VMware NSX licensing model.

    Cloud Director 10.6.1 Release Notes Published Here

  • Why Customers Should Choose VMware Cloud Service Providers When Transitioning from Public to Private Cloud

    As businesses’ cloud strategies evolve, many are reconsidering their reliance on public cloud environments and exploring the benefits of private cloud solutions. Public clouds like AWS, Azure, and Google Cloud offer flexibility and scalability, but they also come with challenges such as unpredictable costs, security concerns, and limited control. This is where VMware Cloud Service Providers (CSPs), powered by VMware Cloud Foundation (VCF), present a compelling alternative for businesses looking to transition from public to private cloud. Here’s why customers should choose a VMware CSP when making this move:

    1. Predictable Costs and Better Financial Control

    Public Cloud Challenge:
    The pay-as-you-go model of public clouds is attractive at first but often leads to unpredictable and escalating costs. Usage spikes, data transfer fees, and networking costs can cause budget overruns, making it difficult for businesses to manage long-term financial planning.

    VMware CSP Advantage:
    With VMware Cloud Foundation hosted by a VMware CSP, costs become more predictable and fixed. Unlike public clouds, where charges can fluctuate based on consumption, VMware CSPs offer stable pricing tailored to the customer’s dedicated infrastructure needs. This leads to greater financial control and ensures that businesses can plan their budgets with confidence, avoiding unexpected bills and cost surges.


    2. Enhanced Security and Compliance

    Public Cloud Challenge:
    While public cloud providers maintain infrastructure security, customers are responsible for securing their data. This shared responsibility model introduces potential security gaps, especially in multi-tenant environments where data is more exposed. For industries with strict regulatory requirements, such as healthcare and finance, managing compliance in a public cloud can be challenging.

    VMware CSP Advantage:
    VMware Cloud Service Providers offer private, dedicated infrastructure, giving businesses full control over their security protocols. VMware Cloud Foundation includes built-in features like NSX micro-segmentation, end-to-end encryption, and automated compliance controls to ensure robust security. This infrastructure meets the stringent security needs of industries like government and financial services, making it easier for organizations to comply with regulations such as GDPR, HIPAA, and PCI-DSS.

    By choosing a VMware CSP, businesses can deploy their own security policies and governance measures, ensuring full compliance without the risks associated with public cloud environments.


    3. Consistent Performance and Infrastructure Customization

    Public Cloud Challenge:
    Public clouds are designed to serve a broad range of customers, leading to performance variability. The shared, multi-tenant nature of public clouds can cause resource contention, which negatively impacts performance for businesses with mission-critical workloads. Additionally, public cloud platforms offer limited options for customizing infrastructure to optimize specific workloads.

    VMware CSP Advantage:
    With a VMware CSP, businesses gain access to dedicated infrastructure that provides consistent, reliable performance. VMware Cloud Foundation allows companies to customize their private cloud environments, tuning resources to meet the exact demands of high-performance workloads like AI/ML, enterprise applications, or data-intensive tasks. This ensures optimal performance and avoids the unpredictable resource contention seen in public cloud environments.


    4. Full Control Over Data and Infrastructure

    Public Cloud Challenge:
    In a public cloud setup, businesses often lose a degree of control over their data and infrastructure, as public cloud providers manage the underlying systems. This can lead to vendor lock-in, where organizations are restricted to the cloud provider’s tools and architecture, making it difficult to adapt or migrate workloads.

    VMware CSP Advantage:
    VMware Cloud Foundation offers businesses full control over their infrastructure, ensuring flexibility and freedom. With a VMware CSP, organizations are not bound by the limitations of a public cloud vendor’s ecosystem. Instead, they can manage and operate their private cloud environment according to their own policies and tools, retaining ownership of their data and ensuring it is managed and stored in compliance with their internal standards.

    Moreover, VMware CSPs provide a vendor-neutral platform, reducing the risk of cloud lock-in and enabling smoother transitions to other cloud models if needed.


    5. Simplified Compliance and Data Residency

    Public Cloud Challenge:
    Many businesses must comply with strict regulations around data residency and sovereignty, requiring data to be stored and processed within specific regions. While public clouds offer region-based services, maintaining compliance can be complex due to the global nature of their infrastructure and multi-tenant environments.

    VMware CSP Advantage:
    VMware Cloud Service Providers offer private cloud environments where data residency is easily enforced, ensuring that sensitive information remains within required geographic boundaries. Organizations can select specific data center locations that comply with local laws and regulatory requirements, providing greater control over data governance. This is crucial for industries like finance, healthcare, and government, where compliance and data sovereignty are paramount.


    6. Hybrid and Multi-Cloud Flexibility

    Public Cloud Challenge:
    Public clouds are optimized for running workloads within their own ecosystem, making hybrid or multi-cloud strategies more complex. This often results in vendor lock-in, where businesses are limited to the services and infrastructure of a single cloud provider.

    VMware CSP Advantage:
    VMware Cloud Foundation is designed for hybrid and multi-cloud environments, offering businesses the flexibility to run workloads across private clouds, on-premises infrastructure, and public clouds (via VMware Cloud on AWS, Azure VMware Solution, or Google Cloud VMware Engine). This allows businesses to choose the best environment for each workload while maintaining a consistent management experience across clouds. VMware CSPs provide the best of both worlds, enabling seamless hybrid cloud operations without sacrificing control or flexibility.


    7. Long-Term Cost Efficiency and Lower Total Cost of Ownership (TCO)

    Public Cloud Challenge:
    Public clouds are ideal for elastic workloads but can become costly for steady-state or predictable workloads. Over time, businesses may find that public cloud environments become less efficient, with resources underutilized or costs outpacing usage.

    VMware CSP Advantage:
    Private clouds hosted by VMware CSPs offer a more cost-efficient solution for businesses with predictable workloads. By shifting to a fixed-cost private cloud model, organizations avoid the long-term costs of over-provisioning in the public cloud. VMware Cloud Foundation optimizes resource utilization, ensuring infrastructure is used efficiently, leading to a lower total cost of ownership (TCO) over time.

    For enterprises looking to stabilize their operational costs while maintaining cloud-level flexibility, VMware CSPs provide a long-term financial advantage compared to public cloud platforms.


    Conclusion

    Transitioning from public cloud to a private cloud environment hosted by a VMware Cloud Service Provider offers businesses a powerful combination of predictable costs, enhanced security, control, and customized infrastructure. VMware CSPs allow organizations to regain control over their data and operations, ensure compliance with stringent regulatory requirements, and optimize performance for mission-critical applications.

    For enterprises seeking a strategic balance between cloud agility and operational control, VMware Cloud Service Providers are the ideal partners to support a seamless and effective move from public cloud to private cloud.

  • VMware Cloud Director OIDC Integration with VMware Workspace ONE Access

    VMware Cloud Director OIDC Integration with VMware Workspace ONE Access

    Prerequisite

    • VMware Workspace access ONE must be already deployed.
    • VMware workspace access ONE must be configured with a directory service source for users and groups.
    • Cloud Director must be installed and configured for provider and tenant organizations.

    Bill of Material

    • VMware Cloud Director 10.5.1
    • VMware Workspace ONE Access 23.09.00

    Steps to Configure Workspace ONE Access for OIDC Authentication

    Workspace ONE Access uses OAuth 2 to enable applications to register with Workspace ONE Access and create secure delegated access to applications. In this case, we will use Cloud Director to integrate with Workspace One Access.

    • In the Workspace ONE Access console Settings > OAuth 2.0 Management page, click ADD CLIENT.
    • In the Add Client page, configure the following.
    • Click SAVE. The client page is refreshed and the Client ID and the hidden Shared Secret are displayed.
    • Copy and save the client ID and generated shared secret.
    • Note: If the shared secret is not saved or you lose the secret code, you must generate a new secret, and update in Cloud Director that uses the same shared secret with the regenerated secret. To regenerate a secret, click the client ID that requires a new secret from the OAuth 2.0 Management page and click REGENERATE SECRET.

    Steps to configure VMware Cloud Director to use Workspace ONE Access for Provider/Tenant users and groups

    • From the top navigation bar, select Administration.
    • In the left panel, under Identity Providers, click OIDC or directly you can browse: https:// [VCD Endpoint]/(provider or tenant/[orgname])/administration/identity-providers/oidcSettings
    • If you are configuring OIDC for the first time, copy the client configuration redirect URI and use it to create a client application registration with an identity provider that complies with the OpenID Connect standard, for example, VMware Workspace ONE Access. (this has already been done above)
    • Click Configure
    • Verify that OpenID Connect is active and fill in the Client ID and Client Secret you created in VMware Workspace ONE Access as above during client creation.
    • 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 at the site of the provider that VMware Cloud Director can use to send authentication requests to. Fill in the IDP Well-known Configuration Endpoint field with the value:               https://ws01 URL/SAAS/auth/.well-known/openid-configuration
    • Click next.
    • If everything is correctly configured, the below information will automatically get populated, keep a note we are using the User Info endpoint.
    • 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.
    • Since we are using User Info as an access type, map the claims as below and click Next.

    NOTE: At the claims mapping step, the Subject theme will be default populated with “sub” which will mean that VCD users will have the username format “[username]@XXX”. If you want to import the users to VCD with a different format, you can change the Subject theme to map to “email” and then import users to VCD using the email address attached to the account. 

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

    Login as an OIDC GROUP Member User

    1. In the Provider/Tenant organization’s Administration Page, import OIDC groups and map them to existing VCD roles.
    2. NOTE: In case you don’t see the “IMPORT GROUPS” button, refresh the page, and you will see the desired button IMPORT GROUPS
    • User go to https:// [VCD Endpoint]/(provider or tenant/[orgname])
    • The user should be redirected to the Workspace ONE Access login page. Users can log in with the user in the group.
    • The user will be redirected back to VCD and should now be fully logged in. 

    After the first successful login, the organization administrator can see the newly auto-imported user.

    Login as an OIDC User

    • In the Provider/Tenant organization’s Administration Page, import OIDC users and map them to existing VCD roles.
    • User go to https://[VCD Endpoint]/(provider or tenant/[orgname])
    • The user should be redirected to the Workspace ONE Access login page and log in there.
    • The user will be redirected back to VCD and should now be fully logged in. 

    If you get the SSO Failure page double-check that you imported to the correct group/user and that the username format is correct. For additional information, you can check Here and for troubleshooting and about configuring additional logging, you can check the official documentation here.

    Login without OIDC or as a Local User

    In version 10.5, if an organization in VMware Cloud Director has SAML or OIDC configured, the UI displays only the Sign in with Single Sign-On  option. To log in as a local user, navigate to https://vcloud.example.com/tenant/tenant_name/login or https://vcloud.example.com/provider/login.

  • NSX Multi-Tenancy in VMware Cloud Director

    Multi-Tenancy was introduced in NSX UI starting from VMware NSX 4.1 and now commencing with version 10.5.1, VMware Cloud Director introduces support for NSX multi-tenancy, facilitating direct alignment of vcd organizations with NSX projects.

    What are NSX Projects ?

    A project in NSX functions akin to a tenant. Creating projects enables the separation of security and networking configurations among different tenants within a single NSX setup.

    Multi-tenancy in NSX is achieved by creating NSX projects, where each project represents a logical container of network and security resources (a tenant). Each project can have its set of users, assigned privileges, and quotas. Multi-tenancy serves various purposes, such as providing Networking as a Service, Firewall as a Service, and more.

    How NSX Projects relate to Cloud Director Organizations?

    Within the VCD platform, the tenancy is established via Organizations. Each tenant receives its exclusive organization, ensuring a distinct and isolated virtual infrastructure tailored to their tasks. This organizational setup grants precise control over tenant access to resources, empowering them to oversee Users, Virtual Data Centers (VDCs), Catalogs, Policies, and other essentials within their domain.

    To clearly outline the tenant structure, VMware NSX introduced a feature known as Projects. These Projects allocate NSX users to distinct environments housing their specific objects, configurations, and monitoring mechanisms based on alarms and logs.

    With VCD 10.5.1, management functionalities tied to NSX Tenancy fall within the exclusive purview of the Provider. NSX Tenancy operates on an Organization-specific level within VCD. When activated, a VCD Organization aligns directly with an NSX Project.

    VCD drives and manages the creation of the associated NSX project, allowing the User to configure the project identifier. The NSX project is actually created during the creation of the first VDC in the organization for which you activated NSX tenancy. The name of the NSX project is the same as the name of the organization to which it is mapped.

    How to enable?

    The Cloud Provider can enable the NSX Tenancy for a specific Organization by going into the Cloud Director Organization section, choosing an organization, and selecting “NSX Tenancy”, he/she can also define a Log Name, which will be the Organization’s unique identifier in the backing NSX Manager logs.

    The name of the NSX project will be the same as the name of the organization to which it is mapped.

    Once NSX tenancy has been activated on the Org level, the Cloud provider can create a new Org VDC and choose to enable “NSX Tenancy”, this is when The NSX project is actually get created in NSX.

    NOTE: Network Pool selection is disabled. This is because NSX supports Project creation only in the default overlay Transport Zone. Also, make sure the default overlay Transport zone already exists.

    Note: If you choose not to activate NSX tenancy during the creation of an organization VDC, you cannot change this setting later.

    When not to choose to enable tenancy?

    Some use cases do not require organization VDC participation in NSX tenancy, for example, if the VDC only needs VLAN networks. Additionally, organization VDCs using NSX tenancy are restricted to using the network pool that is backed by the default overlay transport zone, so, in order to be able to use a different network pool, you might wish to opt out of NSX tenancy.

    also there are a few features that NSX projects do not support today, like NSX Federation deployments as well as not all Edge Gateway features are available for Networking Tenancy-enabled VDCs like VPNs (IPsec/L2) and sharing segment profile templates, etc.. so work in progress and will see more and more features coming in future.

    Conclusion

    Aligning NSX Projects with VCD’s Tenancy ensures customers access an extensive array of networking capabilities offered by the NSX Multi-tenancy solution. Among these crucial functionalities is tenant-centric logging for core VCD networking services like Edge Services and Distributed firewalls. Additionally, integrating NSX Projects paves the way to investigate potential enhancements, facilitating tenant self-service login capabilities within VCD features. Below, you can find more information and capabilities.

    Managing NSX Tenancy in VMware Cloud Director

    VMware Cloud Director 10.5.1 adopts NSX Projects

  • Infrastructure as Code with VMware Cloud Director

    Infrastructure as Code with VMware Cloud Director

    In today’s fast-paced digital landscape, organizations are constantly seeking ways to optimize their IT operations and streamline infrastructure management. One approach that has gained significant traction is Infrastructure as Code (IaC). By treating infrastructure provisioning and management as code, IaC enables organizations to automate and standardize their processes, resulting in increased efficiency, scalability, and consistency.

    In this blog article, we will explore the concept of Infrastructure as Code and its practical implementation using VMware Cloud Director. We will delve into the benefits and challenges of adopting IaC, highlight the features of VMware Cloud Director, and showcase how the integration of Terraform with VMware Cloud Director can revolutionize IT operations for Cloud Providers as well as customers.

    What is Infrastructure as Code?

    Infrastructure as Code (IaC) is a methodology that involves defining and managing infrastructure resources programmatically using code. It allows organizations to provision, configure, and manage their infrastructure resources, such as compute, network, and storage, through automated processes. By treating infrastructure as code, organizations can leverage the same software development practices, such as version control and continuous integration, to manage their infrastructure.

    Benefits of Infrastructure as Code

    The adoption of Infrastructure as Code brings numerous benefits to cloud providers as well as customers:

    Consistency and repeatability: With IaC, infrastructure deployments become consistent and repeatable, ensuring that the same configuration is applied across different environments. This eliminates configuration drift and minimizes the risk of errors caused by manual configurations.

    Efficiency and scalability: IaC enables organizations to automate their infrastructure provisioning and management processes, reducing the time and effort required for manual tasks. This allows IT teams to focus on more strategic initiatives and scale their infrastructure easily as the business demands.

    Version control and collaboration: By using code repositories and version control systems, organizations can track changes made to their infrastructure configurations, roll back to previous versions if needed, and collaborate effectively across teams.

    Documentation and auditability: IaC provides a clear and documented view of the infrastructure configuration, making it easier to understand the current state and history of the infrastructure. This improves auditability and compliance with regulatory requirements.

    Flexibility and portability: With IaC, organizations can define their infrastructure configurations in a platform-agnostic manner, making it easier to switch between different cloud providers or on-premises environments. This provides flexibility and avoids vendor lock-in.

    Challenges of Infrastructure as Code

    While Infrastructure as Code offers numerous advantages, it also presents some challenges that organizations should be aware of:

    Learning curve: Adopting IaC requires IT teams to acquire new skills and learn programming languages or specific tools. This initial learning curve may slow down the adoption process and require investment in training and upskilling.

    Code complexity: Infrastructure code can become complex, especially for large-scale deployments. Managing and troubleshooting complex codebases can be challenging and may require additional expertise or code review processes.

    Continuous maintenance: Infrastructure code needs to be continuously maintained and updated to keep up with evolving business requirements, security patches, and technology advancements. This requires ongoing investment in code management and testing processes.

    Infrastructure as Code Tools

    There are various tools available in the market to implement Infrastructure as Code. Some of the popular ones include:

    Terraform: Terraform is an open-source tool that allows you to define and provision infrastructure resources using declarative configuration files. It supports a wide range of cloud providers, including VMware Cloud Director, and provides a consistent workflow for infrastructure management.

    Chef: Chef is a powerful automation platform that enables you to define and manage infrastructure as code. It focuses on configuration management and provides a scalable solution for infrastructure provisioning and application deployment.

    Puppet: Puppet is a configuration management tool that helps you define and automate infrastructure configurations. It provides a declarative language to describe the desired state of your infrastructure and ensures that the actual state matches the desired state.

    Ansible: Ansible is an open-source automation tool that allows you to define and orchestrate infrastructure configurations using simple, human-readable YAML files. It emphasizes simplicity and ease of use, making it a popular choice for infrastructure automation.

    VMware Cloud Service Provider Program

    The VMware Cloud Service Provider Program (CSP) allows service providers to build and operate their own cloud environments using VMware’s virtualization and cloud infrastructure technologies like VMware Cloud Director, Cloud Director availability etc… This program enables service providers to offer a wide range of cloud services, including infrastructure-as-a-service (IaaS), disaster recovery, Application as a Service, Kubernetes as a Service, DBaaS and many other managed services.

    Integrating Terraform with VMware Cloud Director

    To leverage the power of Infrastructure as Code in VMware Cloud Director, you can integrate it with Terraform. Terraform provides a declarative language for defining infrastructure configurations and a consistent workflow for provisioning and managing resources across different cloud providers, including VMware Cloud Director. By combining Terraform with VMware Cloud Director, Cloud Providers/Customers can:

    Automate infrastructure provisioning: With Terraform, Cloud providers can define Tenant virtual data center, virtual machines, networks, and other resources as code. This allows for automated and consistent provisioning of infrastructure resources, eliminating manual configuration. I wrote a blog article on how to start with Cloud Director & Terraform which can be found here:

    Ensure consistency and repeatability: Infrastructure configurations defined in Terraform files can be version controlled, allowing for easy tracking of changes and ensuring consistency across different environments.

    Collaborate effectively: Terraform code can be shared and collaboratively developed within teams, enabling better collaboration and knowledge sharing among IT professionals.

    Enable infrastructure as self-service: By integrating Terraform with VMware Cloud Director, organizations can provide a self-service portal for users to provision and manage their own infrastructure resources, reducing dependency on IT support.

    Implementing Infrastructure as Code with VMware Cloud Director and Terraform

    To begin with the Terraform configuration, create a main.tf file and specify the version of the VMware Cloud Director Terraform provider

    terraform {
      required_providers {
        vcd = {
          source  = "vmware/vcd"
          version = "3.9.0"
        }
      }
    }
    
    provider "vcd" {
      url                  = "https://vcd-01a.corp.local/"
      user                 = "admin"
      password             = "******"
      org                  = "tfcloud"
      vdc                  = "tfcloud"
    }

    In the above configuration, replace the url, user, password, org, and vdc values with your own VMware Cloud Director details.Now, let’s define the infrastructure resources using Terraform code. Here’s an example of creating a organization in VMware Cloud Director:

    #Create a new org name "tfcloud"
    resource "vcd_org" "tfcloud" {
      name              = "terraform_cloud"
      full_name         = "Org created by Terraform"
      is_enabled        = "true"
      stored_vm_quota   = 50
      deployed_vm_quota = 50
      delete_force      = "true"
      delete_recursive  = "true"
      vapp_lease {
        maximum_runtime_lease_in_sec          = 0
        power_off_on_runtime_lease_expiration = false
        maximum_storage_lease_in_sec          = 0
        delete_on_storage_lease_expiration    = false
      }
      vapp_template_lease {
        maximum_storage_lease_in_sec       = 0
        delete_on_storage_lease_expiration = false
      }
    }

    Creating Organisation Administrator

    #Create a new Organization Admin
    resource "vcd_org_user" "tfcloud-admin" {
      org               = vcd_org.tfcloud.name
      name              = "tfcloud-admin"
      password          = "*********"
      role              = "Organization Administrator"
      enabled           = true
      take_ownership    = true
      provider_type     = "INTEGRATED" #INTEGRATED, SAML, OAUTH stored_vm_quota = 50 deployed_vm_quota = 50 }

    Creating Org VDC

    # Create Org VDC for above org
    resource "vcd_org_vdc" "vdc-tfcloud" {
      name = "vdc-tfcloud"
      org  = vcd_org.tfcloud.name
      allocation_model  = "AllocationVApp"
      provider_vdc_name = "vCD-A-pVDC-01"
      network_pool_name = "vCD-VXLAN-Network-Pool"
      network_quota     = 50
      compute_capacity {
        cpu {
          limit = 0
        }
        memory {
          limit = 0
        }
      }
      storage_profile {
        name    = "*"
        enabled = true
        limit   = 0
        default = true
      }
      enabled                  = true
      enable_thin_provisioning = true
      enable_fast_provisioning = true
      delete_force             = true
      delete_recursive         = true
    }

    Creating Edge Gateway (NAT Gateway)

    # Create Org VDC Edge for above org VDC
    resource "vcd_edgegateway" "gw-tfcloud" {
      org                     = vcd_org.tfcloud.name
      vdc                     = vcd_org_vdc.vdc-tfcloud.name
      name                    = "gw-tfcloud"
      description             = "tfcloud edge gateway"
      configuration           = "compact"
      advanced                = true
      external_network {
         name = vcd_external_network.extnet-tfcloud.name
         subnet {
            ip_address            = "10.120.30.11"
            gateway               = "10.120.30.1"
            netmask               = "255.255.255.0"
            use_for_default_route = true
        }
      }
    }

    Here is the blog post which covers Tenant OnBoarding on Cloud Director using Terraform:

    Best Practices for Infrastructure as Code with VMware Cloud Director

    Implementing Infrastructure as Code with VMware Cloud Director and Terraform requires adherence to best practices to ensure efficient and reliable deployments. Here are some key best practices to consider:

    Use version control: Store your Terraform code in a version control system such as Git to track changes, collaborate with teammates, and easily roll back to previous configurations if needed.

    Leverage modules: Use Terraform modules to modularize your infrastructure code and promote reusability. Modules allow you to encapsulate and share common configurations, making it easier to manage and scale your infrastructure.

    Implement testing and validation: Create automated tests and validations for your infrastructure code to catch any potential errors or misconfigurations before deployment. This helps ensure the reliability and stability of your infrastructure.

    Implement a CI/CD pipeline: Integrate your Terraform code with a continuous integration and continuous deployment (CI/CD) pipeline to automate the testing, deployment, and management of your infrastructure. This helps in maintaining consistency and enables faster and more reliable deployments.

    Use variables and parameterization: Leverage Terraform variables and parameterization techniques to make your infrastructure code more flexible and reusable. This allows you to easily customize your deployments for different environments or configurations.

    Implement security best practices: Follow security best practices when defining your infrastructure code. This includes managing access controls, encrypting sensitive data, and regularly updating your infrastructure to address any security vulnerabilities.

    Conclusion

    Infrastructure as Code offers a transformative approach to managing infrastructure resources, enabling organizations to automate and streamline their IT operations. By integrating Terraform with VMware Cloud Director, organizations can leverage the power of Infrastructure as Code to provision, manage, and scale their infrastructure efficiently and consistently.

    In this blog post, we explored the concept of Infrastructure as Code, the benefits and challenges associated with its adoption. We also provided a step-by-step guide on implementing Infrastructure as Code with VMware Cloud Director using Terraform, along with best practices.

    By embracing Infrastructure as Code, Cloud providers and their Tenants can unlock the full potential of their infrastructure resources, accelerate their digital transformation journey, and ensure agility, scalability, and reliability in their IT operations.

    Few More Links:

    https://developer.vmware.com/samples/7210/vcd-terraform-examples

    https://registry.terraform.io/providers/vmware/vcd/latest/docs

    https://blogs.vmware.com/cloudprovider/2021/03/terraform-vmware-cloud-director-provider-3-2-0-release.html

  • Assess Your Sovereign Cloud Stack for Compliance

    VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud is a management pack available in the VMware Marketplace. You can download and install this management pack on an instance of vRealize (ARIA) Operations to automatically assess a Sovereign Cloud stack for compliance. 

    VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud is intended to be used by the VMware Cloud Service Partners who are part of the Sovereign Cloud Initiative. The following products in the Sovereign Cloud stack are currently supported for compliance assessment:

    • vSphere
    • NSX-T
    • VMware Cloud Director
    • VMware Cloud Director Availability

    For every Sovereign Cloud instance, providers need one instance of vRealize (ARIA) Operations with the VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud installed and configured. The compliance score card is available in the Optimize > Compliance screen of vRealize (ARIA) Operations.

    Compliance Pack for Sovereign Cloud Controls Rules

    The compliance rules are based on a checklist that VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud utilizes to monitor the products in the Sovereign Cloud stack. The checklist is based on the Sovereign Cloud Framework which takes into consideration the following key principles:

    Data Sovereignty and Jurisdictional Control

    Data should reside locally.
    The cloud should be managed and governed locally, and all data processing including API calls should happen within the country/geography.
    Data should be accessible only to residents of the same country, and the data should not be accessible under foreign laws or from any outside geography.

    Data Access and Integrity

    Two data center locations.
    File, Block, and Object store options
    Backup services, Disaster Recovery
    Low-latency connectivity, Micro segmentation

    Data Security and Compliance

    Industry recognized Security Controls (minimum ISO/IEC 27001 or equivalent)
    Additional relevant industry or governmental certifications
    Third-party audits & Zero Trust Security & Encryption
    Catalog of trusted images using the sovereign repository
    Support for air gapped zones/regions
    Operating personnel requirements and security clearance

    Data Independence and Interoperability

    Workload migration with bi-directional workload portability
    Modern application architecture using containers
    Support for hybrid cloud deployments

    Control Rules and Product Control Set for vSphere

    The vSphere control set is available for version 7, and 6.5/6.7 separately and details can be Here

    Control Rules and product control set for nsx-t

    Control rules and product control set for NSX-T and details can be found Here. The NSX-T version supported is greater than or equal to 3.2.x.

    Controls Rules and Product Control Set for VMware Cloud Director

    Control rules and product control set for VMware Cloud Director and details can be found Here. The supported version of the VMware Cloud Directory management pack is 8.10.2.

    Control Rules and Product Control Set for VMware Cloud Director Availability

    Controls rules and product control set for VMware Cloud Director Availability and details can be found Here. The version of the VMware Cloud Director Availability management pack supported is 1.2.1.

    Install the VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud

    The VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud consists of a PAK file that contains default contains views, reports, alerts and symptoms for the VMware software in the Sovereign Cloud stack.

    • Download the PAK file for VMware vRealize Operations Compliance Pack for Sovereign Cloud from the VMware Marketplace, and save the file to a temporary folder on your local system.
    • Log in to the vRealize (ARIA) Operations user interface with administrator privileges. Installation of this management pack is to be done by VMware Cloud Provider Program Partners.
    • In the left pane of vRealize (ARIA) Operations, click Integrations under Data Sources.
    • In the Repository tab, click the ADD button.
    • The Add Solution dialog box opens , Click BROWSE to locate the temporary folder on your system, and select the PAK file.
    • Read and select the checkboxes if required, Click Upload. The upload might take several minutes
    • Read and accept the EULA, and click Next. Installation details appear in the window during the process.
    • When the installation is completed, click Finish.

    in the vROps instance, go to Optimize > Compliance. In the VMware Cloud tab, you can see the VMware Sovereign Cloud Compliance card in the VMware Sovereign Cloud Benchmarks section. Click Enable.

    When you click Enable, a list of policies appears. You must select a policy that you want to apply. i am selecting default policy here

    With the vRealize (ARIA) Operations reporting functions, you can generate a report to view the compliance status of your Sovereign Cloud. You can download the report in a PDF or CSV file format for future and offline needs.

    Accessing Compliance Reports

    In the VMware vRealize (ARIA) Operations Compliance Pack for Sovereign Cloud two kinds of reports are available:

    At a VMware Cloud Provider Program Partner level – This report considers all the infrastructure level resources and generates a report at the org level, showing non-compliance. The compliance data is for the org and associated child hierarchy. Includes compliance details for org, org-vdc, virtual machines, logical switches, and logical routers as per the hierarchy.

    From the left menu, click Visualize > Reports and run the report – [vCloud Director] – VMware Sovereign Cloud – Non-Compliance Report.

    From the Reports panel, click Generated Reports, To select a generated report from the list, click the vertical ellipsis against the [vCloud Director] – VMware Sovereign Cloud – Non-Compliance Report report and select options such as run and delete.

    At a tenant level – The VMware Cloud Provider Program Partner generates a filtered report that the tenant can access. This report is at an org-VDC level. The compliance data is for the child hierarchy only. Includes compliance details for virtual machines, logical switches, and logical routers as per the hierarchy and Tenants can view the generated reports in the VMware Chargeback console by logging in and navigating to Reports > Tenant Reports and clicking the Generated Reports tab.

    Custom Benchmarks

    In case the CSP partner/customer requires they can create a custom compliance benchmark to ensure that objects comply with compliance alerts available in vRealize (ARIA) Operations, or custom compliance alert definitions. When a compliance alert is triggered on your vCenter instance, hosts, virtual machines, distributed port groups, or distributed switches, you investigate the compliance violation. You can add up to five custom compliance scorecards

    This is the first version of the sovereign cloud compliance pack for ARIA Operations for our Cloud Providers brings a comprehensive compliance checklist that encompasses the sovereign framework as a benchmark and continuously validates applications and infrastructure to help partners maintain their sovereignty posture. This brings extended capabilities to ARIA Operations, which, now addition to the capacity, cost, and performance monitoring, will monitor and report compliance drifts to the right stakeholders to better manage their compliance structure.

  • 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.

  • 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. 

  • 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.