Search the Community

Organizations can contribute to the platform’s GitHub or receive a framework for creating enterprise-grade generative AI systems.View the full article

VMware Workstation Pro virtual machines can be exported and imported back into VMware Workstation Pro on other computers or other hypervisor programs such as Proxmox VE, KVM/QEMU/libvirt, XCP-ng, etc. VMware Workstation Pro virtual machines can be exported in OVF and OVA formats. OVF: The full form of OVF is Open Virtualization Format. The main goal of OVF is to provide a platform-independent format for distributing virtual machines between different platforms/hypervisors. A VMware Workstation Pro virtual machine exported in OVF format will export a few files containing metadata, disk images, and other files to help deploy the virtual machine on other platforms/hypervisors. OVA: The full form of OVA is Open Virtualization Appliance. While OVF exports of VMware Workstation Pro virtual machines generate a few files for each virtual machine, OVA combines all those files into a single archive. In short, OVA export is a compressed format of OVF exported files. OVA files are easier to distribute among different platforms/hypervisors. In this article, I am going to show you how to export VMware Workstation Pro virtual machines in OVF/OVA format for keeping a copy of the virtual machine as a backup, or for importing them back to other platforms/hypervisors. Table of Contents: How to Export VMware Workstation Pro VMs in OVA Format How to Export VMware Workstation Pro VMs in OVF Format Conclusion References How to Export VMware Workstation Pro VMs in OVA Format: To export a VMware Workstation Pro virtual machine in OVA format, select it[1] and click on File > Export to OVF[2]. Navigate to a folder/directory where you want to export the VMware Workstation Pro virtual machine in OVA format. Type in a file name for the export file ending with the extension .ova (i.e. docker-vm.ova)[1], and click on Save[2]. The VMware Workstation Pro virtual machine is being exported in OVA format. It will take a while to complete depending on the size of the virtual disks of the virtual machine. Once the VMware Workstation Pro virtual machine is exported in OVA format, you will find an OVA file in your selected folder/directory. How to Export VMware Workstation Pro VMs in OVF Format: To export a VMware Workstation Pro virtual machine in OVF format, select it[1] and click on File > Export to OVF[2]. Navigate to a folder/directory where you want to export the VMware Workstation Pro virtual machine in OVA format. As OVF export will create a few files for each virtual machine, you should create a dedicated folder/directory (engineering-vm in this case) for the virtual machine export and navigate to it[1]. Type in a file name for the export file ending with the extension .ovf ( i.e. engineering-ws.ovf)[2], and click on Save[3]. The VMware Workstation Pro virtual machine is being exported in OVF format. It will take a while to complete depending on the size of the virtual disks of the virtual machine. Once the VMware Workstation Pro virtual machine is exported in OVF format, you will find a few virtual machine files in the selected folder/directory. Conclusion: In this article, I have shown you how to export a VMware Workstation Pro virtual machine in OVA format. I have also shown you how to export a VMware Workstation Pro virtual machine in OVF format. References: Open Virtualization Format (OVF and OVA) | XenCenter CR View the full article

AWS announces the general availability of Amazon EC2 m7i.metal-24xl instance for VMware Cloud on AWS. This offering features a disaggregated storage architecture from compute, supporting both Amazon FSx for NetApp ONTAP and VMware Cloud Flex Storage as primary storage options for customers. With this new offering, customers can now choose among three instance types for VMware Cloud on AWS: i3en.metal, i4i.metal and m7i.metal-24xl. View the full article

