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

0:06into virtualization fundamentals. So in the next video, we'll take a big picture overview look,

0:11and I'll walk through step-by-step with many of the concepts and examples of using virtualization

0:16today 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

0:04regarding the VVF, including what that stands for. So VVF from Broadcom is VMware,

0:12vSphere, and the F is for Foundation. And that is one component instead of a bigger offering of

0:18services called VMware Cloud Foundation or VCF. So in this set of videos and in this course,

0:25we're going to be focusing on VVF, the VMware vSphere portion of it with some add-ins from

0:31Broadcom as part of the overall VVF solution. So in this set of videos, let me give you an

0:35overview regarding what we're going to take a look at and select as our roadmap for this skill,

0:40for this set of videos. So to begin with, let's take a look at the operating system that we're

0:45going to use to provide these homes for these VMs. And this operating system we're going to use as

0:50the home for the VMs from VMware is called ESXi. And it is an example of a hypervisor. So an

0:59example is we have a piece of hardware, for example, a server, and that server, instead of

1:03running a typical operating system, would run ESXi. And then on that host, on this ESXi host,

1:09it 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.

1:23And here's what that means. The ESXi operating system running on this host is taking all the

1:28resources like CPU and memory and storage and network access, and it presents virtualized

1:36versions of those resources to the VMs that are running. Those VMs are often referred to as guest

1:41OSs running on those little virtual machines. And ESXi is referred to as a type one hypervisor,

1:47meaning it is running directly on the bare metal hardware. We don't have an operating system like

1:53Windows or Linux or something else between ESXi and the host, and as a result, it's referred to

1:58as a type one hypervisor. So that's one of the elements we're going to take a closer look at

2:02in this set of videos. So now that we understand what ESXi is in concept, let's also take a look

2:09at how it does that. And the way it does that is with the VM kernel architecture. And the VM

2:14kernel architecture effectively is the core guts and functionality that the ESXi host is using

2:20to provide this virtualized environment for VMs. So it's not Linux, it's not Windows,

2:25it 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

2:37aspects about this VM kernel architecture and supporting VMs is that it provides isolation.

2:42So you can have two virtual machines, let's call this virtual machine A and virtual machine B

2:47running right here next to each other. But even though they're running on the same physical host,

2:51they are isolated from each other. So that means the memory and the disk usage and so forth is all

2:57isolated and protected between those two VMs. So we can have a multi-tenancy environment with

3:02multiple VMs running here, one VM won't impact or disrupt the other VM. Now, there are some things

3:08that can come into play like resource utilization and using tons of CPU, which might deprive another

3:13VM, 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

3:21is the VVF suite or stack. Think of it like a set of tools and features that we can use

3:29as part of our overall vSphere environment. Also in the past, when somebody said vSphere,

3:34I'll put that in quotes there, vSphere, that implied many different components. And so now

3:38as we take a look at VVF, we're referring to those same many components plus a few additional ones

3:43that Broadcom has integrated as part of the VMware vSphere foundation. So as a sneak peek at some of

3:50those features, we have the ESXi host software that's part of that. There's also the ability to

3:56centrally 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

4:09pooling their storage here or interacting with network attached storage or other network types

4:15available over a network, including the use of different types of file systems like NFS or

4:21VMware's VMFS and others. There's also support for Kubernetes for logging and monitoring as well as

4:29alerts. Also in this set of videos, I'd like to chat with you about some use cases along with

4:34additional features that are part of a VPF environment so you can have a familiarity with

4:39what those features are before we go in to start configuring them. We'll also take a look at VMware

4:43vSphere foundation value propositions involving total cost of ownership and why many companies

4:49are moving not only to cloud services to third party but also having on-prem cloud services as

4:56part of a VMware solution. So this will be our roadmap for this set of videos and with that in

5:01mind in the very next video, I'd like to take a deeper dive into the wonderful world of the host

5:06software 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

0:04else inside of VBF possible, and that is the ESXi host, which is a hypervisor.

0:11And a hypervisor is a fancy word for saying an operating system or a system that allows or

0:16supports the livelihood or the life of individual VMs. It's also worth taking just a moment and

0:22looking at the history before we start using hypervisors. So a long, long time ago in a

0:28galaxy far away, when I first got in the world of IT back in the 80s, when we wanted to have

0:33a server and put it on what would be then a functional internet, we'd have to either get

0:38a service provider or host our own and have a physical server. So there's server one,

0:42and 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

0:52one. And then we have, for example, another server that's running application number two.

