Pass VMware 1V0-701 Exam in First Attempt Easily

Getting Started

1. Welcome

Now, I know you might be tempted to skip over this introduction, but just stick with me for a moment while I mention a couple important resources that can really help you succeed. And I promise this whole thing will take less than three minutes. My name is Rick Crescie, and I've been a VMware Certified Instructor since 2013. I've taught VSphere to hundreds of students directly for VMware, and I'm also the primary author for trainerdests.com. And as a long-time instructor, I can tell you that hands-on experience is critical to the learning process. Now, VMware has some great hands-on lab exercises that you can do anytime, on demand. And I've also put out another course that teaches you how to build your own home lab. If you're interested in that or any of my courses, please feel free to reach out to me and I'll give you a discount. Promo code. This is the first course in a series of VSphere courses that I'm working on. The next course I plan to deliver is VSphere six and six. Five foundations. But the material in this course will align directly with the VMware Certified Associate Exam. Now, I also want to encourage you to ask me questions. I want you to have the best possible experience that you can get from this class. And if you have a question,don't hesitate to reach out. I'm happy to be along with you on this journey. And I also want to invite you to connect with me on LinkedIn or contact me through you to me.I try to answer all questions as quickly as I can, but the best way to get in touch with me and stay in touch is via LinkedIn. I check that very frequently, and if there's anything I can do to improve this course, please let me know. I strive to get perfect review scores. So if there is something I can do to improve your experience,

2. Introduction To Virtualization