This post is co-written with Rivlin Pereira, Staff DevOps Engineer at VMware Introduction VMware Tanzu CloudHealth is the cloud cost management platform of choice for more than 20,000 organizations worldwide that rely on it to optimize and govern the largest and most complex multi-cloud environments. In this post, we will talk about how VMware Tanzu CloudHealth migrated their container workloads from self-managed Kubernetes on Amazon EC2 to Amazon Elastic Kubernetes Service (Amazon EKS). We will discuss lessons learned and how migration help achieve eventual goal of making cluster deployments fully automated with a one-click solution, scalable, secure, and reduce overall operational time spent to manage these clusters. This migration led them to scale their production cluster footprint from 2400 pods running in kOps (short for Kubernetes Operations) cluster on Amazon Elastic Compute Cloud (Amazon EC2) to over 5200 pods on Amazon EKS. Amazon EKS cluster footprint has also grown from running a few handful of clusters after the migration to 10 clusters in total across all environments and growing. Amazon EKS is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers. In the cloud, Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other key tasks. Previous self-managed K8s clusters and related challenges The self-managed Kubernetes clusters were deployed using kOps. These clusters required significant Kubernetes operational knowledge and maintenance time. While the clusters were quite flexible, the VMware Tanzu CloudHealth DevOps team was responsible for the inherent complexity, including custom Amazon Machine Image (AMI) creation, security updates, upgrade testing, control-plane backups, cluster upgrades, networking, and debugging. The clusters grew significantly and encountered limits that were not correctable without significant downtime and that is when the team considered moving to managed solution offering. Key drivers to move to managed solution VMware Tanzu CloudHealth DevOps team had following requirements for Amazon EKS clusters: Consistently reproducible and deployed with a one-click solution for automated Infrastructure-as-Code (IaC) deployment across environments. Consistent between workloads. Deployable in multiple regions. Services can migrate from the old clusters to the new clusters with minimal impact. New clusters provide more control over roles and permissions. New cluster lifecycle (i.e., creation, on-boarding users, and cluster upgrades) tasks reduce operational load. Key technical prerequisite evaluation We will discuss couple of technical aspects customers should evaluate in order to avoid surprises during the migration. Amazon EKS uses upstream Kubernetes, therefore, applications that run on Kubernetes should natively run on Amazon EKS without the need for modification. Here are some key technical considerations discussed in Migrating from self-managed Kubernetes to Amazon EKS? Here are some key considerations post that VMware team evaluated and implemented required changes: Kubernetes versions: VMware team was running k8s version 1.16 on kOps. For the Amazon EKS migration, team started with k8s version 1.17 and post migration they have upgraded to 1.24. Security: Authentication for Amazon EKS cluster: kOps clusters were configured to use Google OpenID for identity and authentication. Amazon EKS supports both OpenID Connect (OIDC) identity providers and AWS Identity and Access Management (AWS IAM) as methods to authenticate users to your cluster. To take advantage of Amazon EKS support for AWS IAM for identity and authentication, VMware made user configuration and authentication workflow changes to access the new clusters. Please see Updating kubeconfig for more information. AWS IAM roles for service accounts: VMware had configured AWS IAM roles for pod using kube2iam for kOps self-managed clusters. With this setup, pod level permissions were granted by IAM via proxy agent that was required to be run on every node. This kOps setup resulted in issues at scale. Amazon EKS enables a different approach. AWS Permissions are granted directly to pods by service account via a mutating webhook on the control plane. Communication for identity, authentication and authorization happens only with the AWS API endpoints and Kubernetes API, eliminating any proxy agent requirement. Review Introducing fine-grained IAM roles for service accounts for more information. The migration to IAM roles for service accounts for Amazon EKS fixed issues encountered with kube2iam when running at larger scales and has other benefits: Least privilege: By using the IAM roles for service accounts feature, they are no longer needed to provide extended permissions to the worker node IAM role so that pods on that node can call AWS APIs. You can scope IAM permissions to a service account, and only pods that use that service account have access to those permissions. Credential isolation: A container can only retrieve credentials for the IAM role that is associated with the service account to which it belongs. A container never has access to credentials that are intended for another container that belongs to another pod. Auditability: Access and event logging is available through AWS CloudTrail to help ensure retrospective auditing. Networking: VMware had setup kOps clusters using Calico as an overlay network. In Amazon EKS, they decided to implement Amazon VPC CNI plugin for K8s as it assigns IPs from the VPC classless interdomain routing (CIDR) to each pod. This is accomplished by adding a secondary IP to the EC2 nodes elastic network interface. Each Amazon EC2 node type has a supported number of elastic network interfaces (ENI) and corresponding number of secondary IPs assignable per ENI. Each EC2 instance starts with a single ENI attached and will add ENIs as required by pod assignment. VPC and subnet sizing: VMware created a single VPC with /16 CIDR range in production to deploy Amazon EKS cluster. For development and staging environments, they created multiple Amazon EKS clusters in single VPC with /16 CIDR to save on IP space. For each VPC, private and public subnets were created, and Amazon EKS clusters were created in private subnet. NAT gateway was configured for outbound public access. Also, subnets were appropriately tagged for internal use. Tooling to create Amazon EKS clusters: VMware reviewed AWS recommended best practices for cluster configuration. For cluster deployment, a common practice is IaC and there are several options like CloudFormation, eksctl, the official CLI tool of Amazon EKS, AWS Cloud Development Kit (CDK) and third-party solutions like Terraform. They decided to automate the deployment of the Amazon EKS cluster using a combination of community Terraform modules and some Terraform modules were developed in-house. Customers can also check Amazon EKS blueprints for cluster creation. Amazon EKS Node Groups (Managed/Unmanaged): Amazon EKS allows for use of both managed and self-managed node groups. Managed node groups offer significant advantages at no extra cost. This includes offloading of OS updates and security patching by using Amazon EKS optimized AMI where Amazon EKS is responsible for building patched versions of the AMI when bugs or issues are reported. Amazon EKS follows the shared responsibility model for Common Vulnerability and Exposures (CVE) and security patches on managed node groups, its customers responsibility for deploying these patched AMI versions to managed node groups. Other features of managed node groups include, automatic node draining via the Kubernetes API during terminations or updates, respect the pod disruption budgets, and automatic labeling to enable Cluster Autoscaler. Unless there is a specific configuration that cannot be fulfilled by a managed node group, recommendation is to use managed node group. Please note that cluster-autoscaler is not enabled for you by default on Amazon EKS and has to be deployed by the customer. VMware used managed node groups for migration to Amazon EKS. Solution overview Migration execution With an architecture defined, the next step was to create the AWS infrastructure and execute the migration of workloads from the self-managed Kubernetes clusters to Amazon EKS. Using IaC a parallel set of environments was provisioned for the Amazon EKS clusters alongside the existing kOps infrastructure. This would allow any changes necessary to be made to the Kubernetes manifests while retaining the capability to deploy changes to the existing infrastructure as needed. Figure a. Pre Cut-over Walkthrough Once the infrastructure was provisioned, changes were made to the manifests to align with Amazon EKS 1.17 and particular integrations that would be required. For example, the annotations to enable IRSA were added alongside the existing kube2iam metadata to allow the workloads to be deployed in both sets of infrastructure in parallel. Kube2iam on the kOps cluster provided AWS credentials via traffic redirect from the Amazon EC2 metadata API for docker containers to a container running on each instance, making a call to the AWS API to retrieve temporary credentials and return these to the caller. This function was enabled via an annotation on the pod specifications. kind: Pod metadata: name: aws-cli labels: name: aws-cli annotations: iam.amazonaws.com/role: role-arn iam.amazonaws.com/external-id: external-id To configure a pod to use IAM roles for service accounts, the service account was annotated instead of pod. apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME After testing was performed in a pre-production environment, the workloads were promoted to the production environment where further validation testing was completed. At this stage, it was possible to start routing traffic to the workloads running on Amazon EKS. In the case of this particular architecture this was accomplished by re-configuring the workloads consuming the APIs to incrementally route a certain percentage of traffic to the new API endpoints running on Amazon EKS. This would allow the performance characteristics of the new infrastructure to be validated gradually as the traffic increased, as well as the ability to rapidly roll back the change in the event of issues being encountered. Figure b. Partial Cut-over As production traffic was entirely routed to the new infrastructure and confidence was established in the stability of the new system the original kOps clusters could be decommissioned, and the migration completed. Figure c. Full Cut-over Lessons learned The following takeaways can be learned from this migration experience: Adequately plan for heterogeneous worker node instance types. VMware started with a memory-optimized Amazon EC2 instance family for their cluster node-group, but as the number of workloads run on Amazon EKS diversified, along with their compute requirements, it became clear that needed to offer other instance types. This led to dedicated node-groups for specific workload profiles (e.g., for compute heavy workloads). This has led VMware to investigate Karpenter, an open-source, flexible, high-performance Kubernetes cluster autoscaler built by AWS. It helps improve application availability and cluster efficiency by rapidly launching right-sized compute resources in response to changing application load. Design VPCs to match the requirements of Amazon EKS networking. The initial VPC architecture implemented by VMware was adequate to allow the number of workloads on the cluster to grow, but over time the number of available IPs became constrained. This was resolved by monitoring the available IPs and configuring the VPC CNI with some optimizations for their architecture. You can review the recommendations for sizing VPCs for Amazon EKS in the best practices guide. As Amazon EKS clusters grow, optimizations will likely have to be made to core Kubernetes and third-party components. For example VMware had to optimize the configuration of Cluster Autoscaler for performance and scalability as the number of nodes grew. Similarly it was necessary to leverage NodeLocal DNS to reduce the pressure on CoreDNS as the number of workloads and pods increased. Using automation and infrastructure-as-code is recommended, especially as Amazon EKS cluster configuration becomes more complex. VMware took the approach of provisioning the Amazon EKS clusters and related infrastructure using Terraform, and ensured that Amazon EKS upgrade procedures were considered. Conclusion In this post, we walked you through how VMware Tanzu CloudHealth (formerly CloudHealth), migrated their container workloads from self-managed Kubernetes clusters running on kOps to AWS managed Amazon EKS with the eventual goal of making cluster deployments fully automated with a one-click solution, scalable, secure solution that reduced the overall operational time spend to manage these clusters. We walked you through important technical pre-requisites to be considered for migration to Amazon EKS, some challenges that were encountered either during or after migration, and lessons learned. We encourage to evaluate Amazon EKS for migrating workloads from kOps to a managed offering. Rivlin Pereira, VMware Tanzu Division Rivlin Pereira is Staff DevOps Engineer at VMware Tanzu Division. He is very passionate about Kubernetes and works on CloudHealth Platform building and operating cloud solutions that are scalable, reliable and cost effective. View the full article