0:56Maybe it's a database server. Maybe this is an e-commerce server here. And maybe we have another

1:01server that's just acting as a database. So there's four servers. Now, the challenge is

1:06that a lot of these servers would be utilized, for example, 10 to 15 percent of their utilization,

1:12and everything else is wasted. And so in the old days, we had a one-to-one correlation between a

1:17customer site, for example, and or their applications they were running and a physical

1:22host. And so with a hypervisor, we're breaking that model. And then with all these servers,

1:27they have to be purchased and powered and cooled and maintained, et cetera, et cetera,

1:32regardless of how busy they are. So with the hypervisor, what we're doing at the software

1:36layer is we're breaking the one-to-one relationship between, for example, physical hardware and the

1:42apps and services that use that hardware. So in this scenario, instead of having four separate

1:46physical machines, we have one larger physical machine with CPU, RAM, network access, and so

1:52forth. And then we could run those servers or services as virtual machines and or as services

1:58that 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

2:09hardware, it can divvy up and isolate the resources that are being used. And then we have less

2:14physical servers to deal with. And it creates the illusion, this is the cool part, it creates the

2:18illusion to the VMs that are running here that they have their own dedicated space, when in reality,

2:24they are sharing a bigger computer. And because of that isolation and the trickery, if you will,

2:30that's being provided for each of the VMs, and each one of those VMs, again, believes

2:34it has the dedicated resources being provided to it via the hypervisor. Now, today we have

2:39cloud services from Google, and Amazon, and Microsoft, and they'll have their own implementation

2:46of their flavor of hypervisor providing services to customers, whether it's software as a service

2:52or infrastructure as a service, they have their own hypervisor. And so from a VMware perspective,

2:57from Broadcom, that hypervisor is called ESXi. And it is a type one hypervisor. Now, what does

3:04that 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

3:16operating system like macOS or Windows or Linux or anything else, but we install software directly

3:21on the hardware, that's providing an environment for the virtual machines, that is referred to as

3:25a type one hypervisor. It runs directly on the physical hardware, there's no host operating

3:31system beneath it. It's just a direct connection between the ESXi software and the hardware that

3:36it's running on. So some examples of type one hypervisors, of course, are ESXi, which we just

3:42mentioned. There's also Hyper-V from Microsoft and others. Now, Hyper-V is kind of interesting because

3:49you have a Windows server, and then you enable Hyper-V. And so you still have the Windows server

3:54running and the Hyper-V is available. So how is that a type one? Well, behind the scenes, Hyper-V

4:00has direct access to the hardware, so it's also considered a type one hypervisor. And the

4:04hypervisors are purpose-built for performance and stability and security, including being used in

4:10production environments. And because there's no general purpose operating system like Windows or

4:15Linux beneath that, the attack surface is dramatically smaller than it would be if we

4:21had 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

4:32directly on the hardware. With a type two, it is running on top of or like an application on top

4:39of another operating system. For example, VMware has a product called VMware Workstation, and they

4:45also have a product called VMware Fusion. VMware Workstation runs on Windows, VMware Fusion runs

4:50on a Mac, and then inside of VMware Workstation or inside of VMware Fusion, it generates an

4:55environment to support virtual machines. But because it looks like this, so here's the hardware,

5:00and then we have, for example, Windows as the operating system. And then as one of our apps,

5:05we'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,

5:16we have our general operating system of Windows, and that's what makes VMware Workstation and

5:20VMware Fusion for Mac, that makes them a type two hypervisor. So generally speaking, in a production

5:26environment, we are going to want to use bare metal hypervisors that have direct access to the

5:30hardware. And for like testing or pet projects, if you will, we might want to use type two

5:36for testing a virtual machine or working with it. But in a production environment, very likely we're

5:41going to have physical hardware with a bare metal hypervisor as a type one hypervisor. And that's

5:46exactly what ESXi is. So let me clean it up a little bit. And let's talk about some of the

5:51benefits of ESXi as a type one bare metal hypervisor. One of the main benefits is that

5:58it'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

6:09interface so we can interact with it. But it is purpose built. And that's also because it's not

6:14a general purpose operating system. It's going to have less attack vectors available for compromise.

6:20And also one of the core components as part of ESXi is the VM kernel. So whenever you see the

6:25term VM kernel, just think, oh, that's like the guts or the operating system that ESXi is using.

6:32And so to manage the ESXi software, we can log in directly to the host. There's a graphical user

6:37interface there that's called the VMware host client that we're using to interact directly

6:43with 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

