Virtualization Fundamentals

0:00Hello and welcome. My name is Keith Barker. And in this set of videos, you and I get to put the fun into virtualization fundamentals. So in the next video, we'll take a big picture overview look, and I'll walk through step-by-step with many of the concepts and examples of using virtualization today inside of vSphere environment. So I'll see you, my friend, in the next video in just a moment.

0:00In this video, I'd like to give you a big picture look at many of the components and parts regarding the VVF, including what that stands for. So VVF from Broadcom is VMware, vSphere, and the F is for Foundation. And that is one component instead of a bigger offering of services called VMware Cloud Foundation or VCF. So in this set of videos and in this course, we're going to be focusing on VVF, the VMware vSphere portion of it with some add-ins from Broadcom as part of the overall VVF solution. So in this set of videos, let me give you an overview regarding what we're going to take a look at and select as our roadmap for this skill, for this set of videos. So to begin with, let's take a look at the operating system that we're going to use to provide these homes for these VMs. And this operating system we're going to use as the home for the VMs from VMware is called ESXi. And it is an example of a hypervisor. So an example is we have a piece of hardware, for example, a server, and that server, instead of running a typical operating system, would run ESXi. And then on that host, on this ESXi host, it could then run multiple VMs and other things like containers and Kubernetes and other services

1:15as well. And the core job of an ESXi host is all about abstraction, specifically resource abstraction. And here's what that means. The ESXi operating system running on this host is taking all the resources like CPU and memory and storage and network access, and it presents virtualized versions of those resources to the VMs that are running. Those VMs are often referred to as guest OSs running on those little virtual machines. And ESXi is referred to as a type one hypervisor, meaning it is running directly on the bare metal hardware. We don't have an operating system like Windows or Linux or something else between ESXi and the host, and as a result, it's referred to as a type one hypervisor. So that's one of the elements we're going to take a closer look at in this set of videos. So now that we understand what ESXi is in concept, let's also take a look at how it does that. And the way it does that is with the VM kernel architecture. And the VM kernel architecture effectively is the core guts and functionality that the ESXi host is using to provide this virtualized environment for VMs. So it's not Linux, it's not Windows, it is a purpose-built microkernel designed exclusively to manage virtual machines and

2:31facilitate their access from the VM to the hardware resources that they need. And one of the cool aspects about this VM kernel architecture and supporting VMs is that it provides isolation. So you can have two virtual machines, let's call this virtual machine A and virtual machine B running right here next to each other. But even though they're running on the same physical host, they are isolated from each other. So that means the memory and the disk usage and so forth is all isolated and protected between those two VMs. So we can have a multi-tenancy environment with multiple VMs running here, one VM won't impact or disrupt the other VM. Now, there are some things that can come into play like resource utilization and using tons of CPU, which might deprive another VM, but we'll take a look at solutions for that as well as we continue on through the course.

3:18Another thing that I'd love to chat with you more in detail about in this set of videos is the VVF suite or stack. Think of it like a set of tools and features that we can use as part of our overall vSphere environment. Also in the past, when somebody said vSphere, I'll put that in quotes there, vSphere, that implied many different components. And so now as we take a look at VVF, we're referring to those same many components plus a few additional ones that Broadcom has integrated as part of the VMware vSphere foundation. So as a sneak peek at some of those features, we have the ESXi host software that's part of that. There's also the ability to centrally manage a full bunch of ESXi hosts using vCenter. Again, another component as part of VVF.

4:03There's also storage management as part of that, and that storage could be collectively ESXi host pooling their storage here or interacting with network attached storage or other network types available over a network, including the use of different types of file systems like NFS or VMware's VMFS and others. There's also support for Kubernetes for logging and monitoring as well as alerts. Also in this set of videos, I'd like to chat with you about some use cases along with additional features that are part of a VPF environment so you can have a familiarity with what those features are before we go in to start configuring them. We'll also take a look at VMware vSphere foundation value propositions involving total cost of ownership and why many companies are moving not only to cloud services to third party but also having on-prem cloud services as part of a VMware solution. So this will be our roadmap for this set of videos and with that in mind in the very next video, I'd like to take a deeper dive into the wonderful world of the host software called ESXi that provides this environment for the VMs. So I'll see you in the next video for exactly that.

0:00In this video, we're going to take a look at the foundational concepts that make everything else inside of VBF possible, and that is the ESXi host, which is a hypervisor. And a hypervisor is a fancy word for saying an operating system or a system that allows or supports the livelihood or the life of individual VMs. It's also worth taking just a moment and looking at the history before we start using hypervisors. So a long, long time ago in a galaxy far away, when I first got in the world of IT back in the 80s, when we wanted to have a server and put it on what would be then a functional internet, we'd have to either get a service provider or host our own and have a physical server. So there's server one, and we'd have that online, set it up in DNS, and then people could access it and use it.