In this video, I'll provide you with an introduction to virtualization, where we'll learn many of the basic concepts of what a virtual machine is, what a hypervisor is, and how we can provide resources to our virtual machines that are actually the shared physical resources of an ESXi host. So what is a virtual machine? Well, it's very similar to a physical server. You have an operating system, and the operating system has no idea that it's going to be running on a virtual machine. So if I have Windows or Linux running on my VM, that operating system is called the guest operating system, and it has no awareness that it's running as a VM. Now, a virtual machine does not have its own dedicated hardware, but like I said, the guest operating system doesn't know that. So a virtual machine will run on a physical server. With many other virtual machines, they'll share the physical resources of the host. And this is the first big benefit of virtualization. We can run many machines on shared hardware, each with their own independent guest operating system. And those virtual machines can share a common set of physical resources like CPU, memory, network, and storage. So, unlike a physical server, the virtual machine does not truly have its own dedicated physical hardware. It's using the shared hardware of an ESXi host. And that's what the ESXi host is. This is the actual physical server that our virtual machines will run on. So the virtual machine is almost like a programme running on a computer. We have different programmes that consume different amounts of resources, and we have different VMs running on the same physical host. And some VMs may consume more CPUs, while others may consume less. Some might consume more memory or produce more storage traffic. Other virtual machines less So the ESXi host is like our physical server, and ESXi is the operating system that we install on that physical server. And ESXi is what we refer to as a type one hypervisor. That means it runs right on the hardware. It doesn't require any other operating system. So if you're familiar with VMware Workstation, that's a hypervisor that runs on top of Windows. There's no underlying operating system on the ESXi host. It's purely ESXi running on physical hardware. And then the virtual machines run on top of ESXi and can utilise the physical resources of that host. So again, here we see many virtual machines running on the same ESXi host, again utilising the shared physical resources provided by that host. Now, our ESXi host is an example of a type one hypervisor. And a hypervisor adds what we call a layer of abstraction. So there's a layer of abstraction between the virtual machines and the physical resources. Now, what does this layer of abstraction mean? Well, let's take a moment to think about this. So, let's say, for example, that I'm sitting on the couch and I have myself a bowl of M & M, and I see my son coming towards the living room, so I take a napkin and I cover up that bowl of M & M. I've just created myself a layer of abstraction. My son, I've hidden those underlying physical resources from the people who want to consume those resources, my son.And that's kind of like what a layer of abstraction does on the ESXi host. It creates this layer between the virtual machines and the physical hardware, and it gives us this management capability where we can intelligently divide up those resources. So, for example, as a virtual machine is trying to access physical memory, it's going to access that memory through this hypervisor layer of abstraction. And now we can intelligently decide, well, the first VM might be able to access four gigabytes of memory, and the second VM might be able to access two gigabytes of memory. And maybe the third VM will take precedence over the other two VMs. And we can establish all of these controls because of this hypervisor layer that rides in between the virtual machine and the physical resources. So my VMs are not actually seeing the physical resources at all. They're seeing a virtualized version of those physical resources that we can control because of this layer of abstraction that exists. And one of the most important resources that are shared across virtual machines are my CPUs. So in this slide, we see an ESXi host. And this ESXi host has four physical CPUs. Let's assume that those are four processor cores on the same socket. So we've got a situation in which we've got a four-processor course and we've got a lot of virtual machines. Here you can see that we've got twelve virtual machines displayed. So we've got these twelve virtual machines that are sharing a physical processor, of course. This is called over subscription.We only need to rephrase. We may only need four processor cores to meet the requirements of twelve virtual machines because, odds are, all of my VMs are not going to be consuming as much CPU as they possibly can at all times. That's what the concept of over-subscription is all about. And that's how we efficiently utilise the resources of our EFXI host. Think about it this way. Let's say that we have a restaurant, and we know that we're going to have a certain number of people that visit our restaurant every day. So maybe, for example, we'll know that we'll have 200 people who are going to come to our restaurant every day. Well, I may just simply build enough tables in this restaurant to see 50 people at any given moment. So I'll build my restaurant for my normal usage. I might have 200 people per day, but odds are I'm not going to have all of those people at the exact same moment. Some will come for lunch, some willcome for breakfast, some for dinner. And so it would really be wasteful of me to size my restaurant big enough to seat 200 people because I'm probably not going to have that many people at once. The same concept applies to virtualization. I'm not going to size up my physical CPU resources for my worst-case scenario. Now, there may be times where all twelve of these virtual machines have a CPU-intensive running task, and that's just like 200 people showing up to my restaurant at once. If all twelve of these VMs are carrying out some sort of CPU-intensive task, they're going to be waiting; there's going to be slowness. just like the restaurant example of 200 people showing up at once. There are too many people and not enough physical resources; not enough tables are available. So it's always a balancing act when you're creating your ESXi hosts because you don't want to purchase a bunch of unnecessary physical hardware. But on the other hand, you don't want a bad performance. So we always have to find that sort of fine line. So as we go ahead and create our virtual machines, we can size them individually. So we could say maybe one VM will get four virtual CPUs, one VM will get two virtual CPUs, and one VM will get one virtual CPU. And all that does is govern how many processor cores each VM is allowed to take advantage of. So our hypervisor layer or our layer of abstraction gives us the ability to have a shared set of physical CPUs that are used by a group of virtual machines, and memory virtualization is a very similar concept. I'll probably have virtual machines running on any SXI hosts that exceed the amount of memory that the host can actually deliver. So maybe if I add up all of my VMs over here, the total memory that I'll allocate to them will be 48GB. But maybe my host will actually have 24GB. I'll oversubscribe, just like we talked about with CPU. And as these virtual machines need to utilise memory, as they actually require those memory pages, those memory pages will be mapped back to physical memory on the ESXi host that's shared by all of my virtual machines. So I kind of call it the "four food groups," right? The ESXi host provides a CPU, provides memory, and also provides network virtualization and storage virtualization. And the network virtualization part of our picture looks a little bit different than the other resources that we've already looked at. So from a network virtualization perspective, we now have this component here called a Visa standard switch. This is a virtual switch. And like I said, my VMs work pretty similarly to the way that a physical server works. So when I create a virtual machine, I need to plug it into a network just as if I was putting a physical computer on the network. I have to do the same thing with the VM, right? I have to plug it into a network. And we'll go over that in more detail later in this course. But essentially what I'm going to do is establish a virtual connection from this VM to a port on a VSphere standard switch. And by the way, my VMs that are running on this host can all communicate via that VSphere standard switch. They can talk to each other; they can communicate without their traffic ever even leaving the ESXi host. But if there's something out there that they need to communicate with, like a physical server, they can do that through a Visa standard switch, and they'll have a connection to a physical network and be able to talk to devices that are outside of that ESXi host. So that's the purpose of the Vsphere standard switch and of network virtualization: to provide network connectivity to our virtual machines, and storage virtualization is very similar. My virtual machine is going to have virtual disks. Remember, I've got a guest operating system running in each of these virtual machines, like Windows or Linux. Both of those guest operating systems need to be able to access their C drive and the files that make up that VM. And so as the Virtual Machine generates storageactivity, that storage activity in the form ofscuzzy commands is captured by the hypervisor andredirected to the appropriate storage location. That's the other purpose of the hypervisor, to provide access to a variety of different methods of storage. We'll talk about those later on in this course, like virtual CN VMFS and NFS virtual volumes. But at this point, what we really want to understand in this first lesson is simply the fact that I have multiple virtual machines running on a physical ESXi host. And the physical ESXi host provides access to our four food groups: CPU, memory, network, and storage. Now, one more thing about our virtual machines that's important to understand at this point: A virtual machine is made up of two major pieces. We have the Virtual Machine files and the live state of the Virtual Machine. So let's start with the live state. Every virtual machine that's running is going to have contents in memory. This is a list of all the programmes that are running in the current state of the virtual machine. The virtual machine is going to be using time slots on processors. It's going to have a virtual nick that's connected to a port on a virtual switch, and it's going to send scuzzy commands that are intercepted by the ESXi host and passed along to a storage adapter. So this is what's happening in my virtual machine right now, at this given moment. The virtual hardware that we're providing and the contents of memory at any given moment are what's running on the ESXi host. But the Virtual Machine is also made up of a set of files. Some of these files include our VMDKfile, the virtual disc of our virtual machine, the VMX file, and our configuration file. And those files are located on a data store. And a data store is simply any storage technology that has been prepared to house virtual machine files. When I shut down my VM, there are no more contents in memory. The virtual machine is not being scheduled on a processor. It's not generating any network or storage traffic. When I shut down my VM, it's still registered to a host. We still know which host it's going to run on next time we power it up. But basically, when a VM is powered on, all that really remains is the set of files that we're going to use to boot that virtual machine up next time. So our virtual machines are made up of the live state. That's the part that's running on the ESXi host. That's the contents of memory—the virtual hardware. And they're also made up of a set of files located on a data store. So that's what our virtual machines are. And this is basically the building block of the software-defined data center. So when we start taking physical servers and virtualizing them, creating many VMs, running on multiple ESXi hosts, and doing things like having virtualized networks, having storage arrays that our virtual machines utilise for storage, and things like that, we've gone to a software-defined data center. And if I want to, I can create multiple virtual data centres in the same building. I can create a virtual datacenter that spans multiple physical locations. I have all kinds of options. And that's the biggest difference between a physical datacenter and a software-defined data center: the fact that a software-defined data centre is not defined by four walls, an air conditioning unit, and power. Right? like a physical data centre is. A software-defined data centre can span physical locations. We can make it bigger. We can make it smaller. It's scalable and dynamic. Finally, one last term I want to talk about What is the cloud? Well, we're going to keep this very simple. So a private cloud is essentially a virtualized environment. I've got a bunch of ESXi hosts. I've got virtual machines running on it, and that's my own little private cloud, my own equipment, and there's no kind of third-party hosting service or anything like that. Now, if I decide to, I can also utilise the public cloud. And I like to think of the public cloud as like a utility company, right? So if you're building a new house, you can just call the power company and get your power turned on. You don't have to put generators in your basement or solar panels all over the roof. You can just call the power company and get power. That's kind of like the public cloud. You can simply utilise their existing physical infrastructure. They have the servers; they have the storage capacity; they have the network capacity to run virtual machines. And that's what a public cloud provider is. It's sort of a utility provider for compute and storage capacity. AWS is definitely the most well-known example, and I also teach AWS classes as well. I teach a lot of live AWS classes, and AWS and VMware are definitely getting more closely integrated as time goes on. So if you're ever curious about any of that stuff or you ever want to take a live class, feel free to reach out to me on LinkedIn and I'll be glad to help you out. But yeah, that's what the cloud is, right? So when you think public cloud, think AWS, think Google, or think whoever a public cloud provider is, that's their physical hardware, their compute, and their storage. And then you can also do something called a hybrid cloud, where you have some stuff running in a private cloud and some stuff running in the public cloud. Alright, so let's review. A virtual machine has a guest operating system. It has virtual hardware. It doesn't actually have any physical hardware that's truly dedicated to it. And many virtual machines can run on a single hypervisor. ESXi is a type one hypervisor, and that's our physical server. And the resources of that ESXi host are shared across multiple virtual machines, and they're presented to virtual machines using what we call a layer of abstraction. We can have multiple virtual datacenters in the same building. We can have virtual data centres that span multiple physical locations. And we also briefly introduced what a cloud service provider is, with the most common example being