6:53vCenter where there's one pane of glass or one place to go so that we can configure and monitor,

6:58et cetera, all of our devices. So we tell vCenter what we want to have done and vCenter makes it

7:04happen. And we log in here, that's called the VMware vSphere client, as opposed to logging

7:09in individually to an ESXi host, which is called the host client. At the end of the day, it's a

7:14browser on your computer that we're using, but it's simply who we're interacting with. Are we

7:19interacting with the vCenter server or are we interacting with a individual host? And so those

7:25are 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.

7:36Now you might say, Keith, what do you mean real resources? Well, this host right here is going to

7:40have some CPU or many CPUs for that matter, very likely on a bigger computer. It's going to have

7:46some RAM, random access memory, we'll call that memory right there. It's going to have some

7:52storage or access to storage, and it's going to have network access. And instead of giving any

7:58of these VMs direct access to those resources, it's going to virtualize all those resources

8:04and present them as available to those VMs. So if we want one VM to have more CPU or more memory,

8:10or 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

8:22the host has 28 CPUs. And if that host has 20 CPUs for one of the VMs, let's call this VM1 there.

8:32Maybe we allocate it four CPUs. It's all going through the hypervisor who is presenting those

8:38CPUs as available. But from the client's perspective, from the VM's perspective,

8:42it sees it just as four. Perhaps on the physical host, we have 256 gigabytes of RAM. But maybe for

8:49this one VM, we've given it 64 gigs. And so that's what this VM believes. Now the actual VM, it may

8:56be running an operating system, for example, like Windows or Linux. And that's referred to as the

9:01guest 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

9:14typically are going to be running their own guest OS. That breaks down a little bit when we get to

9:18containers and Kubernetes. But starting off here, we'll just look at these four VMs. They're all

9:23going to have their own individual guest OS. So for the storage for VM1, for example, let's say we

9:29have access to network storage. Let's go ahead and put it on this network right here. And so let's

9:35say we have, let's say 20 terabytes of storage. What we could do is allocate to this machine

9:40saying, you know what, we want you to believe that you've got 60 gigs. And based on the needs for that

9:46VM, perhaps we allocate that from high-speed storage or from a vSAN, depending on what we

9:53have available and also what the needs are for that VM. So behind the scenes, the virtual machine

9:58is 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

10:12storage is. All it knows is that from a guest OS perspective, it's making requests to the disk

10:16and getting responses and calling it a day. And behind the scenes, the hypervisor is the middleman

10:22making all that possible. And then for network access, ESXi also virtualizes that. So in this

10:27topology here, this host called ESXi-Nest-A has four physical network adapters are plugged into

10:35the physical network. However, we can present to the VMs and the guest OSes there, we can present

10:41logical switches with however many network adapters we want to with various properties

10:46and qualities, again, virtualizing the network. So if we wanted this VM to think, okay, you've got

10:51two network interface cards, they're both 10 gig each, so they're both one gig each. We can present

10:55that to the client and then the client and the guest OS there would simply use those network

11:00services as if they were physically attached to that VM. Although in the background, all these

11:05services 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

11:16VM needs. So one term that is used to describe what's happening here is the term abstraction.

11:23We're separating this VM here from the actual physical resources by providing a virtualized

11:29version of them. So that means that this VM doesn't necessarily have to run on this physical host,

11:35we can move it over to this physical host or this physical host, and it wouldn't matter to that VM

11:40because all these services, as far as CPU, memory, storage, et cetera, are all being virtualized and

11:45provided to it. And one of the terms that often comes up when working with VMware is the concept

11:52and term of vMotion. So vMotion means this, vMotion says, take a virtual machine that's running,

11:59so it's accessing disk, it's using memory and everything else that's running, and with vMotion,

12:03we can do a live migration, it's actually called vMotion, from this host and put it over here

12:09on this host. So this is VM1 here on host ESXi nest A, and then after the vMotion happens,

12:17it's now running on ESXi nest C. And because of the abstraction, the virtualization,

12:22this 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

12:33different network attached storage devices, we'll call this device A and this device B,

12:37let's say they're both 20 terabytes. And currently, the client is using in the background

12:43virtualized, it's using some resources off of storage device A. With storage vMotion,

12:48we can move its disk files effectively from storage A over to storage B. So again, vMotion,

12:55moving the VM and its RAM over to a different physical host, and storage vMotion is moving

13:01the actual storage location behind the scenes of what that client is using. For example,

13:06from storage A to storage B. And you can do both of those at the same time with the tools provided