0:48So maybe this is an application server for application number one running on server number one. And then we have, for example, another server that's running application number two. Maybe it's a database server. Maybe this is an e-commerce server here. And maybe we have another server that's just acting as a database. So there's four servers. Now, the challenge is that a lot of these servers would be utilized, for example, 10 to 15 percent of their utilization, and everything else is wasted. And so in the old days, we had a one-to-one correlation between a customer site, for example, and or their applications they were running and a physical host. And so with a hypervisor, we're breaking that model. And then with all these servers, they have to be purchased and powered and cooled and maintained, et cetera, et cetera, regardless of how busy they are. So with the hypervisor, what we're doing at the software layer is we're breaking the one-to-one relationship between, for example, physical hardware and the apps and services that use that hardware. So in this scenario, instead of having four separate physical machines, we have one larger physical machine with CPU, RAM, network access, and so forth. And then we could run those servers or services as virtual machines and or as services that are containerized. So there's one, two, three, and four. And let's say we have some room for a

2:04few more as well that's connected to the network. And with ESXi software and control of that hardware, it can divvy up and isolate the resources that are being used. And then we have less physical servers to deal with. And it creates the illusion, this is the cool part, it creates the illusion to the VMs that are running here that they have their own dedicated space, when in reality, they are sharing a bigger computer. And because of that isolation and the trickery, if you will, that's being provided for each of the VMs, and each one of those VMs, again, believes it has the dedicated resources being provided to it via the hypervisor. Now, today we have cloud services from Google, and Amazon, and Microsoft, and they'll have their own implementation of their flavor of hypervisor providing services to customers, whether it's software as a service or infrastructure as a service, they have their own hypervisor. And so from a VMware perspective, from Broadcom, that hypervisor is called ESXi. And it is a type one hypervisor. Now, what does that mean a type one? A type one hypervisor is installed and has direct control of the hardware.

3:11What does that mean? Well, if we install software directly on the hardware, meaning there's no other operating system like macOS or Windows or Linux or anything else, but we install software directly on the hardware, that's providing an environment for the virtual machines, that is referred to as a type one hypervisor. It runs directly on the physical hardware, there's no host operating system beneath it. It's just a direct connection between the ESXi software and the hardware that it's running on. So some examples of type one hypervisors, of course, are ESXi, which we just mentioned. There's also Hyper-V from Microsoft and others. Now, Hyper-V is kind of interesting because you have a Windows server, and then you enable Hyper-V. And so you still have the Windows server running and the Hyper-V is available. So how is that a type one? Well, behind the scenes, Hyper-V has direct access to the hardware, so it's also considered a type one hypervisor. And the hypervisors are purpose-built for performance and stability and security, including being used in production environments. And because there's no general purpose operating system like Windows or Linux beneath that, the attack surface is dramatically smaller than it would be if we had another type of hypervisor that ran on top of a general purpose operating system, which brings me

4:26to type two. So with type one, it's referred to as a bare metal hypervisor because it's running directly on the hardware. With a type two, it is running on top of or like an application on top of another operating system. For example, VMware has a product called VMware Workstation, and they also have a product called VMware Fusion. VMware Workstation runs on Windows, VMware Fusion runs on a Mac, and then inside of VMware Workstation or inside of VMware Fusion, it generates an environment to support virtual machines. But because it looks like this, so here's the hardware, and then we have, for example, Windows as the operating system. And then as one of our apps, we're running VMware Workstation. And then inside of VMware Workstation, we can support our VMs.

5:10So with a type two with VMware Workstation here, between VMware Workstation and the actual hardware, we have our general operating system of Windows, and that's what makes VMware Workstation and VMware Fusion for Mac, that makes them a type two hypervisor. So generally speaking, in a production environment, we are going to want to use bare metal hypervisors that have direct access to the hardware. And for like testing or pet projects, if you will, we might want to use type two for testing a virtual machine or working with it. But in a production environment, very likely we're going to have physical hardware with a bare metal hypervisor as a type one hypervisor. And that's exactly what ESXi is. So let me clean it up a little bit. And let's talk about some of the benefits of ESXi as a type one bare metal hypervisor. One of the main benefits is that it's purpose built. There is not a lot of fluff inside of an ESXi operating system.

6:03It supports the VMs, has direct access to the hardware. It does provide a graphical user interface so we can interact with it. But it is purpose built. And that's also because it's not a general purpose operating system. It's going to have less attack vectors available for compromise. And also one of the core components as part of ESXi is the VM kernel. So whenever you see the term VM kernel, just think, oh, that's like the guts or the operating system that ESXi is using. And so to manage the ESXi software, we can log in directly to the host. There's a graphical user interface there that's called the VMware host client that we're using to interact directly with the host. And there's also a graphical user interface to interact with what's called vCenter.