3. Demo: Assign vSphere Licenses

In this video, I'll demonstrate how to assign licence keys to a Vsphere Six environment using the Vs for Web client. So here you can see I've already logged into the V SFA Web Client, and I'm going to go ahead and click on Host, Hosts, and Clusters. And one of the first things you'll notice when we get into the Hosts and Clusters view is that my host is currently disconnected. I have an ESXi host, but it's disconnected at the moment. And if we click on the summary for this host, we can see the reason this host is disconnected from V Center is the fact that the host licence is expired. So when your host licences expire, if you're using an evaluation license, for example, you will no longer be able to use VCenter to manage those ESXi hosts. So what I'm going to do is actually go to my administration screen, and under Administration, I can go ahead and apply some licence keys. so under administration. I will click on licenses. And as you can see here for my Visa server, I've got a licence that is currently expired. As you can see from my hosts, I've got a licence that is currently expired. And so what I'm going to actually do is start with V Center. I'm going to right-click my V Centerserver, and I'm going to assign a license. And here's my current licence key that has expired. I'm going to go ahead and hit the Plus button and add a new licence key. Okay, so I'm going to paste in my VCenter licence key, and you'll see this blurred out because I don't want to share my licence with everybody, and I'm going to simply call it VCenter. Six is the name of my licence key, and I'll hit Finish. And now I'll apply this new licensekey to my V Center server. So I'll choose the new V Center licence key, go ahead, and hit okay there. And now I can see that V Center Six is successfully licenced and that the licence expires in about a month or so. And then I'm going to go to my host, where I'm going to perform a similar process. I'll go to my host, and I'll click on assign license. I'm going to click on the Plus button to assign a new licence key, and I'll go ahead and paste my licence key in, hit Next, and call it Vsphere Enterprise Plus. That's my Enterprise Plus licence and key. and I'll just call it license. Finish with one hit. And now I've got an appropriate licence key that I can actually assign to this ESXi host that has not expired. I can also go to my licenses, find the ones that have currently expired, select those, and take action to get rid of them just to keep my licence inventory nice and clean. And now if I go back to hosts and clusters, my host is still disconnected. I can right-click it and, under Connection, go to Connect. And it should allow me to reconnect to this host. And there we go. Now my ESXi host has been reconnected. I can see my virtual machine. And now I can start to manage this host because I have a valid licence key.