13:13in vCenter as we work with and manage our VMs. So with that in mind, in the next video, I'd like

13:17to take a little closer and more in depth look at the VM kernel as part of the ESXi offering

13:24from 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.

0:04We're going to pull back the hood on ESXi and take a closer look at the VM kernel to see actually

0:10what it is, how it's constructed, and why VM isolation is one of the most important

0:15architecture principles in the entire VVF stack. So let's start off with what exactly is

0:22the VM kernel. Effectively, it's the core operating system of ESXi. It's the hypervisor itself.

0:29So when a computer boots up that's running ESXi, for example, this host right here,

0:34what loads is the VM kernel. So there's no Windows operating system, no Linux distribution,

0:40no general purpose OS underneath it. It's just the VM kernel loading and running on that physical

0:45hardware. And it's purpose built with one job, and that is to manage all of the hardware resources

0:51on 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,

1:02here's the hardware, and it's the ESXi host and VM kernel that's in charge of allocating and

1:09allowing those resources to flow between the VM that needs and asks for the resources and the

1:14actual hardware resources themselves. And again, those resources include CPU, RAM, and network

1:21access and storage. So the VM kernel, effectively, ESXi is responsible for the hardware resource

1:28management. It's going to give the virtual machines what they need so they can run. So I'll

1:32refer to that as VM execution. They can run based on the resources that are being provided by the

1:37VM kernel by ESXi. The VM kernel also is providing management interfaces as well. So if we log on

1:44with the browser directly to a host with the host client, or we log on to vCenter with the vSphere

1:49client, those management interfaces and agents are what allows us to interact with the host client

1:55or 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

2:08monitor. So each virtual machine that's running has its own virtual machine monitor, and it runs

2:15alongside the kernel, one for every VM. So when a VM's guest OS attempts to execute a privileged

2:21instruction or access a resource, something that normally would require direct hardware access,

2:27that VM monitor intercepts it and allows it to be handled. So effectively, the ESXi host is acting

2:33as the middleman, once again, between anything the VM might need and the actual hardware and

2:38resources that the VM is trying to access. Again, behind the scenes is the VM monitor that's doing

2:43that interception. So think of VMM as an extension or part of the ESXi host as part of the VM kernel

2:50running on that ESXi host. Another element that the ESXi host and VM kernel are managing and

2:56working with is the virtual machine executable, and I'll call that VMX. There's also a VMX file

3:04that's associated with the VMs that specifies the details for a VM, but in this context,

3:09the acronym VMX is the virtual machine executable. And what that's doing is managing the non-CPU

3:16aspects 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,

3:27if one of these process crashes, it doesn't bring down the whole system, it would only cause a

3:31problem for the specific VM it was running for. And on top of all that, regarding the resources

3:36the VMs may need, including CPU, RAM, network access, and storage, the VM kernel as part of ESXi

3:44is keeping total isolation between all the VMs. So even if these VMs right here, this one,

3:51and this one, and this one, and let's say all four of them are using the same shared storage,

3:55let's call it storage A, the actual blocks of data that are being used are going to be kept

4:01separate. So this VM is going to use some blocks here, VM2 is going to use different blocks,

4:06and VM3 is going to use different blocks, there's not going to be a shared overlap. And that's

4:10important 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

4:21with different levels of trust on the same physical hardware because of the isolation being provided

4:27by ESXi. So an example, we could have one machine here that's being used in production,

4:33and another machine here that we're using in a test or a dev environment, and they can both run

4:38on the same host. And because they're completely isolated from each other, this VM in dev shouldn't

4:43impact the VM that's being used as part of production. Another cool thing about the isolation

4:48is that this VM here can't directly compromise this VM here. Now, if we had two guest OSes,

4:54and they're both, for example, on this network, and they could reach each other, it's also possible

5:00that through normal tools and mechanisms, they could attack each other. But from a hypervisor

5:04perspective, it's keeping these two absolutely isolated and separate from each other. So now

5:11that we've taken a look at ESXi and the VM kernel and some of the magic it performs, in the next

5:16video, I'd like to walk you through some use cases and some really cool features that are available

5:22in a VMware vSphere environment. So we'll do that in the next video, and I'll see you there in just

5:27a moment.

0:00In this video, I'd like to do a few things, introduce some features and functions

0:04as part of vSphere with their use cases, and also more importantly,

0:08why an organization or a business would actually use those features.

0:12So the first case for most companies that are doing virtualization is for server consolidation.

0:19And that remains one of the most compelling reasons why organizations would adopt virtualization in