6:48So think of vCenter like a manager that's going to interact with our ESXi hosts. You can log into vCenter where there's one pane of glass or one place to go so that we can configure and monitor, et cetera, all of our devices. So we tell vCenter what we want to have done and vCenter makes it happen. And we log in here, that's called the VMware vSphere client, as opposed to logging in individually to an ESXi host, which is called the host client. At the end of the day, it's a browser on your computer that we're using, but it's simply who we're interacting with. Are we interacting with the vCenter server or are we interacting with a individual host? And so those are the terms, host client and vSphere client that are used to represent which tool we're using.

7:30And to provide these environments for little VMs is doing abstraction regarding the real resources. Now you might say, Keith, what do you mean real resources? Well, this host right here is going to have some CPU or many CPUs for that matter, very likely on a bigger computer. It's going to have some RAM, random access memory, we'll call that memory right there. It's going to have some storage or access to storage, and it's going to have network access. And instead of giving any of these VMs direct access to those resources, it's going to virtualize all those resources and present them as available to those VMs. So if we want one VM to have more CPU or more memory, or certain types of storage or certain network access, we can configure that on a VM by VM basis.

8:16And the hypervisor ESXi then provides those services virtualized to the VM. So let's imagine the host has 28 CPUs. And if that host has 20 CPUs for one of the VMs, let's call this VM1 there. Maybe we allocate it four CPUs. It's all going through the hypervisor who is presenting those CPUs as available. But from the client's perspective, from the VM's perspective, it sees it just as four. Perhaps on the physical host, we have 256 gigabytes of RAM. But maybe for this one VM, we've given it 64 gigs. And so that's what this VM believes. Now the actual VM, it may be running an operating system, for example, like Windows or Linux. And that's referred to as the guest OS. Think of it like a VM with its guest operating system being a guest of the bigger host.

9:08So these four computers here, these four VMs all represent virtual machines. And each one of them typically are going to be running their own guest OS. That breaks down a little bit when we get to containers and Kubernetes. But starting off here, we'll just look at these four VMs. They're all going to have their own individual guest OS. So for the storage for VM1, for example, let's say we have access to network storage. Let's go ahead and put it on this network right here. And so let's say we have, let's say 20 terabytes of storage. What we could do is allocate to this machine saying, you know what, we want you to believe that you've got 60 gigs. And based on the needs for that VM, perhaps we allocate that from high-speed storage or from a vSAN, depending on what we have available and also what the needs are for that VM. So behind the scenes, the virtual machine is going to have stored for it on disk, a VMDK file, which represents its logical hard drive.

10:06So from the VM's perspective, it doesn't know much about that VMDK file or physically where the storage is. All it knows is that from a guest OS perspective, it's making requests to the disk and getting responses and calling it a day. And behind the scenes, the hypervisor is the middleman making all that possible. And then for network access, ESXi also virtualizes that. So in this topology here, this host called ESXi-Nest-A has four physical network adapters are plugged into the physical network. However, we can present to the VMs and the guest OSes there, we can present logical switches with however many network adapters we want to with various properties and qualities, again, virtualizing the network. So if we wanted this VM to think, okay, you've got two network interface cards, they're both 10 gig each, so they're both one gig each. We can present that to the client and then the client and the guest OS there would simply use those network services as if they were physically attached to that VM. Although in the background, all these services have been virtualized by ESXi and are being presented and provided via the hypervisor.

11:11So think of the hypervisor as the middleman between the VM and the other resources that a VM needs. So one term that is used to describe what's happening here is the term abstraction. We're separating this VM here from the actual physical resources by providing a virtualized version of them. So that means that this VM doesn't necessarily have to run on this physical host, we can move it over to this physical host or this physical host, and it wouldn't matter to that VM because all these services, as far as CPU, memory, storage, et cetera, are all being virtualized and provided to it. And one of the terms that often comes up when working with VMware is the concept and term of vMotion. So vMotion means this, vMotion says, take a virtual machine that's running, so it's accessing disk, it's using memory and everything else that's running, and with vMotion, we can do a live migration, it's actually called vMotion, from this host and put it over here on this host. So this is VM1 here on host ESXi nest A, and then after the vMotion happens, it's now running on ESXi nest C. And because of the abstraction, the virtualization, this VM never notices and doesn't care. There's also an option called storage vMotion,

