One of the two biggest ways to improve an organization’s security posture is through good account management and password hygiene.* As the old saying goes, it’s easier said than done. Good account management seems simple enough, but with hundreds of systems and devices in the average organization it’s easy to miss one.

As for passwords, they’re just not secure anymore. We can make passwords complicated, check them against databases of compromised passwords, and rotate them periodically. What happens then? We write them down. If we avoid that, passwords are still very vulnerable to keystroke loggers, malicious web sites, cameras, malware, and even other people “shoulder-surfing” and watching you type.

Multifactor Authentication

Authentication is often described with the term “factors.” Factors are usually three things: something you have, something you are, or something you know. For example, a password is something you know. A fingerprint is something you are. A one-time password token is something you have. Combine these and you get multifactor authentication, or MFA. Combine two of them and you get two-factor authentication, or 2FA.

Multifactor authentication (MFA) is a huge leap forward for account security. With MFA, even if a bad actor knows your password they won’t know the one-time code that shows up on your phone, for instance. Since that code changes every minute it isn’t likely they’ll be able to guess it. Same for a fingerprint — I certainly hope a bad actor doesn’t have your finger!

Multifactor authentication seems like a good idea, right? Even if it wasn’t such a good idea on its own it is mandated in most compliance frameworks. For example, PCI DSS 3.2 added it as a requirement in control 8.3, and NIST 800-53 revision 4 has it listed in the IA set of controls, such as IA-2. While compliance frameworks often allow for “compensating controls” – alternate ways of achieving the same security goal – those can get complicated. It’s easiest for everyone if a software solution addresses the requirement directly. One of our goals with vSphere is to make it easy to be secure.

This is why vSphere 7 has Identity Federation. Identity Federation allows us to attach vCenter Server to enterprise identity providers like Active Directory Federation Services (ADFS). This means that vCenter Server participates in the same centralized corporate processes, such as onboarding and termination. It also means that users can use the same methods to log into vCenter Server as they do their desktops and the cloud. This includes MFA & 2FA solutions as well.

How Identity Federation Works

Once attached to the identity provider (in this case it’s ADFS — more on that below), the vSphere Client will redirect logins to the provider’s login page. The user or admin logs in using their corporate credentials, including any multifactor authentication that is configured as part of the system. Once they’re authenticated, the identity provider redirects them back to the vSphere Client with a cryptographic token that authorizes them. If you’ve ever logged into a web site using your Google, Twitter, or Facebook credentials this will seem very familiar.

Standard Protocols

Identity Federation uses the standard protocols OAUTH2 and OIDC to exchange information. Even with standards, one of the complications is that all authentication systems have different “schemas” for communicating. At VMworld 2019 US fellow technical marketer Mike Foley summarized this well by comparing it to making a phone call. OAUTH2 is the telephone system, but we still might call someone that doesn’t speak our language. As such, vSphere 7 initially supports ADFS because it represents what a large portion of our customers have and can easily use. More options to come as we teach vSphere more authentication “languages.”

If you enable Identity Federation it takes the place of traditional Active Directory, Integrated Windows Authentication, and LDAP/LDAPS authentication methods in vCenter Server. However, it does NOT replace the traditional vSphere Single Sign-on, which is still present for administration & troubleshooting access. Those traditional login methods still exist for now, though some are deprecated (check the release notes).

Conclusion

vSphere Identity Federation is going to be a great step forward for security, a reduction in work for compliance audits, less process duplication in an organization, less work for vSphere Admins, and a better experience for users.

* = the other big way to increase security in an organization is timely & comprehensive patching, and vSphere 7’s new Lifecycle Manager makes that easier, too.

We are excited about vSphere 7 and what it means for our customers and the future. Join us Monday through Thursdays through April 2020 for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Identity Federation appeared first on VMware vSphere Blog.

vSphere 7 is VMware’s biggest set of innovations since the launch of ESXi. With all the excitement around this new generation of vSphere and the app modernization solutions we felt our loyal vSphere users deserve an event just for themselves!

With the help of the hosts from siliconANGLE’s theCUBE, we’ve brought together vSphere engineering executives, our CTO Kit Colbert, vSphere product management leadership, and customers to showcase the key innovations in vSphere 7 and vSphere 7 with Kubernetes, available through VMware Cloud Foundation.

Join us on Thursday, April 2, 2020 at 8:00 AM PDT!

Visit the event site to learn more and sign up.

The post Join us for the vSphere 7 Launch Event! appeared first on VMware vSphere Blog.

The first release of Distributed Resource Scheduling (DRS) dates back to 2006. Since then, data centers and workloads have changed significantly. The new vSphere 7 release is shipped with DRS enhancements to better support modern workloads by using an improved DRS logic and new accompanying UI in the vSphere Client.

The enhanced DRS logic is now workload-centric rather than cluster-centric, as it was before with DRS. The DRS logic is completely rewritten to have a more fine-grained level of resource scheduling with the main focus on workloads. This blog post goes into detail on the new DRS algorithm, and explains how to interpret the metrics as seen in the new UI.

The Old DRS

vSphere DRS used to focus on the cluster state, checking if it needs rebalancing because it could happen that one ESXi host is over-consumed while another ESXi host has less resources consumed. DRS runs every 5 minutes, and if the DRS logic determined it could improve the cluster balance, it would recommend and execute a vMotion depending on the configured settings. That way, DRS used to achieve cluster balance by using a cluster-wide standard deviation model.

The New DRS

The new DRS logic takes a very different approach. It computes a VM DRS score on each host and moves the VM to the host that provides the highest VM DRS score.

The biggest change from the old DRS version is that it no longer balances host load directly. Instead, it improves the balancing by focusing on the metric that you care most about: the virtual machine happiness. Important to note is that the improved DRS now runs every minute, providing a more granular way to calculate workload placement and balancing. This results in overall better performance of the workloads.

VM DRS Score

The new DRS logic quantifies virtual machine happiness by using the VM DRS score. First, let me emphasize that the VM DRS Score is not a health score for the virtual machine! It is about the execution efficiency of a virtual machine. The score values range from 0 to 100% and are divided into buckets; 0-20%, 20-40%, and so on.

Obtaining a VM DRS score of 80-100% indicates that there is mild to no resource contention. It does not necessarily mean that a virtual machine in the 80-100% bucket is doing way better than a virtual machine in the lower buckets. That is because there are many metrics that influence the VM DRS score. Not only performance metrics are used, but capacity metrics are also incorporated in the algorithm.

The performance drivers for the VM DRS score are contention based, using metrics like CPU %ready time, good CPU cache behavior, and memory swap. The reserve resource capacity, or headroom, that a current ESXi host has is also taken into account to determine the VM DRS score. Will the virtual machine be able to burst resource consumption on its current host and to what level? Are there other ESXi hosts in the cluster that have more headroom available? All these factors play an important role in the calculation of the VM DRS score.

The improved DRS is no longer thinking about the relative load between ESXi hosts in a cluster, the main focus is on the happiness of the workloads. Next to VM DRS Score, DRS presents the Cluster DRS Score in the UI. It is calculated using an aggregation of all the happiness VM scores in the cluster. DRS will try to maximize the execution efficiency of each virtual machine in the cluster while ensuring fairness in resource allocation to all virtual machines.

The vSphere cluster summary overview provides insights on what is happening from a DRS perspective.  If you require more information on VM DRS Score, the new UI will provide that information to you.

View All VMs

When clicking on the ‘View all VMs’ option in the cluster summary DRS view,  you will be presented an overview of all virtual machines in the cluster and more detailed information about their resource claim and entitlement.

There might be situations where you will see a lot of CPU stress, which appear as high CPU ready times (%RDY) in the CPU Readiness column, or a large amount of swapped memory. Those are indicators that the workloads have possibly depleted the cluster compute resources.

You can use this information to move workloads to other clusters, or to scale out the cluster resources by adding additional ESXi hosts. The latter we can do automatically in VMware Cloud on AWS using Elastic DRS.

UI Walkthrough

When you click on the cluster “Summary” overview in vSphere 7, the new DRS UI is shown on the right. Expand the DRS view to get immediate insights. Check out this UI walkthrough to get an understanding of what it looks like:

New Capabilities in DRS

The new DRS logic in vSphere 7 is an important step forward for running modern workloads. Additional new capabilities that tie in with, or are a part of, DRS are Assignable Hardware and Scalable Shares.

Assignable Hardware

When a VM configured with hardware accelerators is first powered on it needs to be placed on an appropriate host in the cluster. The Assignable Hardware framework integrates with DRS to do that. PCIe devices with the new Dynamic DirectPath I/O or NVIDIA vGPU profiles are supported in vSphere 7 as part of this initial placement. This video includes more information on how this works, and more detailed information will follow in an upcoming blog post.

Scalable Shares

An important update to DRS is the option for Scalable Shares. Enabling Scalable Shares allows resource pools to have dynamic & relative entitlements. If you’ve used resource pools you’ve likely seen a situation where resource pools configured with higher share levels would not necessarily guarantee more resources for their workloads. This solves that! An improvement like this is also important for vSphere with Kubernetes, as the vSphere Pod Service needs this to ensure performance. The following video has more information, and more detailed information will follow in an upcoming blog post.

To Conclude

DRS is providing a very fundamental and important functionality as part of our virtual infrastructures since its first release. These important enhancements in vSphere 7 mean that workloads will perform as close to optimal as possible, while ensuring that hardware is used very efficiently, and help vSphere Admins add GPUs and hardware accelerators to workloads.

Watch the following video to learn more about the DRS improvements in vSphere 7.

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Improved DRS appeared first on VMware vSphere Blog.

As you can see by all the other blog articles, a LOT of new stuff is available in vSphere 7! What is also new is me working on something other than vSphere Security (Bob Plankers has that now). My new focus is vSphere with Kubernetes and how it affects the traditional vSphere Administrator (VI Admin).

Long before my time in security I was a “system manager” (sysadmin) running VAXcluster systems that serviced a whole business unit and later, the OpenVMS operating system development team. Technology has changed quite a bit since then, but the challenges are still, basically, the same. This is why the needs and career of the vSphere Administrator are very important to me.

Enough about ancient history. Let’s take a look at “Tanzu Kubernetes Grid clusters” — a big component of vSphere with Kubernetes — from the standpoint of the vSphere Administrator.

What are “Tanzu Kubernetes Grid clusters”?

When we first announced “Project Pacific” in 2019 at VMworld these were referred to as “Guest Clusters.” They are now called Tanzu Kubernetes Grid clusters or “TKG clusters.” With vSphere 7 with Kubernetes this functionality is delivered as part of VMware Cloud Foundation 4.0.

Note: Kubernetes is often abbreviated to “K8S” — there are 8 letters between the ‘K’ and the ‘S’…