4. Virtualization Benefits

In this video, we'll examine some of the benefits of virtualization and also talk about some of the challenges that we have with traditional physical data centers. So with a traditional physical data center, we tend to need a lot of power, a lot of cooling to keep our data centre at the proper temperature, and a lot of physical rack space. and we also have the cost of many physical servers. So with a traditional physical data center, what you have is one physical server for each operating system instance. So if I want a Sequel server, an Exchange server, and all these different servers, I'm going to have one physical server for each of those kinds of major applications. And this can lead to some operational challenges as well because we might have to manage many different hardware platforms. Hopefully most of our servers are similar, but possibly they are not. As a result, multiple management tools may be required, adding to the complexity. So one of the first benefits of data centre virtualization is that it reduces capital and operational expenses. And the first thing I'll say is that it may take some time to realise this kind of capital cost savings. But the thought process is that in a traditional physical datacenter, every time you need a new server, you're going to have to install a new physical server. As you kind of scale out and add more applications, you're adding more physical servers, and that can get really expensive. Whereas with virtualization, we buy a few ESXi hosts and then, as we start to add more virtual machines, we can add those virtual machines within the existing ESXi host, reducing capital expenditures. Also, the operational expenses can decrease because we're managing a smaller footprint of physical servers than we would with a traditional physical data center. We also have application isolation and a reduced attack surface. So what does that mean? Well, let's kind of think about it this way. Some of you have probably had a server like this, right? I call it a catch-all server. So maybe I've got this physical server with Windows installed, and I've got a few random applications, right? So I start installing multiple applications, and none of these applications are big enough to justify their own dedicated physical server. So I'll go ahead and install them all on the same physical server that they share. And this is a traditional physical server. The side effect of this approach is that I am increasing the attack surface. So for example, let's say I've got this one application, and I'll kind of highlight it as purple. The one in purple here has a vulnerability, and it's installed on the same server as all of these other applications. and some hackers manage to take advantage of that vulnerability. And now look at all the other stuff that the hacker has access to, right? So we may want to isolate these applications. Another reason may be, what if one of these applications really starts using a whole lot of resources? All the other applications are going to suffer when we virtualize. It becomes much more practical to have a dedicated instance for each application, right? So if I've got an ESXi host and I want to start running multiple applications, well, I can roll out a different virtual machine for each and every application because all of those virtual machines exist on the same physical server. So now I don't have to intermingle many virtual machines on the same operating system. and this can allow me to do a number of things. Number one: it reduces the attack surface for each virtual machine. But, more importantly, it enables me to specify more stringent Firewall rules for each of these virtual machines, allowing me to maintain a better security posture. I can rapidly deploy virtual machines, right? Think about what it takes to deploy a physical server. We have to order the equipment. We have to get the budget approved to order the equipment in the first place. We have to physically rack and stack and power and cable all the networking. And then we have to install an operating system, install our applications, and do all of our testing. That can take a long time. With virtual machines, I could have an image that's called a template. I can have a template. I'll call this my template. And my template can be a precreated image of a virtual machine complete with an operating system and all of my standardised configurations. Maybe my Windows Firewall rules, or who knows what else? And if I need a new server, a new virtual machine, I will just go ahead and deploy a new virtual machine based on that template, and it can be ready in a matter of minutes. So I can have very rapid deployment in a virtualized environment. How about availability? We'll talk a little bit more about availability later on in this course. But I have all of these tools like false tolerance and high availability that we'll take a closer look at later this week that can help my virtual machines automatically come back online if there's some sort of hardware failure. Centralized Resource Management We've got this centralised management system with V SFR called VCenter, and it's kind of at the centre of everything. So here's my V Center server. It manages all of my ESXi hosts, all of my data stores, my virtual machines, my virtual switches, all of the hardware that I've assigned to my virtual machines, DRS and high availability, and so on and so forth. I have this centralised resource management tool called Vcenter that allows me to manage a variety of functions on a single platform. Another benefit, and this kind of sounds like a funny one, is increased hardware utilization. So let's think about it this way. With data centre virtualization, we can take advantage of over subscription.What I mean by that is, let's say I've got a physical print server, and that physical print server uses a small fraction of the memory that it has. It uses a small fraction of the physical CPUs that it has. Well, I've paid for those resources. I paid for that CPU and that memory, and it's sitting there unutilized, and that's wasteful. But if I have an ESXi host, a physical hypervisor, and I can just kind of pile up the VMs on it until those VMs are using those physical resources of that host at an acceptable level, I want to make sure that if I purchase those physical resources, they're actually getting used. And so that's what virtualization gives us: the ability to share those physical resources across multiple workloads. That way, they're not just sitting there idle. And then we also have policy-based resource allocation. This is another topic that we'll talk about in a couple of videos ahead here. But we'll have things like storage policies to ensure that my virtual machines are stored on the appropriate storage technology. And we can do things like shares, limits, and reservations to ensure that the most important ports and virtual machines are prioritised.