12:28which allows us to move which storage resources the client's using. So maybe we have a couple of different network attached storage devices, we'll call this device A and this device B, let's say they're both 20 terabytes. And currently, the client is using in the background virtualized, it's using some resources off of storage device A. With storage vMotion, we can move its disk files effectively from storage A over to storage B. So again, vMotion, moving the VM and its RAM over to a different physical host, and storage vMotion is moving the actual storage location behind the scenes of what that client is using. For example, from storage A to storage B. And you can do both of those at the same time with the tools provided in vCenter as we work with and manage our VMs. So with that in mind, in the next video, I'd like to take a little closer and more in depth look at the VM kernel as part of the ESXi offering from VMware. So I'll see you in the next video in just a moment.

0:00In this video, we're going to go one level deeper than just what is a hypervisor. We're going to pull back the hood on ESXi and take a closer look at the VM kernel to see actually what it is, how it's constructed, and why VM isolation is one of the most important architecture principles in the entire VVF stack. So let's start off with what exactly is the VM kernel. Effectively, it's the core operating system of ESXi. It's the hypervisor itself. So when a computer boots up that's running ESXi, for example, this host right here, what loads is the VM kernel. So there's no Windows operating system, no Linux distribution, no general purpose OS underneath it. It's just the VM kernel loading and running on that physical hardware. And it's purpose built with one job, and that is to manage all of the hardware resources on that host and present them to the VMs based on how we've configured those VMs.

0:56So based on how many CPUs, how much memory, how much disk, etc. So here's our VM, here's the hardware, and it's the ESXi host and VM kernel that's in charge of allocating and allowing those resources to flow between the VM that needs and asks for the resources and the actual hardware resources themselves. And again, those resources include CPU, RAM, and network access and storage. So the VM kernel, effectively, ESXi is responsible for the hardware resource management. It's going to give the virtual machines what they need so they can run. So I'll refer to that as VM execution. They can run based on the resources that are being provided by the VM kernel by ESXi. The VM kernel also is providing management interfaces as well. So if we log on with the browser directly to a host with the host client, or we log on to vCenter with the vSphere client, those management interfaces and agents are what allows us to interact with the host client or the vSphere client, as well as use the other tools to communicate and interact with the host.

2:01There's also, as part of ESXi, there's something called VMM, which is the VM or the virtual machine monitor. So each virtual machine that's running has its own virtual machine monitor, and it runs alongside the kernel, one for every VM. So when a VM's guest OS attempts to execute a privileged instruction or access a resource, something that normally would require direct hardware access, that VM monitor intercepts it and allows it to be handled. So effectively, the ESXi host is acting as the middleman, once again, between anything the VM might need and the actual hardware and resources that the VM is trying to access. Again, behind the scenes is the VM monitor that's doing that interception. So think of VMM as an extension or part of the ESXi host as part of the VM kernel running on that ESXi host. Another element that the ESXi host and VM kernel are managing and working with is the virtual machine executable, and I'll call that VMX. There's also a VMX file that's associated with the VMs that specifies the details for a VM, but in this context, the acronym VMX is the virtual machine executable. And what that's doing is managing the non-CPU aspects for running a VM, things like device emulation, the VM console, communication with

3:22the management layer, and things like that. And because there's a single VM executable per VM, if one of these process crashes, it doesn't bring down the whole system, it would only cause a problem for the specific VM it was running for. And on top of all that, regarding the resources the VMs may need, including CPU, RAM, network access, and storage, the VM kernel as part of ESXi is keeping total isolation between all the VMs. So even if these VMs right here, this one, and this one, and this one, and let's say all four of them are using the same shared storage, let's call it storage A, the actual blocks of data that are being used are going to be kept separate. So this VM is going to use some blocks here, VM2 is going to use different blocks, and VM3 is going to use different blocks, there's not going to be a shared overlap. And that's important for security. And that applies not just to storage, but also for access to memory.

4:15And isolation is what makes it operationally safe to run multiple VMs or multiple workloads with different levels of trust on the same physical hardware because of the isolation being provided by ESXi. So an example, we could have one machine here that's being used in production, and another machine here that we're using in a test or a dev environment, and they can both run on the same host. And because they're completely isolated from each other, this VM in dev shouldn't impact the VM that's being used as part of production. Another cool thing about the isolation is that this VM here can't directly compromise this VM here. Now, if we had two guest OSes, and they're both, for example, on this network, and they could reach each other, it's also possible that through normal tools and mechanisms, they could attack each other. But from a hypervisor perspective, it's keeping these two absolutely isolated and separate from each other. So now that we've taken a look at ESXi and the VM kernel and some of the magic it performs, in the next video, I'd like to walk you through some use cases and some really cool features that are available in a VMware vSphere environment. So we'll do that in the next video, and I'll see you there in just a moment.

0:00In this video, I'd like to do a few things, introduce some features and functions as part of vSphere with their use cases, and also more importantly, why an organization or a business would actually use those features. So the first case for most companies that are doing virtualization is for server consolidation. And that remains one of the most compelling reasons why organizations would adopt virtualization in general, including whether it's VMware or whether they're doing virtualization with another cloud service provider. And here's the problem it solves.