The HashiCorp Terraform ecosystem continues to expand with new integrations that provide additional capabilities to Terraform Cloud, Enterprise, and Community edition users as they provision and manage their cloud and on-premises infrastructure. Terraform is the world’s most widely used multi-cloud provisioning product. Whether you're deploying to Amazon Web Services (AWS), Microsoft Azure, Google Cloud, other cloud and SaaS offerings, or an on-premises datacenter, Terraform can be your single control plane, using infrastructure as code for infrastructure automation to provision and manage your entire infrastructure. Terraform Cloud run tasks Run tasks allow platform teams to easily extend the Terraform Cloud run lifecycle with additional capabilities offered by services from partners. Wiz Wiz, makers of agentless cloud security and compliance for AWS, Azure, Google Cloud, and Kubernetes, launched a new integration with Terraform run tasks that ensures only secure infrastructure is deployed. Acting as a guardrail, it prevents insecure deployments by scanning using predefined security policies, helping to reduce the organization's overall risk exposure. Terraform providers We’ve also approved 17 new verified Terraform providers from 13 different partners: AccuKnox AccuKnox, maker of a zero trust CNAPP (Cloud Native Application Protection) platform, has released the AccuKnox provider for Terraform, which allows for managing KubeArmor resources on Kubernetes clusters or host environments. Chainguard Chainguard, which offers Chainguard Images, a collection of secure minimal container images, released two Terraform providers: the Chainguard Terraform provider to manage Chainguard resources (IAM groups, identities, image repos, etc.) via Terraform, and the imagetest provider for authoring and executing tests using Terraform primitives, designed to work in conjunction with the Chainguard Images project. Cisco Systems Cisco delivers software-defined networking, cloud, and security solutions to help transform your business. Cisco DevNet has released two new providers for the Cisco Multicloud Defense and Cisco Secure Workload products: The Multicloud Defense provider is used to create and manage Multicloud Defense resources such as service VPCs/VNets, gateways, policy rulesets, address objects, service objects, and others. The Cisco Secure Workload provider can be used to manage the secure workload configuration when setting up workload protection policies for various environments. Citrix Citrix, maker of secure, unified digital workspace technology, developed a custom Terraform provider for automating Citrix product deployments and configurations. Using the Terraform with Citrix provider, users can manage Citrix products via infrastructure as code, giving greater efficiency and consistency on infrastructure management, as well as better reusability on infrastructure configuration. Couchbase Couchbase, which manages a distributed NoSQL cloud database, has released the Terraform Couchbase Capella provider to deploy, update, and manage Couchbase Capella infrastructure as code. Genesis Cloud Genesis Cloud offers accelerated cloud GPU computing for machine learning, visual effects rendering, big data analytics, and cognitive computing. The Genesis Cloud Terraform provider is used to interact with resources supported by Genesis Cloud via public API. Hund Hund offers automated monitoring to provide companies with simplified product transparency, from routine maintenance to critical system failures. The company recently published a new Terraform provider that offers resources/data sources to allow practitioners to manage objects on Hund’s hosted status page platform. Managed objects can include components, groups, issues, templates, and more. Mondoo Mondoo creates an index of all cloud, Kubernetes, and on-premises resources to help identify misconfigurations, ensure security, and support auditing and compliance. The company has released a new Mondoo Terraform provider to allow Terraform to manage Mondoo resources. Palo Alto Networks Palo Alto Networks is a multi-cloud security company. It has released a new Terraform provider for Strata Cloud Manager (SCM) that focuses on configuring the unified networking security aspect of SCM. Ping Identity Ping Identity delivers identity solutions that enable companies to balance security and personalized, streamlined user experiences. Ping has released two Terraform providers: The PingDirectory Terraform provider is a plugin for Terraform that supports the management of PingDirectory configuration, while the PingFederate Terraform provider is a plugin for Terraform that supports the management of PingFederate configuration. SquaredUp SquaredUp manages a visualization platform to help enterprises build, run, and optimize complex digital services by surfacing data faster. The company has released a new SquaredUp Terraform provider to help bring a unified visibility across teams and tools for greater insights and observability in your platform. Traceable Traceable is an API security platform that identifies and tests APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. The company recently released two integrations: a custom Terraform provider for AWS API Gateways and a Terraform Lambda-based resource provider. These providers allow the deployment of API security tooling to reduce the risk of API security events. VMware VMware offers a breadth of digital solutions that power apps, services, and experiences for their customers. The NSX-T VPC Terraform provider gives NSX VPC administrators a way to automate NSX's virtual private cloud to provide virtualized networking and security services. Learn more about Terraform integrations All integrations are available for review in the HashiCorp Terraform Registry. To verify an existing integration, please refer to our Terraform Cloud Integration Program. If you haven’t already, try the free tier of Terraform Cloud to help simplify your Terraform workflows and management. View the full article