A Tanzu Kubernetes Grid (TKG) cluster is a Kubernetes (K8s) cluster that runs inside virtual machines on the Supervisor layer and not on vSphere Pods. It is enabled via the Tanzu Kubernetes Grid Service for vSphere. Since a TKG cluster is fully upstream-compliant with open-source Kubernetes it is guaranteed to work with all your K8s applications and tools. That alone is a big advantage.

TKG clusters in vSphere use the open source Cluster API project for lifecycle management, which in turn uses the VM Operator to manage the VMs that make up the cluster. Let’s look at an architecture layout and then dive into the components:

Here’s the glossary of what you see in this diagram.

• SDDC: the Software-defined Data Center, also known as your vSphere infrastructure
• vSphere Pod Service: The vSphere Pod Service is a special kind of Kubernetes cluster that uses ESXi as its worker nodes instead of Linux.
  • VMware Principle Engineer Joe Beda, one of the co-founders of Kubernetes, refers to Kubernetes as a “Platform Platform. Meaning, Kubernetes is a platform for building new platforms. For example, Kubernetes can run other platforms, like Kubernetes! It’s not just about running containers.
• Namespace:  A namespace is the unit of management that provides governance needed by vSphere admins to assign resources, permissions, policies and controls around Kubernetes workloads. There are two ways we use the term Namespace when we talk about vSphere with Kubernetes:
  • Kubernetes Namespace: These are used within Kubernetes for resource management and controls. In a TKG cluster the developer could use namespaces to control access to certain parts of their application.
  • vSphere Namespace: My colleague Michael West introduced vSphere Namespaces in a blog post at VMworld 2019. vSphere Namespaces align with vSphere constructs like Resource Pools and vSphere Encryption implementations.
• Pods: In this example above these are vSphere Pods. The definition of a pod is a unit of deployment. It runs one or more containers that share resources.
• Tanzu Kubernetes Cluster: – This is a fully conformant Kubernetes cluster running on virtual machines. In the example above it has a Control Plane VM, three worker nodes, and a full K8s stack that can be used by a developer. Running on these worker VMs are pods, and inside the pods are containers.

Why is this interesting to me, the vSphere Admin?

If you think about it, as a vSphere Admin, the common link to developers is via a help ticketing system. Developers open a ticket and request resources. Virtual machines, network changes, more storage, and so on. What if you, the vSphere Admin, could just assign them a sandbox and give them a way to self-service all these requests? That’s what Kubernetes brings to the table for YOU! THAT is, IMHO, the paradigm shift for vSphere Administrators. Let me explain.

With Kubernetes the developer can declare what they want via a YAML file and send that to Kubernetes using the kubectl command. They can say “Give me a TKG cluster running 3 worker nodes, an ingress network, and encrypt all persistent data.” Assuming they have the right permissions in their namespace, those actions are all done for them by the infrastructure.

Note: At no time did they need to learn the vSphere or NSX API’s! They just declared what they wanted and got it. Just like in K8s instances in the public cloud.

If others are running workloads there’s no worry. Workloads are isolated via Namespaces and NSX networking and of course, vSphere virtual machine isolation. Traditionally we’d call this multitenancy! I’ll dive more into Namespaces in another blog. You’re gonna love them, I promise.

Why should TKG clusters be important to me?

vSphere with Kubernetes is affording the vSphere admin the opportunity to maintain their status as the providers of stable, secure, proven infrastructure for these new workloads. In your meetings with developers you can show them that you can provide a fully conformant Kubernetes cluster running on a platform that already meets the company’s business needs and requirements. Little things like backups, compliance mandates, security scans, disaster recovery and customer support that some “forget” about when rushing to implement the new hotness. There’s now no reason to have folks go off and build Shadow IT copies of K8s. Shadow IT is a huge concern of every customer I talk to.

What kind of visibility do I get?

This is a great question. For the longest time I’ve heard customers talk about the inability to map resources to people. They’ll use tags or creative names of VMs, but it really doesn’t give them that warm and fuzzy feeling. If your developer spins up a TKG cluster, you’ll see that in the vSphere client. Each TKG cluster has in it an agent that provides certain centralized management features. The guest agent allows the contents of the cluster to be visible in the vCenter UI. It also allows the vCenter administrator to set policies that govern clusters by installing admission controllers, policy objects, and scanners in the guest cluster.

This is how a namespace looks in the vSphere Client (click on the image to zoom in):

This image shows the Demo Namespace, assigned to user Fred. In that namespace Fred has created a TKG cluster called “dev-cluster.” There are three cluster worker node virtual machines and three cluster control plane virtual machines. Running on these worker nodes are three instances of nginx.

In addition, you’ll see the storage policies assigned. These map directly to vSphere Storage Based Policy Management values, e.g. “high-performance-ssd.”

Let’s look at how the cluster looks from a compute standpoint regarding the virtual machines:

You can see in the image the six VMs that make up the “dev-cluster” TKG cluster, what VM image they are running, their creation time, and the VM class they came from.

The next image shows the same cluster but from the standpoint of Tanzu Kubernetes:

Here you can see the name, “dev-cluster,” the number of worker nodes, the Kubernetes version of the cluster and the IP address for the Control Plane. This is the IP address used by the developer to connect via the kubectl command.

The next image shows the networking for the TKG Cluster:

In the networking pane you can see all the networking involved in the “dev-cluster” TKG Cluster. You have the name of the Control Plane AND the workloads running on the cluster. You also have the IP Addresses and whether then are the addresses of a Load Balancer, or not. You can also see the ports that are opened and if this cluster was using an external IP Address, an Ingress, or Endpoint controller you’d see those as well.

Of course, because all this information is in the vSphere Client it also means it’s available via the vSphere APIs, too.

Wrap Up

There you have it. vSphere with Kubernetes running TKG Clusters with full visibility for the vSphere Administrator in the tool of their choice. As this blog was just an introduction that means I’ll be sharing more with you throughout the coming months. These will be starting out as introduction-level blogs and diving deeper as we get closer to the VMworld timeframe.

I hope you find this information helpful and if you have questions on vSphere with Kubernetes for the vSphere Administrator or topics that you’d like me to cover, please sent me a DM on Twitter: @mikefoley

Thanks for reading!

mike

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Introduction to Tanzu Kubernetes Grid Clusters appeared first on VMware vSphere Blog.

Have you been considering moving your organization’s workloads to the public cloud due to spiraling costs, however application latency, management transparency, and corporate data security concerns have you reconsidering on-premises modernization? Maybe your company is interested in compute-enabling your edge , however the support costs of deploying and maintaining compute at the edge has prevented moving these plans forward.

In either case, VMware offers a solution that addresses these concerns.

VMware Cloud on Dell EMC is the first and only fully managed infrastructure as a service, which comes pre-configured to customer specifications and delivered on-premise or to edge locations. Built around Dell EMC’s VxRail technology, the racked infrastructure arrives ready to deploy with VMware’s Cloud Foundation software pre-installed and included in the monthly subscription cost. The service includes continuous health monitoring of the hardware, VMware software patching and upgrade, security updates, life cycle management, support and onsite service. Professional installation of the infrastructure is even included.

VMware Cloud on Dell EMC is the only true infrastructure as a service offering that delivers a fully managed Hyper Converged infrastructure that includes VMware Cloud Foundation software with monthly ‘cloud-like’ subscription billing.

For more information on this innovative VMware service offering, including rack infrastructure specifications and options available, please download the VMware Cloud on Dell EMC data sheet or view the other resources available on the VMware Cloud on Dell EMC Webpage.

The post VMware Cloud on Dell EMC – Discover Infrastructure as a Service appeared first on VMware vSphere Blog.

It’s been three weeks since we announced VMware vSphere 7 and vSphere with Kubernetes. You’ve been waiting very patiently for it to become “GA” or Generally Available so that you can get it running in your nested vSphere lab (vSphere can run inside your production vSphere environment for testing and training purposes, just like the Hands-on Labs do). You’ve watched all the videos in the vSphere 7 YouTube playlist. You’ve gone back and read all the other posts and recaps. You’ve scoured the VMware Reddit forum for hints of when it will ship, read every single @VMwarevSphere tweet, and followed vSphere on Facebook. You even built an IFTTT applet to send a text message to your phone when something new appears in the vSphere Blog RSS feed.

Now you’re just quietly frustrated that, even though VMware always does this announce-first-ship-soon thing, we did it again. With everything going on in the world COULDN’T THIS HAVE BEEN THE TIME THINGS WERE DIFFERENT?!

Join us for the vSphere 7 Launch Event!

We understand, so here’s something that’s very different: a SECOND launch event. You will DEFINITELY want to watch this on Thursday, April 2. It’s hosted by siliconANGLE’s theCUBE, who are the folks that you see at VMworld every year with their studio in the Community/Hang Space. This event is geared towards all the vSphere Admins out there and will have VMware vSphere Engineering & Product Management leadership, the CTO for vSphere Kit Colbert, and real customers talking about vSphere 7 and vSphere 7 with Kubernetes. The hosts of theCUBE are knowledgeable, charismatic, and always do a great job keeping things interactive and lively.

Use the link above to get a “save the date” reminder, block off your calendar, and enjoy the show.

vSphere 7 – Identity Federation

VMware vSphere 7 has the option to connect to Microsoft Active Directory Federation Services to authenticate and authorize users. This is a new and very welcome direction for vSphere, and it’s exciting because it is a great step forward for security, a reduction in work for compliance audits, less process duplication in an organization, less work for vSphere Admins, and a better experience for users.

vSphere 7 – Improved DRS

The Distributed Resource Scheduler, DRS, is one of the most fundamental components of the software-defined data center. We usually take it for granted as it sits there, quietly helping our workloads stay fast and available. vSphere 7 introduces a number of big improvements to DRS, and Niels Hagoort takes us through them.

vSphere 7 – Introduction to Tanzu Kubernetes Grid Clusters

I bet you’ve heard something about Kubernetes being in VMware vSphere 7, haven’t you? Seems like maybe we’ve mentioned it a few thousand times or so since VMworld US 2019. There’s a very good reason why people keep talking about it, though – it makes Kubernetes much easier for an organization to implement, secure, and govern. Unlike a lot of implementations, it also stays very true to the open source heritage of Kubernetes, too, which is a huge advantage. Mike Foley runs us through what a vSphere Admin will see when they turn on vSphere with Kubernetes, what the Tanzu Kubernetes Grid (TKG) Clusters are, and why developers like them.

In other interesting news around VMware:

Rapidly Respond to Business Continuity Challenges with VMware Cloud on AWS

This is a very weird time in the world right now, and all of us at VMware hope that you, your loved ones, and your friends are safe. Given the realities of global manufacturing, activities like buying new server hardware might be trickier than usual. VMware Cloud on AWS is very compelling under normal circumstances, and right now there are some special offers available to help organizations out.