0:34Instead of having three or four or five or hundreds of servers, they can consolidate that into, for example, one or two hosts. I'd also like to use this opportunity to just refer to the idea that when I talk about an ESXi host, I'm very likely going to call it a host. It's just a key giveaway that I'm talking about ESXi. And then as I talk about VMs and the guest operating systems, I may refer to those as VMs or the guest OS, which represent the operating system running on a VM to help differentiate that.

1:07So here, instead of having one, two, three, four, five servers, perhaps we could use two servers, servers A and servers B. So server one, two, three, four, and five. So up here, we'd have VMs that are running. So let's say I have one, two, and three, they're running on host A, and then VMs four and five, which replace servers four and five running here on host B. So that's one of the first benefits of virtualization is the consolidation. So less hardware means less physical servers to maintain, less physical servers to upgrade when the time comes, et cetera.

1:41And in this example, we're going from five machines to two. However, we could actually, based on the hardware involved and how busy the workloads and the VMs are, we could have a lot more. So we could have literally dozens or hundreds of VMs potentially running here on host A, provided we have enough CPU, RAM, et cetera, to support the needs of those VMs. So if we consolidate our VMs, which I'll refer to as workloads here on these two hosts, what happens if we have a host failure? So in the past, if we lost this physical server, we've lost one application or one server. In this case here, if we lost host A, we're losing three logical servers, three VMs, three workloads. So how do we deal with that? Well, another cool feature, another cool use case is use the feature called HA, which is an acronym for high availability. And here's how HA works. In fact, let's use these three hosts that are in this topology. And each of them currently has four VMs. So if these three hosts were all placed in what's referred to as a cluster, think of a cluster as a fancy name for a group of hosts being used as part of VMware's vSphere. What we could do on that cluster is enable the feature called HA. And here's how HA works. HA is keeping track of the hosts in the cluster. And if there's

3:00a failure, let's go ahead and pick on, how about ESXi Nest A. If that host physically fails, has a problem, these machines all go down, boom, boom, boom, boom. However, with HA, it realizes, oh, that host Nest A had four VMs that were running. It will automatically restart those on one of the remaining hosts over here. Maybe it'll start a couple here and start a couple more over here so that at the end of the day, and actually just a few minutes, those VMs that were all running here on host A are now running over here across host B and host C. And that's referred to as high availability. So effectively with HA, we're rebooting the machines, the VMs that were on the host or host that failed and bringing them up on the other hosts in the cluster that are running.

3:49There's also safeguards in place that we can set up regarding capacity to make sure that we always have enough room and CPU and resources to run those additional VMs should we lose a single host. Another feature is the feature of fault tolerance. And that is different than HA. And let me tell you why it's different. With fault tolerance, we're actually running a replica, a second version of the same VM on two different hosts at the same time. So if this is a critical machine and we're running fault tolerance on it, that means we have one here and we're mirroring to another host, that same machine over here on host B. And that way, if this host fails, that fault tolerant machine, that VM, which is already running is now active on nest B. So fault tolerance is like a simultaneous running of a critical VM. Where with high availability, we're not doing the replication of the VM 24-7, but we're just planning on if a host fails, we'll start up the VMs on the other systems that are still running. Another really important feature that's really cool also is disaster recovery, or DR for short. And with DR, with disaster recovery, we're taking a look at an entire site. Let's say we have two sites or three sites or four sites, and we have a site on the

5:10West Coast, and we know that it's possible that that site could fail, have a problem or have an issue. So with disaster recovery, we are replicating from that site on the West Coast over to a secondary site continuously or on a scheduled basis so that if we lose a whole site, we have all that data replicated in another site that we can then activate and go ahead and use. And in a VVF environment, that disaster recovery can be scripted, we can test it, we can partially automate it just to verify that if we need it, if we have a problem with one of our sites, we can go ahead and bring everything up at the other site where it's been replicated to. And the functionality or that feature that exists as part of VVF that does that is referred to as the VMware Site Recovery Manager or SRM. And one other use case I want to mention here is Kubernetes. And let's chat for a moment about Kubernetes. Not every company is running strictly full-blown VMs with their little guest operating systems on the hypervisors. An example would be a development team that's deploying and using applications as containers orchestrated by Kubernetes. And here's one of the challenges that Kubernetes fixes. In the past, if the dev team wanted to go ahead and have a

6:25development environment, they could go ahead and use typical VMs with the guest OSs and spin one up for every time they wanted to work with that. Or they could use a bare metal solution, run Kubernetes directly on bare metal. But that's a whole nother management platform that we have to work with. And with vSphere, with VVF9, it eliminates that separation because we can have our typical VMs with their guest OSs and so forth. And at the same time, we can run Kubernetes workloads simultaneously and natively on those same hardware, which is a cool benefit because now we don't have to have a separate dev environment with separate physical hardware to support the Kubernetes and the containers. We can do it all on top of our ESXi infrastructure.