VMware software provides cloud computing and platform virtualization services to various users and it supports working with several tools that extend its abilities. You might View the full article

This tutorial will show you how to install VMware Workstation 17 Pro on RHEL-based distributions such as CentOS, Fedora, Rocky Linux, and AlmaLinux, as well View the full article

VMware previewed what will become a suite of intelligent assistants that use generative artificial intelligence (AI) to automate the management of a wide range of IT tasks. View the full article

VMware today unveiled an orchestration tool, dubbed VMware Edge, that promises to simplify the management of edge computing services at scale.View the full article

AWS Backup now supports AWS PrivateLink for VMware workloads, providing direct access to AWS Backup from your VMware environment via a private endpoint within your virtual private network in a scalable manner. With this launch, you can now secure your network architecture by connecting to AWS Backup using private IP addresses in your Amazon Virtual Private Cloud (VPC), eliminating the need to use public IPs, firewall rules, or an Internet Gateway. AWS PrivateLink is available at a low per-GB charge for data processed and a low hourly charge for interface VPC endpoints. See AWS PrivateLink pricing for more information. View the full article

Broadcom today pulled the trigger on an acquisition of VMware for $61 billion in cash and stock that could dramatically expand its software portfolio. Tom Krause, president of the Broadcom Software Group, told investors that the Broadcom infrastructure software group will become part of VMware once the deal closes. The deal, however, includes a 40-day […] The post Broadcom Acquires VMware to Expand Software Portfolio appeared first on DevOps.com. View the full article