The Hybrid Cloud Might be Virtual, But the Savings are Real

Craig Stanley is one of our Cloud Economists. What the heck is a “cloud economist?” It’s someone who helps organizations study the economic benefits of the cloud in the context of their business goals, decisions, and IT initiatives. As more customers discover why VMware Cloud on AWS is game-changing we have more data around their actual savings and benefits. IDC studied all of this and released a new paper, and Craig gives us the highlights and the link to what IDC had to say.

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Launch Recap & Links, Week 3 appeared first on VMware vSphere Blog.

A wide variety of modern workloads greatly benefit from using hardware accelerators to offload certain capabilities, save CPU cycles, and gain a lot of performance in general. Think about the telco industry for example: Network Function Virtualization (NFV) platforms utilizing NICs and FPGAs. Or customers that use GPUs for graphic acceleration in their Virtual Desktop Infrastructure (VDI) deployment. The AI/ML space is another example of workloads where applications are enabled to use GPUs to offload computations. To utilize a hardware accelerator with vSphere, typically a PCIe device, the device needs to be exposed to guest OS running inside the virtual machine.

In vSphere versions prior to vSphere 7, a virtual machines specifies a PCIe passthrough device by using its hardware address. This is an identifier that points to a specific physical device at a specific bus location on that ESXi host. This restricts that virtual machine to that particular host. The virtual machine cannot easily be migrated to another ESXi host with an identical PCIe device. This can impact the availability of the application using the PCIe device, in the event of host outage. Features like vSphere DRS and HA are not able to place that virtual machine on a another, or surviving, host in the cluster. It takes manual provisioning and configuration to be able to move that virtual machine to another host.

We do not want to compromise on application availability and ease of deployment. Assignable Hardware is a new feature in vSphere 7 that overcomes these challenges.

Introducing Assignable Hardware

Assignable Hardware in vSphere 7 provides a flexible mechanism to assign hardware accelerators to workloads. This mechanism identifies the hardware accelerator by attributes of the device rather than by its hardware address. This allows for a level of abstraction of the PCIe device. Assignable Hardware implements compatibility checks to verify that ESXi hosts have assignable devices available to meet the needs of the virtual machine.

It integrates with Distributed Resource Scheduler (DRS) for initial placement of workloads that are configured with a hardware accelerator. This also means that Assignable Hardware brings back the vSphere HA capabilities to recover workloads (that are hardware accelerator enabled) if assignable devices are available in the cluster. This greatly improves workload availability.

The Assignable Hardware feature has two consumers; The new Dynamic DirectPath I/O and NVIDIA vGPU.

Dynamic DirectPath I/O

As a part of the Assignable Hardware framework in vSphere 7, Dynamic DirectPath I/O is introduced. When configuring a virtual machine to use a PCIe device, customers will be presented with three options:

• DirectPath I/O
• Dynamic DirectPath I/O
• NVIDIA vGPU

DirectPath I/O is the legacy feature to passthrough a PCIe device like before with no integration with vSphere DRS and HA. Dynamic DirectPath I/O is the new solution that enables the Assignable Hardware intelligence for passthrough devices. No longer is the hardware address of the PCIe device directly mapped to the virtual machine configuration file (the .vmx file). Instead, the attributes, or capabilities, are exposed to the virtual machine.

When you choose ‘Select Hardware’, all the PCIe devices capable for passthrough are listed in the dropdown menu. Once a specific device is selected, Assignable Hardware with DRS will find a suitable host that can satisfy the request for the configured hardware accelerator.

Hardware Labels

Notice the ‘GPGPU example‘ custom label in the upper screenshot? That is is the optional hardware label for PCIe devices when using Dynamic DirectPath I/O. It allows for even more flexibility when assigning hardware accelerators to virtual machines. A PCIe device can be configured with one label. DRS takes care of initial placement for a virtual machine configured with a Dynamic DirectPath I/O. Assignable Hardware finds a suitable host with an identical device as configured, or find a host with a device with an identical hardware label. This could mean a different type of PCIe device is backing that hardware label.

Customers don’t always have a heterogenous host configuration. ESXi hosts in a cluster could be equipped with different types of GPUs. For example; Using custom hardware labels, we could use a NVIDIA T4 GPU, or a RTX6000 GPU. Both using the same GPU ‘Turing’ architecture, so we could potentially use the ‘Turing GPU‘ hardware label. Using a hardware label provides the flexibility to use either GPU model for the virtual machine, as long as the label matches. It is recommended to only include devices to a specific label that provide similar hardware capabilities.

How to Configure

Providing a custom hardware label is as easy as opening the Passthrough enabled PCI Devices options, insert a label and configure a virtual machine with the PCIe device. Keep in mind that VM hardware version 17 is required for Assignable Hardware and Dynamic DirectPath I/O.

NVIDIA vGPU

The other consumer of Assignable Hardware is NVIDIA vGPU. This is a versatile solution that is co-developed with NVIDIA and allows for partial GPU allocation to workloads. Please review this extensive blog post to learn how NVIDIA vGPU can be integrated on a VMware vSphere platform.

Since vSphere 6.7, the co-developed NVIDIA vGPU solution already allows for workload portability, even live-migrations using vMotion as of vSphere 6.7 Update 1. With vSphere 7 and Assignable Hardware, the workload placement is improved for vGPU enabled virtual machines. Assignable Hardware will verify the availability of the vGPU profile that is selected for the virtual machine.

To Conclude

Assignable Hardware greatly improves how the customers can utilize hardware accelerators. Bringing back vSphere HA and DRS (initial placement) capabilities for virtual machines that are configured with a PCIe device, is huge! The following video also explains the Assignable Hardware concept. Expect more content and demos soon.

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Assignable Hardware appeared first on VMware vSphere Blog.

Content Library has come a long way since its inception in vSphere 6.0. Having such a library allows for virtual machine templates, as well as scripts, text files, and ISO images to be stored efficiently and centralized for sharing within the datacenter. Content Library in vSphere 7 does not disappoint by adding additional features to support VM Template (vmtx) management, further simplifying vSphere content distribution.

In vSphere 7, customers can now manage VM templates in a more efficient and flexible manner. Quickly edit VM templates by checking them out, making necessary changes, and checking them in. Additionally, administrators can edit the configuration of Advanced Content Library settings across vCenter Server instances directly from the vSphere Client.

What is Check-In/Check-Out?

Before vSphere 7, when an administrator needed to perform maintenance on a VM Template (vmtx), the process was quite manual and included multiple steps. An example of those tasks:

• Convert the VM template back to a VM
• Snapshot the VM, if rollback needed
• Update the guest OS or other VM object settings
• Convert the VM back to a VM template
• Copy the VM template back to Content Library
• Delete the old VM template(s) from Content Library

With the introduction of Check-In and Check-Out operations for updating virtual machine templates, when a VM template is stored in Content Library, Check-In and Check-Out actions, as well as template versioning, are available to allow an Administrator to quickly make changes and keep track of VM Template versions. It is no longer necessary to perform the mentioned manual steps for editing the VM template as the process has been included in the new workflows. During this process, the VM template is not available for checkout from other users but will be available to deploy a virtual machine from the VM template without disruption.

Checking out a VM template allows for edits, and Checking in a template, creates a new version of the template containing the updated state of the virtual machine. Below we can see a template being checked in to save the changes made.

Once checked in, the VM template now has an audit trail, or versioning to keep track of any edits. Notes as well as timestamps, and names of the privileged user making the edits are preserved. This new view of template history keeps things simple and easy to manage.

Template Versioning

VM Template versioning is enabled when a VM template is stored in a Content Library. This allows an administrator to keep a history of changes over time with a vertical timeline view. In the Versioning tile, the timeline view provides detailed information about different VM template versions, updates made by privileged users, and when the last change was performed. Quickly and efficiently revert VM templates back to their previous state or delete an unwanted version of a VM template.

NOTE: VM templates that are stored outside of a Content Library are still used in vSphere 7.0, but template management features like Check-In/Check-Out and versioning will not be available for those templates.

Advanced Settings

Content Library in vSphere 7 now allows easy access to editing Content Library service settings directly from the vSphere Client. On the Content Libraries screen, an Advanced button is displayed.

Clicking this button will open the Advanced Configuration settings page where edits can be made. A menu option allows the selection of the vCenter Server instance whose settings need to be changed.

Note: The drop-down menu only appears if the SSO Domain contains more than one vCenter Server.