7:10And to implement the Kubernetes behind the scenes, there is a feature called the vSphere supervisor, which makes managing and working with the Kubernetes easier. So as far as the implementation and use of these features, let me point out and do a little bit of review regarding the core components. So we have ESXi, which is the hypervisor. And I'm going to refer to our ESXi devices as ESXi hosts. Think of them as hosting virtual machines or hosting a Kubernetes environment. We also have a way to centrally manage all of our hosts with something called vCenter. So vCenter runs as a separate VM. And so that VM could be one of the VMs running on our ESXi hosts, or we could have a dedicated set of ESXi hosts for management where we're running the vCenter. At the end of the day, it's another virtual machine that's allowing us to do centralized management of our vSphere environment. So a long time ago, they named it the vCenter server appliance, vCSA. And even though now it's just vCenter, I still like this term because it reminds me it's just an appliance, a virtual machine that's being used for the centralized management of our vSphere environment. We also have in vSphere an opportunity to use a virtualized storage area network, which they refer to as vSAN. This is a VMware solution where we can pool the

8:27resources off of multiple ESXi hosts to create a storage area network that's accessible by all those ESXi hosts in the cluster. And for vSAN, they used to have the original flavor, which I will call the OSA. That stands for the Original Storage Architecture. And currently, they also have now an ESA, which stands for Express Storage Architecture. So we'll have a separate set of videos, a separate skill on vSAN, and we'll walk through deployment and understanding and using vSAN as well. And if we're using Kubernetes, an additional component that I mentioned here is the vSphere Supervisor that supports the Kubernetes layer. And what the vSphere Supervisor does, it transforms a typical vSphere cluster running ESXi and vCenter into a platform that can run both traditional VMs as well as Kubernetes workloads natively under the same management plane.

9:23So if someone came up to us and said, how was the magic behind using a vSphere cluster, a group of ESXi hosts, and supporting traditional VMs as well as Kubernetes, we'd say the secret sauce is using vCenter in combination with the vSphere Supervisor that makes that possible. With the vSphere Supervisor supporting the Kubernetes portion of that, all running on top of our ESXi hosts. And in the next video, I'd like to chat with you a little bit about the total cost of ownership and also the value proposition for using a virtualized VMware environment.

9:57So I'll see you in the next video for exactly that.

0:00In this video, I'd like to chat with you about value proposition and total cost of ownership just to make sure that we're both on the same sheet of music regarding both of those. So from a value proposition, if a customer has 10 or 15 or 20 physical servers, and they can consolidate that down to a couple bigger servers, again, that's going to be a savings. And that's just from the virtualization alone. So host A and host B with network access, and they're running their workloads and their Kubernetes clusters on top of those hosts.

0:30Another value proposition is less downtime. And by that, I mean, we have features such as the HA, high availability, where if this VM is running on this host and this host fails, the vSphere infrastructure can restart that VM over here on another host, and that system can be up and running in very little time. And if we have three servers, for example, we have an app server and a database server, and then we have a web front end server or something similar, we can also orchestrate which order they come up in. So we can say for a high availability and a failure event like this host failing, we can say we want to bring up the database server first, and then the app second, and then the web interface third with a certain amount of time.

1:12So we can orchestrate those to come up on a running host in that cluster in the order that we need them to come up. So the feature there would be HA. If we have a critical system, we could also use fault tolerance, where it's running that same virtual machine on two different hosts at the same time, once the primary one being used, and the other is there as a backup in case that first one fails. We also mentioned disaster recovery, which is absolutely a value proposition. So if we have a critical business, and there's millions of dollars every hour on the line, if we have one site that goes down, getting another site up and running as quickly as possible is going to be super important, and that can be facilitated by disaster recovery. Next, let's take a look at the total cost of ownership. Because for the people who are making the decision to do virtualization or which vendor or products or services to use, whether it's on-prem with a solution like the VVF or using a cloud services provider like Microsoft or Amazon or Google, the people who make those decisions are also going to consider the total cost of ownership. And that's not just the purchase price for a piece of hardware or software, it's also the full lifecycle cost of running the IT infrastructure. So things like hardware acquisition, software licensing, power consumption, cooling,

2:29the space it's going to take in the data center, the rack units, the cabling, everything, including staff time for managing and maintenance, and the cost of downtime as well. And that's also one of the considerations why companies may not want to implement on-prem virtualized environments because they have to have that hardware. So if we went to a service like Amazon or Microsoft or Google, you can pay as you go. There's no initial outlay of a lot of capital because we don't have to buy the full servers, we're just paying for the services that we use with the cloud services.