Rumors are swirling that Broadcom wants to buy its way into the growing hybrid cloud market by acquiring VMware. The deal won’t come cheap—after news of the potential deal surfaced, VMware’s market cap soared to around $50 billion. Yes, billion with a ‘B’. As interest rates increase and investors reevaluate many of the lofty software […] The post Could Buying VMware Bring Broadcom Hybrid Cloud Bona Fides? appeared first on DevOps.com. View the full article

AWS Backup Audit Manager now allows you to audit and report on the compliance of your data protection policies for hybrid VMware workloads. With this launch, you can include the VMware Virtual Machines in AWS Backup Audit Manager’s controls to maintain the compliance status of your organizational data protection policies and to generate unified auditor-ready reports for your VMware workloads across VMware Cloud on AWS, on premises, and on AWS Outposts. View the full article

To provide enhanced performance and read scalability, Amazon RDS on VMware adds support for read replicas across Custom Availability Zones for MySQL and PostgreSQL databases. You can create cross-custom-availability-zone read replicas of a DB instance to serve read traffic in one region, thereby increasing aggregate read throughput. A read replica can also be promoted to become a standalone DB instance if the source DB instance fails. View the full article

In this article, we are going to see how to share a local folder with a remote host running on VMWare Workstation. If you are someone wondering what VMWare Workstation is, it is a The post How to Share a Local Folder with a Remote Host Running on VMWare first appeared on Tecmint: Linux Howtos, Tutorials & Guides. View the full article