If an advanced setting requires a restart of the Content Library service after being edited, a prompt will guide the administrator to the vCenter Server Appliance Management Interface (VAMI) on port 5480 (https://<vCenterServer-FQDN>:5480), to perform the service restart.

Privileges

Content Library in vSphere 7 has a few new privileges that are important to bring up as well as a few existing ones that should be considered. Please refer to the chart below for more details.

Wrapping Up

Content Library has definitely evolved over the years and in vSphere 7 we have made managing templates within those libraries a much simpler process. Gone are the days of extra steps to complete simple tasks. Remember that PowerCLI 11.5 included many new cmdlets for managing a Content Library. Utilizing these commands can dramatically decrease operations like Creating a new Library or even just adding or removing content. Stay tuned for more content and demos on vSphere 7 and its features.

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Content Library appeared first on VMware vSphere Blog.

This post is by Philip Buckley-Mellor, an infrastructure designer for British Telecommunications (BT) with over 30 years of experience managing and designing infrastructure for large enterprises. His Service and Platforms Team at BT is responsible for delivery of broadband, television, and mobile services to millions of BT customers. 

At BT, we focus on delivering outstanding customer experiences through super fast broadband, TV, and mobile. To do this, we are constantly improving applications and delivering new functionality.  This is a critical part of our overall corporate strategy – always enhancing the already great service we provide to our customers – and our IT team is proud to be a crucial contributor to our customers’ satisfaction.

To achieve a more agile application base, we have implemented a microservices architecture for key application components and services. Our modern applications need a modern infrastructure, so we’ve also been experimenting with containers for some time to support our use of microservices, and we plan to expand their use going forward.

Modern Applications on vSphere

We’re extremely excited to see that VMware vSphere with Kubernetes will now provide the container infrastructure we need in a single stack that unifies our infrastructure, enabling us to run and manage virtual machines and containers with a single set of people, processes, and systems.

We use VMware vSphere, NSX-T, vRealize Operations, and other VMware products and solutions extensively. This makes us very comfortable in our ability to manage, troubleshoot, and optimize our environment. Our familiarity with VMware solutions will make it easy for us to deploy containers using vSphere with Kubernetes.

Our operations team will be able to quickly deploy containers on-premises and across multiple clouds. As an example, there are times when we need extra capacity to handle the projected demand of some of our services. In those cases, we can easily deploy the application on a cloud like Azure or AWS without extensive rework because vSphere provides a common environment for us to use.  We’ll be able to give developers a simple view of their containers, and they won’t need to be concerned about what’s in a VM versus what’s in a container. They can just focus on the task at hand knowing that the infrastructure they need is at their fingertips.

I like that we don’t need extensive training in the use of new products to be able take advantage of Kubernetes. vCenter, which is used by our administrators, continues to be really easy to use even though it’s been extended to support containers. vCenter still looks much the same as it did in the previous vSphere versions that we have become experts in. In many ways I can’t imagine an easier approach to becoming a Kubernetes administrator. We’ll continue to use the same processes and tools to manage the environment. Our IT team will be able to apply policies around security, performance, resource allocation, and capacity management using vCenter, and developers won’t need to worry about the challenges of managing the infrastructure.

A revolutionary step forward

VMware is an innovative company and they’ve been improving vSphere for many years. We’re always glad when there is a new release as the capabilities are helpful and solid.

This new release – vSphere 7 – is a huge leap forward. In some ways, vSphere has been completely reinvented because of the unification of containers, and virtual machines, and the integration of vSphere with the new Tanzu products including Tanzu Mission Control for an end-to-end Kubernetes solution. At the same time, it’s the vSphere that we know and love – the learning curve for our teams is going to be very small, which is a big bonus because growing Kubernetes expertise is difficult.

I’m excited about it, as are a lot of my peers at other companies. People in my position should take an opportunity to evaluate what they can achieve with vSphere with Kubernetes.

– Philip Buckley-Mellor

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post British Telecom Accelerates App Development with vSphere appeared first on VMware vSphere Blog.

vSphere 7

The new generation of vSphere for existing enterprise apps. Available in two editions.

VMware vSphere 7, the new generation of vSphere, is now generally available. This major new release brings a massive improvement in the work experience of vSphere administrators, folks who are responsible for the security, performance, and resiliency of the infrastructure and applications that provide all the key services to their organizations.

Watch the vSphere 7 digital launch event for the executive view, a technical overview, and a customer perspective with the hosts of siliconANGLE’s theCUBE.

To deep dive into the new features in vSphere 7, please visit the vSphere Academy and the YouTube playlist for vSphere 7.

Major Release

The purpose of this major release from vSphere is two-fold. The first is to embed containers and Kubernetes into vSphere, unifying them with virtual machines as first class citizens. This enables all vSphere administrators to become Kubernetes administrators and easily deliver new services to their developers. More on this in part two of this blog post, when vSphere 7 with Kubernetes becomes available as part of VMware Cloud Foundation 4. If you’re interested in vSphere 7 with Kubernetes, please visit the VMware Cloud Foundation blog site to learn more.

The second purpose of this major release is to deliver an essential building block of the cloud operating model to vSphere admins for running existing enterprise applications with vSphere 7. vSphere 7 addresses key challenges faced by our vSphere admins in areas of lifecycle management, security, and performance and resiliency needed by business-critical applications, AI/ML applications and latency sensitive applications.

Lifecycle Management

vSphere admins spend a significant amount of time on the lifecycle management of infrastructure. Lifecycle management includes ensuring that their systems are up-to-date and that the latest firmware for the underlying compute, storage and networking are installed and working. It also includes installing patches provided by VMware and other industry vendors, as updates are released in response to security vulnerabilities and as enhancements are deployed. Upgrading to the latest vSphere software version often takes a dedicated amount of time too, since each host needs to be updated, and the current process involves manual steps to validate. A typical vCenter Server upgrade would include migrating external PSCs and the vCenter Server from Windows OS to a vCenter Server appliance. Upgrading vSphere clearly involved many different activities and tools that required significant planning.

vSphere 7 offers a much simpler software architecture with a single upgrade workflow. With vSphere 7, the only requirement is to upgrade vCenter Server; there is no need to upgrade other external components such as the external PSC (Platform Services Controller) or load balancers. This results in a more efficient upgrade process given the fewer nodes that need to be managed.

Also, vSphere 7 enables the upgrades of entire ESXi clusters (versus a single ESXi host at a time) using a desired state model with cluster image management. The desired state model of the upgrade validates each host’s configuration until it matches the desired state. This simplifies and automates the host upgrade significantly for the entire ESXi cluster, once customers have upgraded to vSphere 7. Note that customers would have to upgrade to vSphere 7 to take advantage of the desired state model for future upgrades.

Security

vSphere admins are frequently and deeply involved in security operations related to infrastructure. Implementing data privacy and security policies and performing periodic compliance validation becomes a joint responsibility of IT and security organizations. The problem is that there are many ways in the industry to implement security policies, including implementing multi-factor authentication (MFA). Life for vSphere admins is even more complicated because many customers already have MFA in their corporate identity management systems.

vSphere 7 solves this problem using Identity Federation, which means vCenter Server can integrate with an enterprise identity provider without involving the vAdmins and vCenter Server. This simplifies the vSphere Admin’s job and helps reduce compliance audit scope.

vSphere 7 also enables vSphere admins to protect the integrity of your virtual infrastructure with remote attestation by a trusted computing base. This capability is delivered by vSphere Trust Authority. With vSphere Trust Authority, vSphere admins conduct security checks on a few strongly trusted hosts, validating the operating system, firmware, credentials, etc. These trusted systems are then compared to other running systems, with any differences being identified, so they can be evaluated for security vulnerabilities.

Performance and Resiliency

Whether customers are running database applications that demand a large VM such as SAP HANA or Oracle back ends, or AI/ML applications using GPU resources, or latency sensitive applications that require granular access to timing information, the needs for large and high performing applications continues to grow.

vSphere 7 delivers massive improvements to Distributed Resource Scheduler (DRS), vMotion, and Assignable Hardware to meet the needs of enterprise applications.

• Improved DRS –Now using a workload centric approach for efficient resource allocation and live migration of workloads, the improved DRS concentrates less on the ESXi host utilization and prioritizes the VM condition – think of it as how “happy” your virtual machine is. The VM DRS score is calculated every minute, allowing vSphere to provide a much more granular optimization of resources.
• Large application vMotion– vSphere admins can extend vSphere’s vMotion capability to large workloads such as SAP HANA and Oracle back ends. Previously, these workloads necessitated a longer stun-time during the switchover phase. With vSphere 7 and the greatly improved vMotion logic to transfer only those pages that are desired by the workload, stun time is reduced drastically for large workloads.
• Assignable Hardware– With vSphere 7, vSphere admins can provision efficient pools of accelerated hardware for AI/ML applications with supported GPUs. Assignable Hardware will now interact with DRS when that VM is powered on (initial placement) to find an ESXi host that has such a device available, claim that device, and register the VM to that host. If there is a host failure and vSphere HA kicks in, Assignable Hardware also allows for that VM to be restarted on a suitable host with the required hardware available.
• Precision Time Protocol (PTP)– vSphere 7 delivers PTP support for applications that need high-resolution time, such as high frequency trading and 5G applications built by telco service providers.

Next Steps

Now is the time to start planning your upgrade.

• To learn about the upgrade process, pricing and packaging for vSphere 7 and upgrading your vSphere license keys, please visit the vSphere Upgrade Center. If you have questions, you can visit Resources in the Upgrade Center or contact VMware Support.

• To learn more about the vSphere 7 release, please visit the key product resources onvSphere Central, vSphere 7 blog or vSphere Academy.

Also, remember that End of General Support (EOGS) for vSphere 6.0 occurred on March 12, 2020. Please read the 6.0 EOGS blog for more details and upgrade to vSphere 7 as soon as possible to take advantage of the new capabilities.

Thank you for helping us improve vSphere 7 by giving us feedback, and being open about the challenges you face in your operating environments. Please continue to provide feedback through all channels, including our user groups and the VMware Technology Network . You can learn also more about vSphere 7 through our VMUG webcast series and through the resources below. Thank you for your continued confidence in vSphere!

Key vSphere 7 upgrade resources:

• Visit the vSphere 7 Upgrade Center
• Visit the vSphere Central
• Watch the vSphere 7 launch event to hear executive, technical, and customer perspectives on vSphere 7

Additional Information:

• vSphere 7 Blog
• vSphere 7 Product Page
• vSphere Academy
• vSphere 7 YouTube Playlist
• VMUG webcast series
• App Modernization in a Multi-Cloud World
• Modern Apps Press Release

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Announcing General Availability of the New Generation of vSphere appeared first on VMware vSphere Blog.

We’re very excited to announce the general availability of vSphere 7 today! It caps off a massive across-the-board effort by the many engineering teams within VMware. We have built a ton of new capabilities into vSphere 7, including drastically improved lifecycle management, many new security features, and broader application focus and support.  But of course, the biggest new capability is the integration of Kubernetes into vSphere.

Many customers have asked – how can I get vSphere with Kubernetes?  Is it built-in?  Is anything else required to enable it to run?

As discussed previously, Kubernetes is indeed built deeply into the very core of both ESXi and vCenter.  As we were building Kubernetes in, it was clear that Kubernetes required a very flexible and dynamic networking layer that could connect both containers (inside pods) and traditional VMs.  In order to best address this need, we made the decision to use NSX.  NSX provides a robust set of L4-7 software-defined networking capabilities designed exactly for this use case.

Given that multiple components were now needed (ESXi, vCenter, NSX), orchestration was necessary to coordinate lifecycle and health management.  SDDC Manager was the perfect fit.   As it turns out, vSphere + NSX + SDDC Manager = VMware Cloud Foundation (VCF).  And we’ve made the integration with Kubernetes work seamlessly with our recently announced VCF 4.

So VCF 4 is what you need to get vSphere with Kubernetes.

VCF 4 is the quickest and easiest path to a SDDC (Kubernetes-enabled or not!).  First off, it handles all the basic orchestration and lifecycle management of both our software bits and Kubernetes, dramatically reducing the complexity of operating a SDDC environment.  But it does so much more to simplify the use of Kubernetes:

• Fastest way to get Kubernetes in your datacenter: from creation of workload domains with compute, storage, network to enabling Kubernetes on clusters, it takes less than a couple of hours.
• Automated deployment of NSX-T edges to create logical networks for Kubernetes namespaces and to configure egress and ingress.
• Out-of-box integration with storage (Container Storage Interface) and network (Container Network interfaces) to perform operations like persistent volumes and egress/ingress/namespace tenancy.
• Scale Kubernetes infrastructure by simply adding or removing vSphere nodes.
• Enterprise-grade certificate, password, license, and SSO management.
• And above all: no specialized knowledge of Kubernetes or containers required for IT Admins to stand it all up!

Second, you have a lot of optionality in terms of which our of products you consume (see the full product matrix).  The most minimal version of VCF is the Standard edition without vSAN.  It will get you vSphere, NSX, and SDDC Manager, along with vRealize Log Insight for log management, and will use the storage you connect it up to.

While vSAN isn’t required for vSphere with Kubernetes or VCF workload domains, it is the default storage offering for VCF (and indeed is required for the management domain).  vSphere with Kubernetes was absolutely designed to run best in vSAN environments and to take advantage of its capabilities.  For instance, vSAN offers the best support for storage policies for Kubernetes workloads.  So, we recommend vSAN for your VCF workload domains!

VCF Advanced and Enterprise bring a ton of extra functionality over VCF Standard.  With VCF Advanced, vRealize Automation 8.1 can orchestrate Kubernetes namespaces in the vSphere Supervisor Cluster, enabling you to automate governance and create end-to-end, policy-driven, self-service consumption and development pipelines for your developers’ Kubernetes experience.  vRealize Operations 8.1, along with vRealize Log Insight 8.1, helps operationalize vSphere with Kubernetes by enabling you to monitor the health, performance, and capacity of constructs such as Namespaces, Tanzu Kubernetes clusters, and vSphere Pods. With VCF Enterprise, the advanced storage features of vSAN deliver powerful security and availability to all your applications, Kubernetes- and VM-based.

As you can see, VCF is a powerful and flexible vehicle for delivering SDDCs, including Kubernetes-enabled ones.  It will not only help you to embrace Kubernetes but also get you moving on your infrastructure and cloud transformations.  VCF allows you to start off small, with just the SDDC components you need, at a surprisingly low price point, and grow your way into a fully virtualized infrastructure.

Finally, I just wanted to give a big shout-out to all the engineers who spent the last many months pouring their heart and souls into vSphere 7 and VCF 4.  They were both massive efforts driving a huge amount of innovation.  Thank you!

Now it’s time for you to reap the benefits of all their work!!

Learn more:

• vSphere with Kubernetes 101 Whitepaper
• Follow the vSphere blogs for more on vSphere with Kubernetes
• Follow the VCF blogs for more on more on how VCF is the easiest path to Kubernetes
• 3 Things You Should Know About VMware Cloud Foundation
• Tech Field Day 21: VMware Cloud Foundation 4: Accelerate Kubernetes Infrastructure Deployment
• Tech Field Day 21: VMware Cloud Foundation 4: Integrated Cloud Native Storage with vSAN 7

Thank you for reading! Please join us on April 2 for the vSphere 7 Launch Event — an event designed specifically for vSphere Admins!

And please keep reading here, Monday through Thursday into May for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post How to Get vSphere with Kubernetes appeared first on VMware vSphere Blog.

I am excited to share that we have kicked off a new 5-part webcast series, in partnership with VMUG, to help you easily learn about vSphere 7. It’s called Getting To Know vSphere 7, and we have put together some great content to share with you.

You can go to the series landing page and then register for each webcast individually. Direct links included below in each webcast’s details. You will hear from the vSphere team about key capabilities, benefits, use cases, and most importantly — why it matters to you and your career.

I look forward to connecting with you through these webcasts! Check out the details below and register of all 5 webcasts right away! (Note: Since the Apr 1 webcast is already done, you will be able to access it on-demand from VMUG.com.)

“Getting To Know vSphere 7”

Session Details

Webcast #1 – Apr 1, 2020 @ 10am PDT

The New vSphere – Essential Services for the Modern Hybrid Cloud

Speakers:

• Himanshu Singh
• Adam Eckerle

Abstract:

Modern application workloads require an infrastructure platform that connects developers and IT teams while simplifying management. The newly released VMware vSphere 7 has been rearchitected with native Kubernetes, massively changing the game when it comes to building and running modern applications for the enterprise, and boosting productivity for developers and IT. Moreover, IT can ensure governance and security while providing Developers self-service access to resources from the hybrid cloud. With the latest innovations in vSphere 7, IT is now able to support Kubernetes leveraging existing investments in resources and skillsets.

VMware vSphere is bringing new innovations and capabilities to run and manage modern applications with native Kubernetes, simplify lifecycle management, strengthen intrinsic security and drive enhanced performance and resiliency for all business-critical workloads. vSphere delivers the essential services for the modern hybrid cloud. Join this session to learn how you can simplify your hybrid cloud and amplify your career with vSphere 7.

Webcast #2 – Apr 6, 2020 @ 10am PDT

vSphere 7 with Kubernetes: Modern Infrastructure for Modern Applications

Speakers:

• Himanshu Singh
• Mike Foley

Abstract:

VMware vSphere 7 has been rearchitected with native Kubernetes, to massively change the game when it comes to building and running modern applications for the enterprise. With the latest innovations in vSphere 7, IT will be able to support Kubernetes leveraging existing investments in resources and skillsets, and ensure governance and security while providing Developers self-service access to resources from the hybrid cloud. This session will provide a technical overview of vSphere with Kubernetes, and cover the new user experience and use cases.

Webcast #3 – Apr 27, 2020 @ 10am PDT

Simplifying Operations with vSphere Lifecycle Manager

Speakers:

• Niels Hagoort
• Himanshu Singh

Abstract:

vSphere 7 comes with many enhancements for lifecycle management and implementing consistency across ESXi hosts and vCenter Server instances. This talk covers how to use vSphere Lifecycle Manager for declarative ESXi cluster management. Using vSphere Lifecycle Manager allows you to integrate vSphere with selected hardware vendors to push out full-stack firmware updates. Learn how to use the simplified image creator to include vendor components and additional drivers. This session also details how to manage vCenter Server configurations and updates for desired state consistency.

Webcast #4 – May 4, 2020 @ 10am PDT

Intrinsic Security: How vSphere 7 Helps Us Keep Workloads Safe

Speakers:

• Bob Plankers
• Himanshu Singh

Abstract:

When VMware talks about security and compliance we often talk about “intrinsic security,” or the idea that security is baked into the products, rather than something sprinkled on afterwards. Intrinsic security is a goal, a feature, and an attitude, and vSphere 7 represents the best of it at the core of data center infrastructure. Using the “CIA Triad” that is familiar to information security professionals, we’ll translate the new features and improvements into the security and compliance benefits for your workloads.

Webcast #5 – May 11, 2020 @ 10am PDT

vSphere 7 & Bitfusion: Running Elastic Infrastructure for AI and ML Workloads

Speakers:

• Mike Adams
• Jim Brogan

Abstract:

Hardware acceleration is used extensively for machine-learning and artificial intelligence. Virtualization is needed for this hardware acceleration to solve issues with low utilization, and difficulties with silos and management.  The Bitfusion technology will be presented that enables remote GPU access, fractional GPU access, analytics and manageability. These capabilities will be demonstrated as well. Bitfusion was acquired in August 2019, to extend VMware’s vision, “Any app, any device, any cloud”, to hardware acceleration.

We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.

The post Getting To Know vSphere 7: A 5-Part Webcast Series appeared first on VMware vSphere Blog.

Four weeks of vSphere 7 launch… it’s been quite the adventure. Here’s what’s transpired in the last week!

Watch the vSphere 7 Launch Event

This was a really great online event! The folks at theCUBE did a wonderful job, and the folks from VMware were informative, interesting, and funny. If you haven’t watched it please do.

vSphere 7 – Assignable Hardware

Niels has a great rundown of Assignable Hardware, which is a feature that makes it possible to vMotion VMs that have hardware devices attached to them. This is a big deal — means it’s much easier to maintain infrastructure now.

vSphere 7 – Content Library

Nigel runs through the new check in/check out and template management that’s in the vSphere 7 Content Library.

British Telecom Accelerates App Development with vSphere

vSphere with Kubernetes is impressing a lot of people. It was very nice of BT to talk about how they’re excited, too, and worth the read.

vSphere 7 – Announcing General Availability of the New Generation of vSphere

You can download vSphere 7! Pete runs through a lot of the highlights of vSphere 7.

How to Get vSphere with Kubernetes

Kit talks about vSphere with Kubernetes and what the VMware Cloud Foundation brings to the table.

Getting To Know vSphere 7: A 5-Part Webcast Series

These are going to be great, if I do say so myself. This is the calendar and agenda, sign up!

vSAN 7 is Generally Available

vSAN 7 comes INSIDE vSphere 7. Upgrade and you get a new storage solution, too, that supports native file services, cloud-native storage, and lots of other performance and reliability improvements. vSAN is really a great way to cut down on overhead tasks and get back to the interesting parts of your job.

VMware Cloud on AWS – Purchase online and get started today

Amidst all this craziness in the world we’ve made VMware Cloud on AWS completely self-service for signups, just use a credit card.

New Release – PowerCLI 12

PowerCLI is the Powershell interface for vSphere, and PowerCLI 12 is what supports vSphere 7. Lots and lots of new cmdlets and functions to interact with the new features.

We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.

The post vSphere 7 – Launch Recap & Links, Week 4 appeared first on VMware vSphere Blog.

Now that vSphere 7 has shipped and support for vSphere 6.0 has ended it’s time to revisit a lot of the certificate management methods and techniques we use when managing vSphere environments. Certificates are what drive the TLS encryption that protects all network communication to & from vSphere.

First, vCenter Server 7.0 has done some interesting things to help make certificate management easier. To start, the solution certificates are gone, reducing complexity:

Second, there are now REST APIs for handling vCenter Server certificates, as part of the larger effort to ensure APIs are present for nearly everything in vSphere:

There are also additional simplifications around certificates for services in both vCenter Server and ESXi, so that the number of certificates to manage is much lower, whether you are managing them manually or allowing the VMware Certificate Authority (VMCA) that is part of vCenter Server to manage the cluster certificates for you. The VMCA is “just enough certificate authority” to manage the vSphere cluster’s cryptographic needs. It should not be confused with a general-purpose certificate authority (CA) like those that are often found as part of enterprise PKI infrastructure. You cannot ask the VMCA for a certificate for your company’s blog, for example.

vSphere Certificate Management Modes

The certificate management changes in vSphere 7 are evolutionary, smoothing our management activities for us. In vSphere 7 there are four main ways to manage certificates:

Fully Managed Mode: when vCenter Server is installed the VMCA is initialized with a new root CA certificate. This is used to manage the intra-cluster certificates (protecting communications between ESXi hosts, and between ESXi hosts and vCenter Server), as well as what is called the “Machine Certificate.” The Machine Certificate, despite its name, is what us humans see in our browsers when we log into the vSphere Client. We can download the VMCA root CA certificate from the main vCenter Server web page and import it into our PCs in order to establish trust. We can also regenerate the VMCA root certificate if we want, using our own information instead of the default text values like “VMware Engineering” and such.

Hybrid Mode: the VMCA does a tremendous job automating the certificate management inside the vSphere clusters, and it saves us enormous time and frees us from the possibility of errors, like when we forget to renew a certificate. However, if we have a lot of people that access the vSphere Client it is often impractical to ask them all to import the VMCA root CA certificate. Instead, we can replace the certificate that the vSphere Client uses so that it is accepted by default by client browsers. This is the best of both worlds – deep automation for the security inside the infrastructure and minimal management effort for vSphere Client users. However, vSphere Admins will still want to import the VMCA root CA certificate in order to establish trust with the ESXi hosts, whose management interfaces will have certificates signed by the VMCA. In most cases the vSphere Admin team is small(ish), making this task is very manageable:

Note that in both hybrid mode and the default, fully managed mode neither the ESXi hosts nor the vSphere Client have self-signed certificates, which is a common misconception. They are signed by the VMCA. The VMCA is an integral part of vCenter Server. We trust vCenter Server to manage the core of our infrastructure, and therefore we implicitly trust the VMCA, too. To say that the VMCA is untrustworthy is to call into question the trustworthiness of vCenter Server as well. Is the VMCA root CA certificate more or less trustworthy than all the other root CA certificates that appear without our consent in our browsers and operating systems? Many thousands of VMware customers answer that as “more trustworthy,” especially if they regenerate it with their own information. Similarly, many customers enjoy the separation of infrastructure trust from the rest of the enterprise PKI infrastructure, from a “separation of duties” perspective as well as avoiding potential dependency loops if parts of the enterprise PKI infrastructure run inside vSphere.

Subordinate CA Mode: the VMCA can operate as a subordinate CA, delegated authority from a corporate CA. This allows vCenter Server to continue automating the certificate management, just like in the fully managed mode, except the certificates it generates are trusted as part of the organization. This is appealing to some organizations, but it requires importing key material into the VMCA that, if misplaced (or secretly stored, just in case) in transit, could be used by an attacker to impersonate the organization and conduct attacks like man-in-the-middle. In most cases, organizations — both enormous and small — that seek this level of automation find themselves using the Hybrid Mode instead because it helps isolate potential fault domains.

Full Custom Mode: in this mode the VMCA is not used, and a human must install and manage all the certificates present in a vSphere cluster. Even with the simplifications in vSphere 7 this can still amount to dozens of certificates, and the potential for operational issues and outages should a certificate be allowed to expire. Furthermore, because vCenter Server uses certificates to establish trust with the hosts, the replacement of certificates on ESXi hosts involves disconnecting and reconnecting them to vCenter Server. This can be rather onerous in the face of distributed switches and vSAN storage, which don’t like to be disconnected like that. Generating hundreds of keys, CSRs, and signing certificates is also error prone and time-consuming, not just for vSphere Admins but also the enterprise PKI teams.

A Clear Winner

It’s probably clear which mode we recommend in vSphere 7: Hybrid Mode. It let’s us take advantage of the automation and the trust we have in our vCenter Server installations but replace the machine certificate so that humans have a better experience in their browsers.

To be clear, even though we feel strongly about hybrid mode, all four modes are documented and fully supported. One size does NOT fit all in this world.

The automation with the VMCA is very compelling, especially for large institutions, and especially ones with heavy compliance & security burdens. This might seem counterintuitive, but the truth is that, for most people, discussions around certificates conflate encryption and trust in very dangerous ways. This is especially true now with certificate authorities like Let’s Encrypt, where the emphasis is less on trust and more on enabling encryption. Take all that, mix in a cup of “best” practices from a decade ago, a gallon of compliance framework & auditor, two cups of confusing jargon, and a few condescending tablespoons of “that’s not how we do things around here” and you have a recipe for trouble, endangering staff time, morale, uptime, and actual security. Keep it simple and you keep it safe.

Certificate management is possibly the single most confusing topic we encounter, and so we’ve got much more to come on these topics. Stay tuned!

We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.

The post vSphere 7 – Certificate Management appeared first on VMware vSphere Blog.

Updating and patching systems can potentially include many steps. When planning to update we must consider the many moving parts of the environment to be sure of interoperability as well as compatibility between products in the datacenter. In previous versions of vSphere, discovering the interoperability of VMware products within an environment included manual steps.

Steps may have included:

• Discovering that a new version is available (via Blogs, email, VMware TAM or account teams, etc.)
• Understanding the interoperability of a new solution version (via VMware Product Interoperability Matrix / Interoperability)
• Learning about the supported Upgrade Path of the new version (via VMware Product Interoperability Matrix / Upgrade Path)
• Comparing VMware products in the datacenter for compatibility with each other before upgrading

In vSphere 7, this task list has been consolidated into a workflow that brings it all into the vSphere Client, introducing vCenter Server Update Planner. Update Planner is part of vSphere Lifecycle Manager and is used to facilitate vCenter Server updates. Update Planner handles updates and upgrades all within the same interface, further simplifying vCenter Server lifecycle.

Prerequisites

When a new feature becomes available there can be a sense of curiosity, or how will this help me, or what should I be aware of before using that feature. To help with those unknowns, let’s discuss a few prerequisites to consider when using Update Planner.

• Update Planner is intended for upgrading from vSphere 7 to a higher version or update (example: Update1)
• Update Planner does not assist moving from older vSphere versions to vSphere 7, as the feature is specific to vSphere 7
• You must join the VMware Customer Experience Improvement Program (CEIP) to use Update Planner.
  • vCenter Server must have access to the internet to participate in CEIP either directly or via proxy
  • Update Planner (along with; Skyline Health for vSphere, vSAN Performance Analytics, vSAN Support Insight, Host Hardware Compatibility, etc.) uses this path to query VMware Product Interoperability Matrices online and report findings via the vSphere Client
  • Learn more about CEIP in the vSphere Client. Join or Leave the CEIP program easily from the same interface (see below)

Update Planner

Let’s discuss some of the things that this new feature can do for customers. Update Planner enables the ability to manage vCenter Server updates and upgrades as well as create interoperability reports for compatibility requirements. These reports will help plan vCenter Server updates and upgrades within your vSphere environments. Planning for an update is also simplified. One of the most important steps when planning an upgrade is to check and verify compatibility by visiting the

Update Planner automates the following steps of planning an update:

• Discover the current vSphere version and details
• Verify compatibility against the target vCenter Server version
• Verify interoperability of the target version with other products
• Recommend, Create, and Test vCenter Server update plans

When logged into the vSphere Client, from the vCenter Server Summary page, an Administrator can quickly see when new updates become available. If either of those alerts is clicked (View Updates or Updates Available), the vCenter Server Update Planner is launched. The available update is displayed in Update Planner along with some valuable info about the update; Release Date, Version, Build, Type, Severity, Reboot Required, and Release Notes. Now it is even easier to find the Release Notes for the software version as a link is provided in the results.

Administrators can quickly run Pre-Update Checks to ensure the system meets the minimum requirements to upgrade.

In this example lab environment above I do not have any additional VMware products installed yet so my Interoperability report is blank. If more products were part of my environment, it may look like this sample data below.

This data can also be exported as a CSV file for reporting purposes. Products that are not detected, can be added manually by clicking the Modify Product List button.

Having these new features and information readily available at the vSphere administrator’s fingertips while using the vSphere Client is critical. Overlooking a product in the datacenter or omitting a step in the upgrade process can cause unwanted or unexpected results. Allowing Update Planner to perform interoperability and pre-checks, avoids any missed steps by bringing it all into one view.

Closing

As a recap, Update Planner increases the accuracy of planning for a vCenter Server upgrade by querying online interoperability matrices to report which products within your vSphere environment meet the minimum software and hardware requirements for a successful upgrade of vCenter Server. As we move closer the Update versions of vSphere 7 (ie; Update 1 or Update 2), expect to see additional content to support updating to these releases. This video also discusses Update Planner in vSphere 7.

If you have any questions, please be sure to comment on the blog or you can find my on Twitter: @vCenterNerd

We are excited about vSphere 7 and what it means for our customers and the future. Join us Monday through Thursdays through April 2020 for posts highlighting the new features, capabilities, and improvements in vSphere 7 and vSphere with Kubernetes. It’s easy to stay informed, please follow us directly using the RSS feed, on Facebook, and on Twitter.

The post vSphere 7 – Update Planner appeared first on VMware vSphere Blog.

Data center infrastructures are only as resilient and available as the implemented protection strategy. Natural disasters, connectivity disruptions, power outages, or criminal infiltration are all examples of real scenarios that threaten the utilization, integrity, and security of the infrastructure-resident data. A comprehensive data protection solution will not only consistently protect and backup infrastructure data, but also facilitate timely recovery of this data when this becomes necessary.

Comprehensive data protection is critically important for all infrastructures.

It is for this reason that VMware Cloud on Dell EMC has partnered with Dell EMC to offer Dell Data Protection for VMware Cloud on Dell EMC. Dell Data Protection solutions take a comprehensive full-system approach to protecting data and offer a broad portfolio of software and hardware products enabling a high-degree of solution choice and customization.

The VMware Cloud on Dell EMC and Dell Data Protection teams recently presented a webinar that discussed how Dell Data Protection provides comprehensive data protection and recovery capabilities for VMware Cloud on Dell EMC, regardless whether deployed on-premise or at the edge.  You can watch a replay of this webinar  or download the associated solution guide – both which explain how VMware and Dell EMC together provide customers with a fully protected, fully managed infrastructure as-a-Service on-premise or at the edge that is delivered as a subscription with monthly billing.

The post Protecting VMware Cloud on Dell EMC with Dell Data Protection appeared first on VMware vSphere Blog.

VMware Cloud on Dell EMC is a fully assembled and configured SDDC as a service offering that runs in your on-premises edge or data center location. Simply select the number and size of Dell EMC VxRail hosts needed in a deployment and leave the rest to VMware – we manage the lifecycle and operate this infrastructure as a cloud service.

Each VMware Cloud on Dell EMC SDDC rack deployment arrives ready to run your applications. But there are a number of integrations that most customers deem necessary for a new technology stack to become a seamless extension of the existing on-premises infrastructure.

For the next series of posts, I will be showing how to integrate the fundamental services of your enterprise, such as DNS, DHCP, and Active Directory authentication. In addition to that, we’ll review how to consolidate the administrative view of the new SDDC and your existing vSphere environment with hybrid linked mode (HLM). Later, we’ll wrap up the series with an overview of how to extend existing networks onto the new SDDC so that applications can migrate without the need to change IP addresses and without downtime – thanks to live migration with vMotion.

DNS on the VMware Cloud on Dell EMC SDDC

Let’s face it – no administrator or developer has ever enjoyed typing IP addresses. Besides being tedious and inefficient, it’s often difficult to remember specific addresses outside of a small lab network, and mistakes can lead to highly undesirable outcomes. By default, a new VMware Cloud on Dell EMC SDDC is configured to forward DNS resolution requests out to a well-known public DNS provider on the Internet. This is a fine approach for certain use cases – for instance, you’d still be able to download OS patches and updates with this setup – but not likely appropriate for a production data center deployment.

In order to use internal names, instead of IP addresses, to access your servers and services, you’ll need to configure VMware Cloud on Dell EMC SDDC networking so that your existing internal DNS servers can be queried.

Recall that VMware Cloud on Dell EMC is equipped with NSX-T, which is one great benefit of the fully managed SDDC as a service. Traffic in and out of the SDDC is split between two NSX-T network gateways. The management gateway handles traffic to vCenter Server, VMware ESXi hosts, and certain other essential communications. The compute gateway is for your VM workloads and it routes traffic from one or more network segments on the SDDC to other networks outside of the rack.

An NSX-T gateway exposes one or more IP endpoints to support network services such as DNS or VPN. As an aside, these addresses are allocated from the SDDC Management Network – a /24 CIDR subnet that is specified during initial SDDC ordering phase – and this is one of the reasons why this network must be routable within your data center.

The DNS Service IP is an address that the management components or workloads use for name resolution services. This is accomplished via a forwarding service on each gateway that queries upstream DNS servers. You can optionally set up several different upstream destinations that are directed conditionally, depending on the FQDN. This offers great flexibility for complex environments, but most deployments should be satisfied by pointing to a set of centralized corporate DNS servers.

If you decide to connect your existing vSphere environment with the new SDDC through HLM, or if you intend to perform migrations from one to another, the management DNS service must be integrated with your existing naming services. In order to execute these workflows, the VMware Cloud on Dell EMC SDDC will need to resolve and connect to your existing vCenter Server environment.

On the other hand, the compute gateway DNS service is used by the guest operating systems to resolve other services in your environment such as databases, services, or administrative operations like patch management. If necessary, the two gateways can point to different upstream DNS services.

To change the default upstream DNS server addresses, simply log into the VMware Cloud Services portal and navigate to the Networking & Security section. The DNS settings are on the lower left navigation under the System heading, as shown below:

Keep in mind that these DNS configurations are completely transparent to applications on the SDDC. Workloads connected to a network segment and configured to use the built-in DHCP server will be automatically assigned the DNS Service IP on the compute gateway. The client is unaware of the forwarding mechanics described above. As you can see in the image below, the guest OS has obtained the DNS Service IP (10.174.68.141) as its sole DNS server. Resiliency is provided by NSX-T internals, so multiple addresses are not needed as they would be with more traditional networking.

Takeaway

VMware Cloud on Dell EMC is built from the full VMware SDDC stack, including NSX-T for network virtualization. This enables administrators to have flexible control of DNS services that the management and compute components rely on for name resolution. VMware is still responsible for lifecycle management of the SDDC, but because this is delivered as a service, valuable IT resources can focus on running the business and not maintaining infrastructure.

For more information, visit the VMware Cloud on Dell EMC website , follow us on Twitter @VMWonDellEMC, or read the VMware Cloud on Dell EMC Technical Overview Paper Released.

The post How VMware Cloud on Dell EMC Integrates with your Enterprise DNS Services appeared first on VMware vSphere Blog.

It’s an exciting time to be a vSphere administrator! vSphere 7 is now available and there’s lots of really cool things incorporated into it. What I’m going to introduce to you in this blog is the vSphere Pod Service. If you have been following any of the Project Pacific announcements and content from VMworld 2019 some of this will be familiar to you. This blog is another in a series of blogs discussing vSphere with Kubernetes not from the developer side but from the vSphere administrator perspective.

The first thing we’re going to talk about is the vSphere Pod Service. Before we dive into that, a quick recap on what Kubernetes is and then how vSphere Pod Service fits in.

Kubernetes is a platform for managing containerized workloads and services. When you deploy Kubernetes, you get a cluster. Several components are instantiated as part of that process.

• Nodes: Every cluster has at least one worker node.
• Pods: These are the components of the application workload running on the worker nodes
• Control Plane: This manages the worker nodes and the Pods in the cluster and runs across the cluster, providing fault tolerance and high availability.

What is the vSphere Pod Service?

vSphere Pod Service is a service that runs on a VMware managed Kubernetes control plane over your ESXi cluster. It allows you to native Kubernetes workloads directly on ESXi. The ESXi hosts become the Nodes and vSphere Pods are what are running the components of the app workloads.

Now why would I want to do that? What’s the advantage of running it this way? We’ll get into that in just a moment.

vSphere Pod Service Background

vSphere Pod Service is a fundamental re-architecture of ESXi. There were many ways in which we could address the needs of Kubernetes and container workloads running on ESXi. For example, we had previously released vSphere Integrated Containers. It had containers running on VMs and managed by VMware Admiral, a container management platform. But it wasn’t Kubernetes and we thought we could do a better, more deep and native integration with vSphere.

Operationally, the way forward is declaring what you want and letting the infrastructure supply it. This is true not only from the developer standpoint but from the administrator standpoint as well. But in order to accomplish this we didn’t want (or need!) to re-invent the wheel. We have a great platform in vSphere. To toss all of that overboard and start over is not only very expensive and disruptive, it means those customers that depend on it would have to do the same thing and learn everything new from scratch. We have many customers who depend on vSphere. The have processes in place that are integral to their business. They also need to do things like pass security audits or accomplish backups!

Wouldn’t it make more sense to leverage what we have, provide equal or better performance and scalability AND bring our customers along on this journey? As someone who has been in and around IT for 35+ years in makes complete sense to me.

vSphere Pod Service Components

vSphere Pod Service Spherelet

The Spherelet is based on the Kubernetes “Kubelet” and enables an ESXi hypervisor to act as a Kubernetes worker node. The Spherelet is an ESXi UserWorld agent that acts as an extension to the Kubernetes Control Plane. Its primary function is to poll the Kubernetes Control Plane’s API server for changes made to pod configuration, volumes, services, configmaps and secrets and then carry out the necessary operations to ensure that these are instantiated.

Figure 1 – vSphere Pod Service – vSphere Admin connects to vCenter. DevOps connects to the K8S Control Plane

CRX (“Container Runtime for ESXi”) Agent

In my opinion, this part is one of the coolest parts of the underlying architecture. Remember, ESXi is not Linux. The vSphere Pod Service provides a purpose-built lightweight Linux kernel that is responsible for running containers inside the guest. It provides the Linux Application Binary Interface (ABI) necessary to run Linux applications. Since this Linux kernel is provided by the hypervisor, VMware has been able to make numerous optimizations to boost its performance and efficiency. Additionally, because the CRX kernel does not load a full Linux guest OS, the instantiation of new vSphere Pods is very fast.

That’s right. We are not loading a full Linux guest OS. Just a very optimized kernel and init process called CRX Init. The Linux kernel used gets updated when you update ESXi via normal lifecyle management.

As with everything on ESXi, this will be shipped in a VIB. And if you followed my previous blogs on Secure Boot for ESXi, that means this Linux kernel is contained in a digitally signed package so that when you turn on Secure Boot it is verified to have not been tampered with. So not only is CRX a great way to run containers it is inherently more secure as well!

The CRX Agent looks very similar to the VMX because that’s where it started out. The key difference is that anything to do with a guest OS was pulled out.

• USB connectivity? Gone.
• Video display hardware? Gone.
• Anything else that’s not needed is removed.

All these changes make the CRX super lightweight. The over-used adage of “It has to be on bare metal to have performance!” or “Running on a VM introduces too much overhead!” is now ancient history. To vSphere a vSphere Pod looks essentially like a specialized Virtual Machine. That means from a vSphere Admin standpoint it looks and feels “familiar”. You’re not learning a whole new thing. We’ll dive more into the CRX in a future blog article.

hostd

“hostd” is the UserWorld agent on the ESX host that the Spherelet communicates with to query the hardware properties of the vSphere Pod and reconfigures it to attach container image VMDKs or NICs. The communication channel with hostd is over a localhost HTTPS connection that is authenticated using local tickets. The session is authenticated using the DCUI user which is guaranteed to be able to perform VM reconfigure operations even in lockdown mode.

Image Service

The Image Service is responsible for contacting the container image registry and staging the container image on a VMDK that will be attached to the vSphere Pod by the Spherelet. It leverages Harbor and each team gets their own project to share.

Kubernetes Control Plane API

The Kubernetes Control Plane API is the central endpoint that validates and configures all the API objects representing entities in the Kubernetes cluster including pods, services, volumes, controllers, etc. It exposes a REST endpoint that kubectl connects to, to make requests on the API objects. It also provides the frontend to the cluster’s shared state through which all other components in the cluster interact. The API is polled by other controllers in the cluster (such as the Kubelet) for changes to the API objects so that it can propagate changes to the cluster state.

Ephemeral VMDK

Each vSphere Pod is provisioned with a VMDK that is used to stage the container logs, the emptyDir volume and configmaps. The lifetime of this VMDK is tied with that of the vSphere Pod. Any data written to this VMDK will be lost when the pod has completed running. Ephemeral VMDKs are provisioned by the DRS scheduler extension but are formatted and staged for use by the Spherelet Agent when instructed to do so by the Spherelet. Because this is a VMDK it is storage agnostic. Any storage that is supported by vSphere will work.

Container Image

Containers that comprise the pod will have their container images mounted into the vSphere Pod as VMDK images. Container images are pre-populated into VMDKs by the Image Service and need to be provisioned prior to the pod startup sequence.

When do I use vSphere Pod Service?

While the vSphere Pod Service uses Kubernetes, it’s not a conformant Kubernetes cluster. This is by design, as it intends to use Kubernetes to improve vSphere, rather than trying to turn vSphere into a Kubernetes clone. As Joe Beda says, it’s a Platform Platform. If your developers require standards-based and fully conformant with upstream Kubernetes clusters then you can use Tanzu Kubernetes clusters, also referred to as “Guest” clusters.

Some example use cases for vSphere Pod Service are those that can be in lockstep with the ESXi lifecycle. vSphere Pods are not where you want to run the latest and greatest Kubernetes and all of the 3^rd party tools used during development. vSphere Pods provide unique security and operational advantages such as leveraging the proven ESXi isolation techniques that may, at this time, be interesting to some unique/particular workloads. vSphere Pods don’t allow direct access to hardware, another security advantage.

Figure 2 – vSphere Pod Service – Advanced Security and Performance

For most developers and users, TKG clusters are the way to go because they fully conform to Kubernetes and they allow you to incorporate 3^rd party extensions and tools that hook into Kubernetes.

Wrap Up

I hope that this has given you, the vSphere Administrator, a useful overview on what the vSphere Pod Service is all about. If you have questions or ideas on the content a vSphere Administrator would be interested in when it comes to vSphere with Kubernetes, then reach out to me on Twitter. I’m @mikefoley and my DM’s are open.

Thanks,

mike

The post vSphere 7 – Introduction to the vSphere Pod Service appeared first on VMware vSphere Blog.

On April 9, 2020 VMware published VMSA-2020-0006, outlining a serious vulnerability which may affect vCenter Server 6.7 and external Platform Services Controllers (PSCs) if certain criteria are met. This post is intended to help VMware customers and partners understand the issue better by collecting common questions. It is not intended to replace official VMSA communication. All customer environments are different and critical issues such as this should start an immediate conversation between your organization’s management, information security personnel (CISO, etc.), and IT operations.

Please Read

The following links will help you determine if you are affected by this issue. Please read them before continuing.

• VMware Security Advisory VMSA-2020-0006
• Additional Documentation for VMSA-2020-0006: Determining if a vCenter 6.7 deployment w/embedded or external Platform Services Controller (PSC) is affected by CVE-2020-3952 (78543)

VMSA-2020-0006 (CVE-2020-3952)

What it is: Please read the VMware Security Advisory for the description, and while you’re there sign up for the security advisory mailing list using the form on the right.

What you need to do: Find all instances of vCenter Server 6.7 and external 6.7 Platform Services Controllers that were upgraded from a previous vSphere version, as described in the VMSA, and update them using the standard patching process. As the vCenter Server Appliance VAMI may offer several patches please ensure you are selecting the latest one. Also ensure that you are updating ALL vCenter Server Appliances as well as ALL Platform Services Controller instances. As always, ensure you have a backup of the affected systems prior to patching. If in doubt, assume you require the update.

What effect will it have: Patching will close the vulnerability directly, and you can move on knowing you are secure.

So… should I be worried?

Organizations that don’t have a regular cadence for patching & updates or whose organizational structures make it nearly impossible to make changes in a timely fashion should be very worried. Even rigidly structured frameworks like ITIL support the concept of “emergency changes” and this would certainly qualify.

The best way to handle this issue is to patch it directly using the normal update procedures, such as through the VAMI on the vCenter Server Appliance.

Compensating controls, such as firewall rules on the vCenter Server Appliance, makes an environment more complicated and do not actually fix the underlying problem. Compensating controls and workarounds are like a cast on a broken leg. They don’t heal the wound; they just cover it up to help protect it. Over time the cast becomes a problem of its own. These workarounds make you less flexible, just as a cast does. They slow you down, just as a cast & crutches do. They also complicate operations by having their own rules and requiring their own maintenance. For example, “don’t get your cast wet” means a lot of normal activities are now really, really hard. Your cast will require its own maintenance, too, as it gets smelly and itchy. Same for the workarounds.

You WILL spend much less time and effort overall if you just fix the problem outright by patching. This is borne out in experience and studies of IT over the last 40 years.

While we always recommend running current versions of all infrastructure software, you can patch vCenter Server and the Platform Services Controllers independently of ESXi. A common misconception by non-technical managers, and change management staff unfamiliar with vSphere capabilities, is that workloads are affected by vCenter Server patching. Workloads do not stop running when vCenter Server and the Platform Services Controllers are rebooting. Only VM management operations like console access, power on/power off, resizing, etc. would be affected for the duration of the update process. Direct access to VMs, such as via RDP or through an application’s normal interface, continue unaffected. It is often worth outlining this directly in proposed change documentation.

Frequently Asked Questions

How do I know if I am affected?

Read the VMSA and the associated KB article for details. If you are unsure, always proceed as if the patch is required.

I cannot patch my environment. Is there a workaround for this?

As the VMSA states there are no workarounds. There may be compensating controls, drawing on any defense-in-depth your environment has.

When you say “compensating controls” what do you mean?

As the PCI Security Standards Council defines it, “compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other controls.”

In short, they are other, more roundabout ways of achieving the same security goal without using the specific control that’s listed. In this case, using isolation techniques (network segmentation, firewalling, etc.) might be a compensating control, but that is a discussion between you and your information security staff.

When you say “isolation” what do you mean?

Isolation is where you use technologies like network segmentation, VLANs, firewalls, and such to separate assets based on the function of the asset. For instance, the VMware Validated Design is the documentation for a reference implementation of VMware vSphere and other products like the vRealize Suite. It outlines the use of VLANs to separate hypervisor management traffic from workload traffic. This separation would then be further enforced with firewalls. Implementing controls like this is a discussion between you and your information security staff.

How do I create firewall rules on the vCenter Server Appliance?

Please refer to the documentation, Edit the Firewall Settings of the vCenter Server Appliance, or contact VMware Global Support Services. Please test this in a dedicated test environment, and ensure you create a rule ALLOWING access for yourself prior to creating rules that deny access.

Does this affect vCenter Server instances with SSH? If I disable SSH will that fix it?

We always recommend disabling SSH because, in most cases, it is not needed for management and configuration and disabling it eases compliance audits and improves security. However, in this case changing the state of SSH will not affect this particular vulnerability.

Does this affect Windows installations of vCenter Server?

Yes, the VMSA describes the versions affected.

Does this affect vCenter Server 6.5?

The VMSA describes the versions affected.

What if I migrated from Windows vCenter Server 6.5 to the appliance version of vCenter Server 6.7? Do I still need to patch?

Yes. The VMSA describes the versions affected.

How can I get the fix for this issue without updating all of vCenter Server?

As the VMSA states there are no workarounds. As such, the patch for this vulnerability is only found in the complete update to the version of vCenter Server listed in the VMSA.

Can I update my Platform Services Controller and not patch vCenter Server?

During normal operations vCenter Server and the Platform Services Controllers need to be kept at the same versions to ensure compatibility and supportability.

Are other products that use vSphere affected?

VMware Cloud Foundation is updated rapidly once the patch is available and tested. For other integrated solutions please ask the vendor directly.

The post VMSA-2020-0006 & CVE-2020-3952: What You Need to Know appeared first on VMware vSphere Blog.

We greatly improved lifecycle management in vSphere 7. The new innovations for lifecycle management in vSphere 7 make it easy for customers to have consistent and up-to-date systems. The major lifecycle management improvements in vSphere 7 are vCenter Server Profiles, Update Planner and vSphere Lifecycle Manager (vLCM).

vCenter Profiles is way to ensure configuration and version consistency across multiple vCenter Server instances. Update Planner helps in making sure the latest updates are checked for product interoperability and installed for the vCenter Server Appliance (VCSA). vLCM is a comprehensive collection of abilities in vSphere 7 for consistency across ESXi hosts and easier ways to update hosts. This blog post focuses on vSphere Lifecycle Manager (LCM).

vSphere Lifecycle Manager (vLCM)

Consistency across ESXi hosts is essential for creating reliable and high performing platforms, but is difficult to obtain, especially at scale. vLCM solves the complexity by enforcing consistency across ESXi hosts in a cluster using a declarative model. vLCM not only accomplishes this by using an ESXi base image but extends it with the desired state for firmware and driver versions as well.

The goal is to remove variability between ESXi hosts. This will enable customers for more efficient upgrades, improved reliability and performance, and easier overall maintenance. The most important capabilities of vLCM are its desired state model, the integration with hardware vendors for full-stack firmware updates, and simplified OEM image customizations, along with automatic compatibility checks.

Declarative ESXi Cluster Management

The foundation of vLCM is the declarative cluster lifecycle management. The vLCM desired state of an ESXi host represents the target ESXi version, and firmwares & drivers version for the host as opposed to the versions that it currently runs. Once vLCM and cluster image management is enabled for a cluster, a desired state is set up. All the ESXi hosts in the cluster adhere to the desired state. When a host drifts from the desired state, the host is remediated to be complainant to the desired state.

When a vSphere 7 cluster is configured to use a single cluster image, vLCM will replace the baseline methodology used in vSphere Update Manager (VUM).

An cluster image consists of the following components:

• ESXi version: A base ESXi image supporting vSphere ESXi 7.0 or later.
• Vendor Addon: Package provided by the supported host vendor that potentially includes hardware providers, vendor firmware and drivers.
• Firmwares & Drivers: Customers can include additional firmware and drivers that are not included in the vendor addon. For example, when using an async driver for a hardware accelerator or NIC.

Configuring a cluster image is easy, following the wizard under Cluster > Updates > Setup Image. The compatibility check includes verification of currently installed vibs (kernel modules). For example, you might see warnings about vibs when you are used vendor specific ISO’s. These modules can be added as vendor addon in the image. Please note that QuickBoot is supported for vLCM, but has to be enabled manually.

When the cluster is managed collectively using the same image and all hosts are remediated, vLCM shows everything is up to date.

The Image Depot in vCenter Server is used as a repository for all vLCM components. When the vCenter Server is connected to the internet, it will automatically download ESXi base images and vendor components. If a proxy is required, vLCM uses the proxy settings from vCenter Server Appliance. If there’s no direct internet access, the Update Manager Download Service (UMDS) can be used, or updates to the image depot can be imported manually.

Full Stack Firmware Updates

A Hardware Support Manager (HSM) may be used to integrate with vSphere to check, but also update firmwares and drivers on the system, directly from within the vSphere Client!

The HSM is software provided by the hardware vendor as i.e. an OVF image. It includes a plug-in that registers itself as a vCenter Server extension. Hardware vendors provide and manage the firmware & driver updates that are accessed by vLCM using the HSM.

In the initial vSphere 7 release, Dell OpenManage and HP IlO Amplifier are supported. Check out this demo to see how vLCM with HSM is used to remediate ESXi hosts and updates firmwares and drivers:

Simplified OEM Customization

vLCM allows for customers to streamline OEM vendor components into the image. The vendor components and the ESXi image are disassembled in vLCM, making it easier to update the vendor specific components when a new vSphere release is issued. Effectively replacing the need for vendor specific ISOs as this capability replaces this. Vendor addons include vendor customizations for selected servers.

Cluster Quickstart Workflow

When configuring a new cluster, customers have the ability to implement a declarative ESXi host image for the cluster immediately. The image setup in the cluster quickstart workflow allows for choosing an ESXi base image and the optional vendor addons.

Creating the cluster using quickstart with single image cluster management allows customers to benefit from vLCM capabilities from the start.

To Conclude

We’ve invested a lot in making vSphere lifecycle management more efficient. vSphere 7 is a great step forward to achieve this. In the coming weeks, we’ll publish more blogs and demos on everything vLCM. The next blog post covers lifecycle manager compatibility checks. Stay tuned!

More Resource to Learn

• Top-3 New Features in vSAN 7: #1 – vSphere Lifecycle Manager
• vLCM on docs.vmware.com
• vSphere 7 – Content Library
• Introducing vSphere 7: Features &#038; Technology for the Hybrid Cloud

We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.

The post vSphere 7 – Lifecycle Management appeared first on VMware vSphere Blog.