3:02So when we talk about total cost of ownership, there are three kind of general categories that are often brought up. The first of those is CapEx, which is a shortcut way of writing capital expenditure. That's the upfront cost, things like server hardware, storage hardware, network hardware, physical data center build out, and so forth. Another factor would be the operational expenditure, which is written out as OpEx. And that's the ongoing cost, the power, the cooling, software maintenance, licensing, staff time, hardware refresh cycles, etc. And then the third element, which is also important to consider, is the cost of risk. So all of those need to be considered as part of the total cost of ownership. So for the cost of risk, it's not just talking about, you know, hacking and attacking, it's also things like financial detriment based on unplanned downtime, or data loss, or a failed recovery scenario that's going to result in a loss, including the likelihood of that happening. So if a company did decide they want to do an on-prem flavor of virtualization, for example, using VMware, some of the value drivers would be the consolidation of the infrastructure. For example, instead of 10 physical servers,

4:21two physical servers, or instead of 100 physical servers, five physical servers. And that's going to correlate to capital expenditures, the actual servers that we have to buy. So the fewer servers, the more savings. So we refer to it as fewer hosts, referring to the ESXi hosts. There's also going to be savings on cooling and power. And these are all a little bit subjective because we could have some, you know, super huge servers that take a lot of power and need a lot of cooling and are very expensive. But logically, if we're going from 20 or 30 physical servers down to two or three or four, we're going to have capex reductions because of the fewer hosts, and the cooling and power would relate to the operational expense. There's also going to be some simplification. For example, if we have to refresh our servers or change our servers up every three to five years, it's a lot easier to do that on four hosts or 10 hosts rather than 100 hosts. Also for scheduling downtime, if we're scheduling downtime for four or five hosts versus 40 or 50 hosts, again, we have less physical devices to work with and manage. And that's part of the simplification, which is going to reduce our operational expenditure for the people and technicians who do those updates and maintenance windows and so forth, because we have less physical hosts that we're dealing with. Another huge benefit as far as a value proposition is

5:40the amount of time that it would take to bring up a new service. So in the old days, if you had to, for example, have a new server, you'd buy the physical server, install the operating system, and get it all going. Now, if you wanted to spin up a new VM, it's done in a matter of minutes, not weeks or months, because we can go to this cluster of ESXi hosts and say, you know what, we need a new virtual machine here. It's going to be running a database application or a web application. We give it the parameters, we spin it up, and boom, it's online and ready to go. We didn't have to provision new hardware or anything else for it because we had the infrastructure all ready to go. So for speed and efficiency, that's one element regarding provisioning.

6:23Another fact that makes it really efficient is a centralized management system of vCenter. So for managing dozens or hundreds of ESXi hosts, we can go to one place, log on, and take a look at everything that's going on regarding those hosts as well as the VMs that they're currently running. So the faster it is, the more effective it is, it's going to reduce our operational expenditures. There's also a really cool feature that also is included as part of a vSphere environment, and that is the ability to do cloning and snapshots and use templates. For example, let's say we have this VM right here, it's perfect. And we want to go ahead and recreate 20 or 30 or 40 more of those, we can go ahead and create a template from that. And then like, just like a cookie cutter, hit the button and say, boom, boom, boom, boom, I want five of those, 10 of those, and it'll replicate those for us. Also, we're doing testing. For example, let's say we have this VM right here, and we're testing an update or a patch, we can test it on that VM. But before we do it, we can take a snapshot. So if it doesn't go well, or not as we wanted it to, we can revert back to that snapshot, and boom, be at that initial state once again, and then try again.

7:34There's another really cool concept referred to as content libraries. And in a content library, we can put our content, things like ISO images, or we can put templates or VMs that we use a lot and make them easily available inside of the vSphere ecosystem. And that way, we don't have to go looking for those files on a file system, they can be readily available as part of our vSphere. And another consideration regarding a value proposition is the resilience that we can have with either fault tolerance or high availability that's critical in a business that wants to stay running. Those features can reduce downtime, which is effectively lowering the cost of risk because the risk is less, we're not going to be down as much if we have those tools and techniques in place, things like HA, replication, and fault tolerance.

0:00In this video, I like to call it our validation video. I'd like to give you a challenge regarding some of the content that we've discussed in this set of videos regarding virtualization fundamentals. And here's what I'd like you to do. I'd like you to imagine that you and I have been asked as consultants to come in and talk with a company and we'll call it Acme Incorporated. So we're going into this meeting with Acme Incorporated and they are considering virtualization. And there's lots of options for virtualization. They could do it with a product from VMware. They could use products from Microsoft. They could use complete cloud services from people like Amazon and Google and Microsoft. And so what we're going to do is we're going to go in and build the case for and provide them information on why a VMware vSphere environment on-prem, if that's what they're deciding to go with on-prem, why that would be a valuable and beneficial situation. So what I'd like you to do, I'd like you to think about and list five things that would be beneficial for the customer should they choose to use a VMware solution on-prem at their location. So those five things may be how they could reduce downtime. Those five things could be, for example, how they could centrally