5. Management Challenges

In this video, we'll take a look at some of the management challenges that VMware VSphere can help us overcome. So first off, we have the management of varying hardware. And I've already mentioned this in the priority list: if we're running all physical servers, we may have a variety of server types, a variety of different types of disks, and all sorts of drivers and hardware that we need to manage. We also may have problems because of this with centralised control, and we also have compliance difficulties. So if we've got all these different platforms running operating systems and we basically have a challenge with standardization, this can lead to a lot of compliance challenges in order to make sure that we are enforcing a consistent and controlled profile across our data center. And then we have the scalability of management tools as well. So as our physical data centre grows, the management tools that we may have in place may not scale well with that physical data center. So how does VSphere solve this? Well, number one, we won't have that management of varying hardware anymore. So with a physical data center, what we could potentially have is all of these physical servers, and maybe one of them is an HP, another is an IBM, and another is a Dell. And over time, we're going to have all of this varying hardware. Or even if they're the same manufacturer, they might have different guts, they might have different motherboards, and they might have different graphics solutions and network interface card types. And so if I've, let's say, deployed something like SQL on this physical server, and I want to now replace that physical server, how hard is it to migrate that workload to some other physical server? Can I just back it up and restore my backup to that new physical server? Maybe. Or maybe my new physical server has a different type of network interface card type in.It's going to have different drivers. and so managing that varying hardware can be a real challenge. Now, instead of having my SQL Server on a physical machine, let's kind of think about it this way. Let's say that my SQL Server runs inside a virtual machine. Well, I've got a very limited set of hardware options, right? Maybe I've got a virtual NIC that Windows sees; that's a VMX net. Three: I've got a virtual Scuzzy controller, I've got virtual memory, I've got virtual CPUs, and it's all a very standardised set of hardware. And all of my virtual machines have the same set of hardware, regardless of the physical hypervisor that they're running on. What the guest operating system sees from machine to machine is very much the same. And now if I need to backup and restore to, let's say, a different physical ESXi host, there aren't going to be any driver issues there for me. Everything is the same. I have this consistent hardware that's actually presented to the guest operating system, and it doesn't change. We can also have centralised control. And I mentioned a little bit about VCenter in the last slide. So with VCenter, I've got a centralised server that I use to manage everything. All my hosts, all my virtual machines, all of my resource management That's all done in my centralised system called Vcenter. And from a compliance perspective, there are tools that VMware has to allow you to manage compliance effectively. One of the tools that I'll mention here is V Center Configuration Manager, which we can use to basically create a standard configuration that can be used as a reference. We can check for compliance issues and resolve those. But there are other tools as well. When we think about compliance, we can think about things like templates, right? So a template is an image of a virtual machine from which I can deploy all of my new virtual machines. So if I get all my settings in compliance on my template, then every virtual machine that I create based on that template will also be in compliance. And there are some additional tools, like host profiles and things like that, if you want to kind of take it to the next level. But in the end, compliance is one of the challenges that Vspheric can help us with.