0:24general, including whether it's VMware or whether they're doing virtualization

0:30with 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

0:40into, for example, one or two hosts. I'd also like to use this opportunity to just

0:46refer to the idea that when I talk about an ESXi host, I'm very likely going to call it a host.

0:52It's just a key giveaway that I'm talking about ESXi.

0:55And then as I talk about VMs and the guest operating systems, I may refer to those as

1:00VMs 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,

1:11perhaps we could use two servers, servers A and servers B.

1:14So server one, two, three, four, and five. So up here, we'd have VMs that are running.

1:20So let's say I have one, two, and three, they're running on host A,

1:23and then VMs four and five, which replace servers four and five running here on host B.

1:27So that's one of the first benefits of virtualization is the consolidation.

1:34So less hardware means less physical servers to maintain,

1:38less physical servers to upgrade when the time comes, et cetera.

1:41And in this example, we're going from five machines to two. However,

1:46we could actually, based on the hardware involved and how busy the workloads and the VMs are,

1:50we could have a lot more. So we could have literally dozens or hundreds of VMs potentially

1:55running here on host A, provided we have enough CPU, RAM, et cetera, to support the needs of those

2:02VMs. So if we consolidate our VMs, which I'll refer to as workloads here on these two hosts,

2:07what happens if we have a host failure? So in the past, if we lost this physical server,

2:12we've lost one application or one server. In this case here, if we lost host A, we're losing three

2:19logical servers, three VMs, three workloads. So how do we deal with that? Well, another

2:23cool feature, another cool use case is use the feature called HA, which is an acronym for high

2:30availability. And here's how HA works. In fact, let's use these three hosts that are in this

2:37topology. And each of them currently has four VMs. So if these three hosts were all placed in

2:42what's referred to as a cluster, think of a cluster as a fancy name for a group of hosts

2:48being used as part of VMware's vSphere. What we could do on that cluster is enable the feature

2:53called 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

3:06problem, these machines all go down, boom, boom, boom, boom. However, with HA, it realizes, oh,

3:13that host Nest A had four VMs that were running. It will automatically restart those on one of the

3:21remaining hosts over here. Maybe it'll start a couple here and start a couple more over here

3:26so that at the end of the day, and actually just a few minutes, those VMs that were all running here

3:31on host A are now running over here across host B and host C. And that's referred to as high

3:38availability. So effectively with HA, we're rebooting the machines, the VMs that were on the

3:43host 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

3:54have enough room and CPU and resources to run those additional VMs should we lose a single host.

4:00Another feature is the feature of fault tolerance. And that is different than HA. And let me tell you

4:06why it's different. With fault tolerance, we're actually running a replica, a second version of

4:13the same VM on two different hosts at the same time. So if this is a critical machine and we're

4:18running fault tolerance on it, that means we have one here and we're mirroring to another host, that

4:24same machine over here on host B. And that way, if this host fails, that fault tolerant machine,

4:31that VM, which is already running is now active on nest B. So fault tolerance is like a simultaneous

4:40running of a critical VM. Where with high availability, we're not doing the replication

4:45of the VM 24-7, but we're just planning on if a host fails, we'll start up the VMs on the other

4:52systems that are still running. Another really important feature that's really cool also is

4:57disaster recovery, or DR for short. And with DR, with disaster recovery, we're taking a look at an

5:04entire 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

5:15issue. So with disaster recovery, we are replicating from that site on the West Coast over to a

5:22secondary site continuously or on a scheduled basis so that if we lose a whole site, we have

5:28all that data replicated in another site that we can then activate and go ahead and use. And in a

5:34VVF environment, that disaster recovery can be scripted, we can test it, we can partially automate

5:40it just to verify that if we need it, if we have a problem with one of our sites, we can go ahead

5:44and bring everything up at the other site where it's been replicated to. And the functionality

5:49or that feature that exists as part of VVF that does that is referred to as the VMware Site Recovery

5:55Manager or SRM. And one other use case I want to mention here is Kubernetes. And let's chat for a

6:02moment about Kubernetes. Not every company is running strictly full-blown VMs with their little

6:09guest operating systems on the hypervisors. An example would be a development team that's

6:14deploying and using applications as containers orchestrated by Kubernetes. And here's one of the

6:20challenges 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

6:30spin one up for every time they wanted to work with that. Or they could use a bare metal solution,

6:35run Kubernetes directly on bare metal. But that's a whole nother management platform that we have to

6:40work with. And with vSphere, with VVF9, it eliminates that separation because we can have