Morpheus Data has updated its hybrid cloud computing platform to add support for a bare metal-as-a-service option as well as tighter integrations with VMware vCloud Director (vCD) and NSX-T, Microsoft System Center Virtual Machine Manager (SCVMM), Microsoft Azure and Veeam data protection tools. In addition, version 5.0 of the Morpheus IT management platform adds support […] The post Morpheus Data Extends Hybrid Cloud Reach appeared first on DevOps.com. View the full article

If you have VMware workloads and you want to modernize your application to take advantage of cloud services to increase agility and reduce total cost of ownership then Google Cloud VMware Engine is the service for you! It is a managed VMware service with bare metal infrastructure that runs the VMware software stack on Google Cloud—fully dedicated and physically isolated from other customers. In this blog post, I'll take you through Google Cloud VMware Engine, its benefits, features, and use cases. Benefits of Google Cloud VMware Engine Operational continuity- Google offers native access to VMware platforms. the service is sold, delivered and supported by Google - no other companies are involved. The architecture is compatible with your existing applications, as well as operations, security, backup, disaster recovery, audit, and compliance tools and processes. No retraining - Your teams can use their existing skills and knowledge. Infrastructure agility - The service is delivered as a Google Cloud service, and infrastructure scales on demand in minutes. Security - Access to the environment through Google Cloud provides built-in DDoS protection and security monitoring. Policy compatibility- You can continue to use VMware tools and security procedures, audit practices, and compliance certifications. Infrastructure monitoring - You get reliability with fully redundant and dedicated 100 Gbps networking, providing up to 99.99% availability to meet the needs of your VMware stack. There is also infrastructure monitoring so failed hardware automatically gets replaced. Hybrid platform - The service enables high-speed, low-latency access to other Google Cloud services such as BigQuery, AI Platform, Cloud Storage, and more. Low cost- Because the service is engineered for automation, operational efficiency, and scale it is also cost effective! How does Google Cloud VMware Engine work? Google Cloud VMware Engine makes it easy to migrate or extend your VMware environment to Google Cloud. Here is how it works... you can easily migrate your on-premises VMware instances to Google Cloud, using included HCX licenses, via a cloud VPN or interconnect. The service comprises VMware vCenter, the virtual machines, ESXi host, storage, and network on bare metal! You can easily connect from the service to other Google Cloud services such as Cloud SQL, BigQuery, Memorystore, and so on. You can access the service UI, billing, and identity and access management all from the Google Cloud console as well as connect to other third-party disaster recovery and storage services such as Zerto and Veeam. Google Cloud VMware Engine use cases Retire or migrate data centers - Scale data center capacity in the cloud and stop managing hardware refreshes. Reduce risk and cost by migrating to the cloud while still using familiar VMware tools and skills. In the cloud, use Google Cloud services to modernize your applications at your pace. Expand on demand - Scale capacity to meet unanticipated needs, such as new development environments or seasonal capacity bursts, and keep it only as long as you need it. Reduce your up-front investment, accelerate speed of provisioning, and reduce complexity by using the same architecture and policies across both on-premises and the cloud. Disaster recovery and virtual desktops in Google Cloud - High-bandwidth connections let you quickly upload and download data to recover from incidents. Virtual desktops in Google Cloud - Create virtual desktops (VDI) in Google Cloud for remote access to data, apps, and desktops. Low-latency networks give you fast response times -- similar to those of a desktop app. Power high-performance applications and databases - In Google Cloud you have a hyper-converged architecture designed to run your most demanding VMware workloads such as Oracle, Microsoft SQL Server, middleware systems, and high-performance noSQL databases. Unify DevOps across VMware and Google Cloud - Optimize VMware administration by using Google Cloud services that can be applied across all your workloads, without having to expand your data center or re-architect your applications. You can centralize identities, access control policies, logging, and monitoring for VMware applications on Google Cloud. Conclusion So there you have it! Google Cloud VMware Engine, its use cases, benefits, and how it works. If this has piqued your interest, check out the Google Cloud VMware Engine documentation and demo for more details. Here is a video on Google Cloud VMware Engine: What is Google Cloud VMware Engine? #GCPSketchnote​ For more #GCPSketchnote, follow the GitHub repo and for similar cloud content follow me on twitter @pvergadia and keep an eye out on thecloudgirl.dev Related Article Google Cloud VMware Engine explained: Integrated networking and connectivity Learn about the networking features in Google Cloud VMware Engine to let you easily and deploy workloads across on-prem and cloud environ... Read Article