6. Optimization Challenges

In this video, we'll take a look at some of the optimization challenges that virtualizing with VMware VSphere can potentially solve for you. So let's start out by taking a brief look at some of the challenges that can arise with a virtualized environment. And one of the problems that we might have is that it may be difficult to locate performance-based bottlenecks. At times, it's hard to determine which resource is actually causing poor performance. For example, let's say that users are reporting an application that is working slowly. Well, how do we know if it's a CPU or memory or network or storage issue? How do we identify and find those bottlenecks? And this can be really complex in both a physical server environment and in a virtualized environment as well. Another challenge with a virtualized environment is actually right-sizing our virtual machines. So how do we determine how much CPU, memory, disc space, and network bandwidth is actually required by a virtual machine? This is going to be a really challenging thing to determine. And if we don't properly size our virtual machines, we may end up wasting resources, and that leads to inefficient resource usage. So how do we make sure we're getting the most out of not only our CPU and memory and the resources of our ESXi hosts, but also out of the storage capacity that we've purchased? We also need to make sure that we're properly placing our workloads, that the virtual machines are running on the ideal host, and that my virtual machine files are being placed on the optimal data store. And we need to make sure that our critical virtual machines are prioritised above less critical workloads. So how does VMware's VSphere product line solve these optimization challenges? Well, for the first two optimization challenges identifying bottlenecks and right-sizing our virtual machines, we can use V-Realize Operations Manager. And what VRealize Operations Manager does is provide a simple dashboard-based tool. So essentially what Virtualized Operations Manager does is sit there and gather all this information from V Center, correlate it all, and analyse it all. And then it presents you a very simple dashboard that you can use to quickly identify what virtual machines have been improperly sized. Are there efficiency changes that we can make to make our environment run better? And that's the purpose of the V realizeoperations manager. How about efficient resource usage? Well, there are a number of tools available to us, right? Number one, we have thin provisioning disks. So if I create a virtual machine with an 80-gig disc and it only has 20 gigs of data stored on that 80-gig disk, that virtual disc will only consume 20 gigs of actual disc space. That's a thin provisioned. Disk memory is also thinly provisioned. So if I have a virtual machine that I've created with 16 gigs of memory, but it's only using eight gigs of memory, it will only consume eight gigs of physical memory on the ESXi host. How about the placement of workloads? What we have are a couple of load balancing solutions called Distributed Resource Scheduler and Storage Distributed Resource Scheduler, or DRS. And what DRS and storage DRS will do is automatically migrate virtual machines from host to host or from data store to data store to load, balance, and equalise the workload. And so by placing these workloads in the optimal location automatically, we can ensure that we have balanced resource usage and that our virtual machines will work as well as they possibly can. We can also use storage policies to govern which data stores virtual machines are placed on. So for example, let's say I have a really critical virtual machine that needs to perform very well and cannot tolerate a lot of storage latency. Well, I could write a storage policy that says this virtual machine needs to be stored on 15,000 rpm SaaS drives or on high-performance storage arrays. And then my storage policies, or as they used to be called, storage profiles, will take care of ensuring that that virtual machine is located on a data store that is compliant with that storage policy. And then we've got the prioritisation of critical VMs. So there are a number of tools built into the Vespa to accommodate this. The VSphere Distributed Switch supports quality-of-service marking of traffic. So what this means is that I can identify certain criteria in my Visa Distributed Switch based on a number of different factors. And basically, when traffic comes through and hits the Distributed Switch that matches our Q OS policy, a tag is appended to that traffic. So let's think about it this way: We've got all of these virtual machines running on an ESXi host, right? We've got many VMs running together on an ESXi host. So here is my ESXi host, and some of these VMs are going to be really important and some of them are going to be not so important. And let's say that this is a mission-critical VM right here. Well, as traffic leaves this VM and heads for the physical network, it's going to hit a virtual switch. And in this case, let's assume that the type of virtual switch we're using is the VSphere Distributed Switch. So here's my VSphere distributed switch. In that Vsphere distributed switch, I can identify a quality of service policy that will take that traffic and append a value to it, a quality of service value. So, as that traffic leaves my ESXi host and begins to move out into the physical network, which will just be represented by a kind of cloud-like shape here, the quality of the service tag that's been appended to it will govern how important that traffic is. The physical network hardware can actually recognise these Q OS values and prioritise traffic appropriately. So with a VISA for Distributed Switch, we can specify the quality of service on traffic that is actually respected by the physical network. We can also define shares and limits and reservations. So with limits and reservations, these are resource controls for virtual machines. And we're not going to get really deep on these concepts here, but I'm just going to give you a brief explanation of each of these three resource controls. So, shares are a relative priority for a virtual machine. So let's say, for example, that one virtual machine has a thousand memory shares and another virtual machine has 2000 memory shares. Well, the virtual machine with 2000 shares is entitled to twice as much memory as the virtual machine with 1000 shares. And this is important because remember, our virtual machines are running on an ESXi host, right? So again, here's this ESXi host and the ESXihost has a finite amount of memory, right? So here's the actual physical memory of the ESXi host. And on this host, I'm going to have all of these VMs running here, all these different VMs that are competing for the physical memory of that ESXi host. And under most circumstances, maybe they can all get as much as they are configured for. Under normal circumstances, maybe they're getting everything that they ask for. But if the ESXi host starts to run low on memory and the demand of my VMs starts to exceed what the host can actually provide, that's when shares start being enforced and the virtual machines with the most shares get priority access to those resources. So we have shares; we have limits, which basically just place a hard cap. For example, you could set a memory or a CPU limit on a virtual machine. And we have reservations as well, which is a way to guarantee a virtual machine a specific amount of some physical resource. And then finally, we got storage IO control and network IO control, which again allow us to prioritise critical VMs. And basically what these two are are our shares, limits, and reservations, except for storage and network. So storage IO control allows you to define shares, limits, and reservations for storage bandwidth. And what I mean by storage bandwidth is this ESXi host that my virtual machines run on. And the ESXi host has a physical connection to some sort of storage array out here that's somewhere else in the physical network. So as my virtual machines need to communicate with that storage array, I can assign shares, limits, and reservations that control which virtual machine gets priority access to that bandwidth. And it's the exact same thing with network IO control, right? But instead of communicating with storage, we're enforcing those controls on the physical network bandwidth that's available to my virtual machines. And the final solution to these priority-setting virtual machines is V flash.So here's what we can do with vFlash. With vFlash, we can go ahead and take an ESXi host—here's my host—and install some SSD capacity on the host, right? a solid-state drive. And solid state drives arereally fast, really fast storage. and I could allocate a chunk of this solid state drive to a particular virtual disc on a virtual machine. And what this virtual disc will use the SSD for is a cache. It will house some of the most frequently read data on that SSD drive. That way, when this virtual machine goes to access that data that it frequently needs to get to, it will be served up really quick off of the SSD. So those are some of the solutions that VS FARE provides to common optimization problems.

Hide