6:46our typical VMs with their guest OSs and so forth. And at the same time, we can run Kubernetes

6:53workloads simultaneously and natively on those same hardware, which is a cool benefit because

7:00now we don't have to have a separate dev environment with separate physical hardware

7:04to 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

7:14supervisor, which makes managing and working with the Kubernetes easier. So as far as the

7:20implementation and use of these features, let me point out and do a little bit of review

7:25regarding the core components. So we have ESXi, which is the hypervisor. And I'm going to refer

7:30to our ESXi devices as ESXi hosts. Think of them as hosting virtual machines or hosting

7:36a Kubernetes environment. We also have a way to centrally manage all of our hosts with something

7:42called vCenter. So vCenter runs as a separate VM. And so that VM could be one of the VMs running

7:50on our ESXi hosts, or we could have a dedicated set of ESXi hosts for management where we're

7:54running the vCenter. At the end of the day, it's another virtual machine that's allowing us to do

7:59centralized management of our vSphere environment. So a long time ago, they named it the vCenter

8:04server appliance, vCSA. And even though now it's just vCenter, I still like this term because it

8:10reminds me it's just an appliance, a virtual machine that's being used for the centralized

8:14management of our vSphere environment. We also have in vSphere an opportunity to use a virtualized

8:21storage 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

8:34those ESXi hosts in the cluster. And for vSAN, they used to have the original flavor, which I

8:40will call the OSA. That stands for the Original Storage Architecture. And currently, they also

8:46have now an ESA, which stands for Express Storage Architecture. So we'll have a separate set of

8:53videos, a separate skill on vSAN, and we'll walk through deployment and understanding and using

8:59vSAN as well. And if we're using Kubernetes, an additional component that I mentioned here

9:04is the vSphere Supervisor that supports the Kubernetes layer. And what the vSphere Supervisor

9:10does, it transforms a typical vSphere cluster running ESXi and vCenter into a platform that

9:16can 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

9:28ESXi hosts, and supporting traditional VMs as well as Kubernetes, we'd say the secret sauce is

9:34using vCenter in combination with the vSphere Supervisor that makes that possible. With the

9:40vSphere Supervisor supporting the Kubernetes portion of that, all running on top of our ESXi hosts.

9:46And in the next video, I'd like to chat with you a little bit about the total cost of ownership and

9:52also 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

0:05just to make sure that we're both on the same sheet of music regarding both of those.

0:09So from a value proposition, if a customer has 10 or 15 or 20 physical servers,

0:15and they can consolidate that down to a couple bigger servers, again, that's going to be a

0:19savings. And that's just from the virtualization alone. So host A and host B with network access,

0:25and 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

0:36HA, high availability, where if this VM is running on this host and this host fails,

0:42the vSphere infrastructure can restart that VM over here on another host, and that system can be

0:48up and running in very little time. And if we have three servers, for example, we have an app server

0:54and a database server, and then we have a web front end server or something similar,

0:58we can also orchestrate which order they come up in. So we can say for a high availability

1:03and a failure event like this host failing, we can say we want to bring up the database server first,

1:08and 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

1:18them to come up. So the feature there would be HA. If we have a critical system, we could also

1:23use fault tolerance, where it's running that same virtual machine on two different hosts at the same

1:28time, once the primary one being used, and the other is there as a backup in case that first

1:34one fails. We also mentioned disaster recovery, which is absolutely a value proposition. So if

1:39we have a critical business, and there's millions of dollars every hour on the line, if we have one

1:44site that goes down, getting another site up and running as quickly as possible is going to be

1:48super important, and that can be facilitated by disaster recovery. Next, let's take a look at the

1:54total cost of ownership. Because for the people who are making the decision to do virtualization

1:59or which vendor or products or services to use, whether it's on-prem with a solution like the VVF

2:06or using a cloud services provider like Microsoft or Amazon or Google, the people who make those

2:12decisions are also going to consider the total cost of ownership. And that's not just the purchase

2:16price for a piece of hardware or software, it's also the full lifecycle cost of running the IT

2:22infrastructure. 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

2:34staff time for managing and maintenance, and the cost of downtime as well. And that's also one of

2:40the considerations why companies may not want to implement on-prem virtualized environments because

2:46they have to have that hardware. So if we went to a service like Amazon or Microsoft or Google,

2:51you can pay as you go. There's no initial outlay of a lot of capital because we don't have to buy

2:57the 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

3:07are often brought up. The first of those is CapEx, which is a shortcut way of writing capital