1:17manage and what the name of those tools are they're using to centrally manage their environment. So pretty much anything we discussed as a benefit regarding virtualization with the VMware environment, any of those would be perfectly fine. So I'm going to ask you to pause the video right now and I'd like you to make a list of at least five things. If you want to go for bonus points, go for more, that's great. But list at least five things that would be beneficial or valuable from a customer perspective as far as why they would want to go with a virtualization and specifically a vSphere implementation for their virtualization on-prem. So go ahead and pause me now.

1:56And when you're ready, click on resume and we'll continue together. And welcome back. So one of the things I would do probably before we start speaking to the customer is I would find out what their pain points are. Like what is the current problem or problems that you're facing? And then based on what their problems are, I would then talk about the value proposition from a VMware perspective. So let's say they said, for example, it's a hassle with all the servers that we currently have. So if they have 20 servers and that's one of the challenges regarding updates and patches and so forth on the servers, we can solve that or help reduce that pain by going to, for example, three hosts instead of 20 servers. And that way their space in the racks would be less, their power consumption theoretically would be less depending on the size of those three servers. And when they have to do patching and updates and so forth, they have three hosts to deal with as opposed to 20. So I would say one of the benefits would be consolidation. Great. So that's one of the features that we can implement with our virtualization.

3:04Another pain point if they had it was maybe they're scared or nervous about downtime. We just can't be down for a long period of time. So we might want to find out, okay, how long can you afford to be down for? Is it like zero seconds or zero minutes, or is it like five minutes, 10 minutes? What are you looking at? And then we could go ahead and talk about features such as high availability or fault tolerance or disaster recovery and replication between sites that are features as part of a vSphere environment that we can use. So that would be for less downtime. Another pain point could be if they had 20 servers, how are they managing those? How do you connect to and work with the software on those servers? Are you doing it like server by server by server by server, which would be painful. And if they are, another benefit would be centralized management using this bad boy right here, which is vCenter. So vCenter, if they went down to three hosts, they could manage all three hosts and all the apps as well as Kubernetes that are running on those apps from one location that is vCenter. So you and I, or they would log into vCenter and vCenter would interact with those devices to be able to manage not only the hosts, but also the applications and the VMs running on those hosts. And if they were concerned, for example, about

4:19some critical application here and another VM here and another one here, and possibly them encroaching on each other or sharing information back and forth, we can go ahead and also talk about the benefit of the hypervisor ESXi with total isolation for those VMs. So although there's common hardware and resources like CPU and disk and memory and so forth that's being dished out to these VMs, the isolation in the hypervisor keeps all that separate on a VM to VM basis.

4:49So there's no leaking of information from the hypervisor from one VM to another. So let's see how we're doing. We have consolidation. We have less downtime. We have the three options there. We have centralized management. Oh, I know another thing that's kind of implied here is that we have abstraction, which means we're virtualizing the resources that VMs need. And the benefit of abstraction is that we can do features like DRS. We haven't talked about that, but I'll mention it right now. Distributed Resource Scheduler can actually take a look at all of our ESXi hosts, for example, in this cluster and say, wow, this guy is at 90% utilization and this guy is at 80% utilization, this host, and this one's at 10. And what it can do, it can go ahead and take some of the VMs and be motion them over to another host that has more resources available that's not being taxed as much. And that's called distributed resource scheduler. If we have high availability and we have a host that fails, the system can restart that VM on another host. And that's because of the abstraction. It doesn't really matter which physical hardware we're using. The VM doesn't care because it's getting all of its resources virtualized to it. So whether it's running on this host or the VM is running here or here, it doesn't matter because of the abstraction, the separation between the VM

6:09and the actual real resources that it's using. So as far as some of the benefits of virtualization in a vSphere environment, we have the consolidation here. That's one. We have fault tolerant and high availability options, including HA, which I'll call one. Fault tolerant, I'll call one. And disaster recovery, which I'll call another one. So that's four. And then centralized management, we'll go ahead and call five. So I have had a lot of fun in this virtualization fundamental skill. And I look forward to seeing you, my friend, in our other skills as we go forward, where we'll work with the implementation and management of many of these components, including ESXi, vCenter, the vSphere Supervisor, and more. So I look forward to seeing you, my friend, in a future skill very, very soon. Until then, I hope this has been informative, and I'd like to thank you for viewing.