3:13expenditure. That's the upfront cost, things like server hardware, storage hardware, network hardware,

3:19physical data center build out, and so forth. Another factor would be the operational expenditure,

3:25which is written out as OpEx. And that's the ongoing cost, the power, the cooling, software

3:31maintenance, licensing, staff time, hardware refresh cycles, etc. And then the third element,

3:37which is also important to consider, is the cost of risk. So all of those need to be considered

3:43as part of the total cost of ownership. So for the cost of risk, it's not just talking about,

3:48you know, hacking and attacking, it's also things like financial detriment based on unplanned

3:55downtime, or data loss, or a failed recovery scenario that's going to result in a loss,

4:02including the likelihood of that happening. So if a company did decide they want to do an on-prem

4:10flavor of virtualization, for example, using VMware, some of the value drivers would be

4:15the 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

4:26to correlate to capital expenditures, the actual servers that we have to buy. So the fewer servers,

4:32the more savings. So we refer to it as fewer hosts, referring to the ESXi hosts.

4:36There's also going to be savings on cooling and power. And these are all a little bit subjective

4:42because we could have some, you know, super huge servers that take a lot of power and need a lot

4:46of cooling and are very expensive. But logically, if we're going from 20 or 30 physical servers down

4:53to two or three or four, we're going to have capex reductions because of the fewer hosts,

4:58and the cooling and power would relate to the operational expense. There's also going to be

5:03some simplification. For example, if we have to refresh our servers or change our servers up

5:08every three to five years, it's a lot easier to do that on four hosts or 10 hosts rather than

5:13100 hosts. Also for scheduling downtime, if we're scheduling downtime for four or five hosts versus

5:1940 or 50 hosts, again, we have less physical devices to work with and manage. And that's part

5:26of the simplification, which is going to reduce our operational expenditure for the people and

5:31technicians who do those updates and maintenance windows and so forth, because we have less

5:36physical 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,

5:46for example, have a new server, you'd buy the physical server, install the operating system,

5:51and get it all going. Now, if you wanted to spin up a new VM, it's done in a matter of minutes,

5:57not weeks or months, because we can go to this cluster of ESXi hosts and say, you know what,

6:02we need a new virtual machine here. It's going to be running a database application or a web

6:06application. We give it the parameters, we spin it up, and boom, it's online and ready to go. We

6:12didn't have to provision new hardware or anything else for it because we had the infrastructure

6:16all 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.

6:28So for managing dozens or hundreds of ESXi hosts, we can go to one place, log on, and take a look

6:34at everything that's going on regarding those hosts as well as the VMs that they're currently

6:38running. So the faster it is, the more effective it is, it's going to reduce our operational

6:43expenditures. There's also a really cool feature that also is included as part of a vSphere

6:49environment, and that is the ability to do cloning and snapshots and use templates. For example,

6:56let's say we have this VM right here, it's perfect. And we want to go ahead and recreate 20 or 30 or

7:0340 more of those, we can go ahead and create a template from that. And then like, just like a

7:08cookie cutter, hit the button and say, boom, boom, boom, boom, I want five of those, 10 of those,

7:13and it'll replicate those for us. Also, we're doing testing. For example, let's say we have

7:17this VM right here, and we're testing an update or a patch, we can test it on that VM. But before

7:23we do it, we can take a snapshot. So if it doesn't go well, or not as we wanted it to, we can revert

7:28back 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,

7:39we can put our content, things like ISO images, or we can put templates or VMs that we use a lot

7:46and make them easily available inside of the vSphere ecosystem. And that way, we don't have to

7:50go looking for those files on a file system, they can be readily available as part of our vSphere.

7:57And another consideration regarding a value proposition is the resilience that we can have

8:02with either fault tolerance or high availability that's critical in a business that wants to stay

8:08running. Those features can reduce downtime, which is effectively lowering the cost of risk because

8:14the risk is less, we're not going to be down as much if we have those tools and techniques in

8:18place, 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

0:05regarding some of the content that we've discussed in this set of videos regarding

0:10virtualization fundamentals. And here's what I'd like you to do. I'd like you to imagine

0:14that you and I have been asked as consultants to come in and talk with a company and we'll

0:19call it Acme Incorporated. So we're going into this meeting with Acme Incorporated

0:25and they are considering virtualization. And there's lots of options for virtualization.

0:28They could do it with a product from VMware. They could use products from Microsoft. They

0:34could use complete cloud services from people like Amazon and Google and Microsoft. And so

0:40what we're going to do is we're going to go in and build the case for and provide them information

0:46on why a VMware vSphere environment on-prem, if that's what they're deciding to go with on-prem,

0:53why that would be a valuable and beneficial situation. So what I'd like you to do, I'd like

0:58you to think about and list five things that would be beneficial for the customer should they choose

1:07to use a VMware solution on-prem at their location. So those five things may be how

1:13they 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.

1:22So pretty much anything we discussed as a benefit regarding virtualization with the VMware

1:27environment, any of those would be perfectly fine. So I'm going to ask you to pause the video right

1:33now and I'd like you to make a list of at least five things. If you want to go for bonus points,

1:38go for more, that's great. But list at least five things that would be beneficial or valuable from

1:44a customer perspective as far as why they would want to go with a virtualization and specifically

1:50a 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.

2:03And welcome back. So one of the things I would do probably before we start speaking to the customer

2:09is I would find out what their pain points are. Like what is the current problem or problems that

2:15you're facing? And then based on what their problems are, I would then talk about the value

2:21proposition from a VMware perspective. So let's say they said, for example, it's a hassle with

2:28all the servers that we currently have. So if they have 20 servers and that's one of the challenges

2:34regarding updates and patches and so forth on the servers, we can solve that or help reduce that pain

2:40by going to, for example, three hosts instead of 20 servers. And that way their space in the

2:46racks would be less, their power consumption theoretically would be less depending on the

2:51size of those three servers. And when they have to do patching and updates and so forth,

2:55they have three hosts to deal with as opposed to 20. So I would say one of the benefits would be

3:00consolidation. 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.

3:09We just can't be down for a long period of time. So we might want to find out, okay,

3:13how long can you afford to be down for? Is it like zero seconds or zero minutes, or is it like five

3:18minutes, 10 minutes? What are you looking at? And then we could go ahead and talk about features

3:22such as high availability or fault tolerance or disaster recovery and replication between sites

3:29that are features as part of a vSphere environment that we can use. So that would be for less

3:34downtime. Another pain point could be if they had 20 servers, how are they managing those? How do

3:40you connect to and work with the software on those servers? Are you doing it like server by server by

3:45server by server, which would be painful. And if they are, another benefit would be centralized

3:51management using this bad boy right here, which is vCenter. So vCenter, if they went down to three

3:56hosts, they could manage all three hosts and all the apps as well as Kubernetes that are running

4:03on those apps from one location that is vCenter. So you and I, or they would log into vCenter and

4:09vCenter would interact with those devices to be able to manage not only the hosts, but also the

4:13applications 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

4:26encroaching on each other or sharing information back and forth, we can go ahead and also talk

4:31about the benefit of the hypervisor ESXi with total isolation for those VMs. So although there's

4:38common hardware and resources like CPU and disk and memory and so forth that's being dished

4:43out 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

4:55how we're doing. We have consolidation. We have less downtime. We have the three options there.

5:00We have centralized management. Oh, I know another thing that's kind of implied here

5:05is that we have abstraction, which means we're virtualizing the resources that VMs need. And the

5:11benefit of abstraction is that we can do features like DRS. We haven't talked about that, but I'll

5:16mention it right now. Distributed Resource Scheduler can actually take a look at all of

5:21our ESXi hosts, for example, in this cluster and say, wow, this guy is at 90% utilization

5:27and this guy is at 80% utilization, this host, and this one's at 10. And what it can do,

5:32it can go ahead and take some of the VMs and be motion them over to another host that has

5:38more resources available that's not being taxed as much. And that's called distributed resource

5:43scheduler. If we have high availability and we have a host that fails, the system can restart

5:49that VM on another host. And that's because of the abstraction. It doesn't really matter

5:54which physical hardware we're using. The VM doesn't care because it's getting all of its

5:59resources virtualized to it. So whether it's running on this host or the VM is running here

6:04or 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

6:15in a vSphere environment, we have the consolidation here. That's one. We have fault

6:21tolerant and high availability options, including HA, which I'll call one. Fault tolerant, I'll call

6:26one. And disaster recovery, which I'll call another one. So that's four. And then centralized

6:31management, we'll go ahead and call five. So I have had a lot of fun in this virtualization

6:36fundamental skill. And I look forward to seeing you, my friend, in our other skills as we go forward,

6:41where we'll work with the implementation and management of many of these components,

6:45including ESXi, vCenter, the vSphere Supervisor, and more. So I look forward

6:51to seeing you, my friend, in a future skill very, very soon. Until then,

6:55I hope this has been informative, and I'd like to thank you for viewing.