WEBVTT 00:00:00.000 --> 00:00:04.160 Welcome back to vSphere 8 in the real world and now we're going to discuss VM migration. 00:00:06.480 --> 00:00:12.480 So let's say either planned or unplanned, okay, so you're expecting some kind of maintenance or 00:00:12.480 --> 00:00:19.440 maybe it's something unexpected and you need to, for one or more reasons, you need a VM to be on a 00:00:19.440 --> 00:00:24.639 different host than what is currently on. Maybe the host that the VM is running on is having issues 00:00:24.639 --> 00:00:28.639 and you need to bring down that host. Maybe like all of a sudden you're seeing like a hardware 00:00:28.639 --> 00:00:32.400 failure occurring, you're getting errors on a certain device and you want to quickly get the 00:00:32.400 --> 00:00:37.200 VM off before that. That would be like a preventative measure or maybe you just need a 00:00:37.200 --> 00:00:41.360 patch. So this is totally scheduled. It's that certain day of the month that you guys patch your 00:00:41.360 --> 00:00:48.880 EFX by host and so we need to evacuate all the VMs off that host. Maybe just through your 00:00:48.880 --> 00:00:52.639 monitoring, you're looking at this and you're saying, well, I'm seeing that this particular 00:00:52.639 --> 00:00:58.160 host is heavily utilized. We're looking at CPU utilization in the 80s. We're seeing memory 00:00:58.160 --> 00:01:05.120 utilization in the 80s, 90s. We need to redistribute some of these VMs because this other host over 00:01:05.120 --> 00:01:10.000 here, its CPU utilization is only in the 20s and its memory utilization is only in the 30s. 00:01:10.000 --> 00:01:15.760 So we need to move some VMs off of this heavily utilized host to another one. But it's the middle 00:01:15.760 --> 00:01:21.440 of the day. You don't want to stop your workload. You don't want to interrupt your users, right? 00:01:22.080 --> 00:01:25.839 You need to patch your host, as we said, and you don't want to have to wait till the middle of the 00:01:25.839 --> 00:01:30.080 night to do it when no one's around. You want to do it right now in the middle of the day while 00:01:30.080 --> 00:01:34.480 everyone's working, while you're scheduled to be at work, and so you want to evacuate the host. 00:01:34.480 --> 00:01:40.559 So all these different scenarios are reasons why you might want to live migrate the VMs from one 00:01:40.559 --> 00:01:49.680 host to another. Live migrate is kind of a generic industry term for a vMotion. VMware's branded 00:01:49.680 --> 00:01:56.080 version of what they call a live migration is a vMotion. And so what a vMotion is, is simply 00:01:56.080 --> 00:02:01.519 we have a VM running on a host, and for one of many different possible reasons, we want to move 00:02:01.519 --> 00:02:07.519 that VM from host one over to host two without bringing down the workload. And so we decide we're 00:02:07.519 --> 00:02:13.520 going to vMotion that VM's workloads. We're going to move the compute from one host to another. 00:02:13.520 --> 00:02:17.600 I'm going to right-click on the VM. I'm going to say I want to migrate, and I'm going to go 00:02:17.600 --> 00:02:21.759 through a wizard, which asks me a bunch of questions like what host do I want to move it to, 00:02:21.759 --> 00:02:25.919 and the priority I want to use to move it. We'll walk through that, and I want to move it to another 00:02:25.919 --> 00:02:31.119 host. So then I choose the second host. VMware's going to run a check and say, yep, you are able 00:02:31.119 --> 00:02:36.720 to do a vMotion from host one to host two. And you go through the wizard, and you say okay. 00:02:36.720 --> 00:02:44.639 And what VMware starts doing, what the ESXi hosts start doing, is they will start copying the RAM 00:02:44.639 --> 00:02:50.960 from one host to the other. But while you're doing that, that VM's using that RAM. It's making 00:02:50.960 --> 00:02:57.119 changes. And so it keeps a map of all the pages in RAM, and as a page changes during this copy, 00:02:57.119 --> 00:03:01.600 it marks the changes. It marks the pages that have changed. So once you've gone through 00:03:01.600 --> 00:03:06.559 all the pages of all the RAMs copied from host one to host two, it then goes through and says, 00:03:06.559 --> 00:03:14.160 okay, now what page has changed during this copy process? And it copies just those pages over. 00:03:14.240 --> 00:03:19.440 And again, it's keeping track of what pages changed. And then once it gets all those synced 00:03:19.440 --> 00:03:24.479 over, it can make another copy. And when the host feels that the number of changes that are left 00:03:24.479 --> 00:03:32.399 are small enough that we can quiesce the VM, move those final pages, move the VM over, 00:03:32.399 --> 00:03:39.600 and fire it up without there being an obvious interruption in services, then it quiesces the VM 00:03:39.600 --> 00:03:46.080 so it does this quick pause, copies those pages, and then it also copies over the CPU registers 00:03:46.080 --> 00:03:51.039 that the VM has registered on the CPU, and then it fires it on this host. Now, you might wonder, 00:03:51.039 --> 00:03:55.440 well, how long does it quiesce for? Because if I'm running a database, that could mess up my 00:03:55.440 --> 00:04:00.559 database. My applications might disconnect. If users are trying to open files, I'm going to get 00:04:00.559 --> 00:04:04.800 a bunch of help desk tickets saying, hey, this file server's down. I can't get to the file. Oh, 00:04:04.800 --> 00:04:08.559 wait, there it is. But in the meantime, they've made the phone calls. Your help desk phone is 00:04:08.559 --> 00:04:14.559 blowing up. Emails are being sent. Any monitoring software you have might be firing off alarms 00:04:14.559 --> 00:04:20.239 saying, this server's down, this server's down. Oh, wait, no, it's back now. Actually, it is so fast. 00:04:20.239 --> 00:04:26.559 It does it so quickly that if you're pinging from a workstation to that server and you'll see ping, 00:04:26.559 --> 00:04:32.399 ping, ping, sometimes you'll see all, if you're going from a Windows box that defaults four, 00:04:32.399 --> 00:04:35.679 all four will come across. You won't miss any. If you're in a continuous ping, 00:04:36.480 --> 00:04:41.600 you will see ping, ping, ping, all the way down. You won't miss a ping. Sometimes you'll miss one. 00:04:41.600 --> 00:04:47.600 Sometimes you'll miss one. Oftentimes, I'd say less than half, but still pretty often, 00:04:47.600 --> 00:04:52.720 you won't see any packets dropped. It will actually just be so fast and so seamless. 00:04:54.239 --> 00:04:57.679 Because what also happens is the VM, when it lands on the new host, 00:04:58.320 --> 00:05:05.040 the host is going to send out a packet from that VM to the network so that the switches know, 00:05:05.040 --> 00:05:09.600 this MAC address is now over here on this interface. It was on that interface. It's now 00:05:09.600 --> 00:05:15.600 on this interface. So VMware gets the number of pages that have changed down to a bare minimum. 00:05:16.239 --> 00:05:22.399 It fires the VM up on the new host. It sends a packet out to the network from that VM so the 00:05:22.399 --> 00:05:28.160 switches know where that VM now is. The VM doesn't know what happened. The hosts obviously know, 00:05:28.160 --> 00:05:34.079 but they don't care. The users don't know what happened, right? The network knows something 00:05:34.079 --> 00:05:38.799 changed. They don't know why it changed, but they know this MAC address was on this interface, 00:05:38.799 --> 00:05:44.480 and now it's over here on this interface. Okay, great. No problem. And the application still 00:05:44.480 --> 00:05:50.079 runs smoothly. The user's experience is fine. You won't be dropping packets. Nothing. It'll 00:05:50.079 --> 00:05:55.839 be perfectly smooth. So it's a really awesome thing. It happens very, very fast. VMware has 00:05:55.839 --> 00:06:03.200 perfected what's called a live migration. So zero downtime, live migrations, moves your workload 00:06:03.200 --> 00:06:09.519 from one host to another. It will move between different switches, different port groups if you 00:06:09.519 --> 00:06:14.239 ask it to. You can actually move between clusters. You can even migrate from one cloud to another. 00:06:14.239 --> 00:06:20.239 So if you have a vSphere environment in your data center here, and you have another one that's maybe 00:06:20.239 --> 00:06:24.320 like in a different city or state, or maybe it's in Azure, instead of being in your data center, 00:06:24.320 --> 00:06:27.920 it's in Azure, you can move workloads up into Azure. All kinds of very cool things. Now, 00:06:27.920 --> 00:06:33.119 some of those things require additional services, right? You need a cloud license, 00:06:33.119 --> 00:06:39.359 and you need a license for metro clustering and things like that. But the VMs will move 00:06:39.359 --> 00:06:46.320 very quickly. It's a very, very cool feature. All right. So here we're showing that you have 00:06:46.320 --> 00:06:52.320 a VM running on host one, and you can live migrate it from one host to host two. All right. 00:06:53.040 --> 00:06:58.239 DRS will do this for you automatically too. If you have a license for DRS and your DRS is set 00:06:58.239 --> 00:07:04.720 to fully automated, that scenario that we gave where this host is heavily utilized, 80% CPU, 00:07:04.720 --> 00:07:11.040 90% memory, or something like that, this guy over here, 20% CPU, 30% memory, real low versus real 00:07:11.040 --> 00:07:15.440 high, DRS can look at things like that and say, let's balance this out. Let's try and get it a 00:07:15.440 --> 00:07:19.359 little bit closer. It's not going to try and get it exactly because it doesn't want to keep moving 00:07:19.359 --> 00:07:25.119 workloads constantly. But it will say, okay, we're getting pretty close. And it will actually, 00:07:25.119 --> 00:07:29.359 on its own, move a VM from one host to another to try and balance the workload. 00:07:29.359 --> 00:07:33.119 You can specify when you configure DRS how aggressive you want that to be. 00:07:34.160 --> 00:07:37.679 It's a scale of one to five, and you can say how aggressive or not aggressive you want it to be. 00:07:37.679 --> 00:07:42.160 But DRS will do that for you automatically. You'll automatically live migrate VMs from one host to 00:07:42.160 --> 00:07:47.119 another. And maybe your host, your cluster has 30 hosts. And it will look at all of them and say, 00:07:47.119 --> 00:07:50.959 okay, these guys are heavily utilized. These guys are not. And why would that happen? Why 00:07:50.959 --> 00:07:55.839 would you have a cluster where some hosts are really heavily utilized and some are not? 00:07:55.839 --> 00:08:01.279 Well, maybe when you started all these up, certain VMs weren't that busy. The databases 00:08:01.279 --> 00:08:05.600 weren't that big. They didn't have that many users. Time has changed. Databases have grown. 00:08:06.720 --> 00:08:11.920 More users are hitting them. Other applications aren't as busy. It might not even be over a 00:08:11.920 --> 00:08:16.799 period of months and years. It might be just within a month. This week is end of month, 00:08:16.799 --> 00:08:20.480 and the servers that run all the accounting databases are just getting hammered from all 00:08:20.480 --> 00:08:25.600 the reporting. And so we need to spread those out more. And the other servers for another department, 00:08:25.600 --> 00:08:29.279 maybe they slow down a certain time of the month, and they don't do as much. 00:08:29.279 --> 00:08:33.200 So at the beginning of the month, all of a sudden, we see manufacturing taking off. All 00:08:33.200 --> 00:08:38.000 these new orders that sales pushed at the very end of the month, they hit the beginning of the month. 00:08:38.000 --> 00:08:42.320 And so those reports are going crazy, and accounting has slowed down a little bit. 00:08:42.880 --> 00:08:47.280 So there's going to be different reasons why certain VMs at certain days of the week or 00:08:47.280 --> 00:08:52.479 certain days of the month or different times of the year, certain ones are busier. DRS is going 00:08:52.479 --> 00:08:58.080 to monitor it constantly, and it can make adjustments to that automatically. Or you 00:08:58.080 --> 00:09:01.840 can just be looking at it, and you can say, this host, all of a sudden, is really busier. That 00:09:01.840 --> 00:09:06.159 one's not so much. Maybe it's not something you're doing to try and balance workload, 00:09:06.159 --> 00:09:11.200 but you're trying to evacuate a host. We want to patch the host. We want to update hardware on 00:09:11.200 --> 00:09:16.239 the host, and we don't want to wait to shut VMs down. We want to do it during the day, 00:09:16.239 --> 00:09:20.559 during production time. We trust this service. It works well for us, and we're going to go 00:09:20.559 --> 00:09:24.320 ahead and take care of it right now. All right? So that's live migration there. 00:09:25.760 --> 00:09:29.919 There's also a storage migration. So all those things we just discussed 00:09:29.919 --> 00:09:37.280 about with moving to compute, you can also do with storage. So we have a VM running on a certain 00:09:37.280 --> 00:09:44.239 data store that's on our stand, for example, and we might see that that LUN is getting really 00:09:44.239 --> 00:09:50.559 heavily utilized. The IO is very high. The latency is getting really high, and we need to lower the 00:09:50.559 --> 00:09:55.119 latency on that data store. And one way we're going to do that is we're going to move some 00:09:55.119 --> 00:10:02.640 VMs to another data store that is less utilized, or maybe it has much, much faster disks, and so 00:10:02.640 --> 00:10:10.239 the latency is just going to be much lower anyway. And so we can storage migrate all the files that 00:10:10.239 --> 00:10:15.520 make up that VM. We can move them from one data store to another data store doing a storage 00:10:15.520 --> 00:10:23.200 migration. And this is a little bit less magical, so to speak, because it's just moving files, 00:10:23.200 --> 00:10:26.960 and we're going to tell the host that's running that VM, okay, your files are here, and the host 00:10:26.960 --> 00:10:31.359 is going to be moving them over and say, okay, now your files are there. Right? It'll copy files over, 00:10:31.359 --> 00:10:36.799 it'll monitor for changed blocks, it'll synchronize those changed blocks, again, quiesce the storage, 00:10:36.799 --> 00:10:43.919 and then finish, and now you're living over there. Not a real big surprise that we can do that. 00:10:43.919 --> 00:10:49.280 It actually is a newer feature than a regular compute vMotion. A compute vMotion has been 00:10:49.280 --> 00:10:53.039 around for a lot longer than storage migrations, but more storage migrations have been around for 00:10:53.039 --> 00:11:00.080 quite a while too. So you can also change storage, and we can also change compute and storage at 00:11:00.080 --> 00:11:05.520 once. So if we have a license for both a vMotion and a storage vMotion, and let's say I have a 00:11:05.520 --> 00:11:10.159 VM that's on local storage on a host. Well, you can't move the compute to a different host because 00:11:10.159 --> 00:11:15.520 that host can't see that local storage on the first host. So what I can do is say I want to 00:11:15.520 --> 00:11:23.520 move the compute and the storage from host one to local storage on host two. And so then it will 00:11:23.520 --> 00:11:28.000 literally just copy all the storage files over, and it'll copy the compute files all over, and now 00:11:28.000 --> 00:11:34.400 it lives over there on that new host. So we can do a compute vMotion, we can do a storage vMotion, 00:11:34.400 --> 00:11:39.440 or we can choose to do both. So there we're seeing we're just moving the virtual disk, right? 00:11:39.440 --> 00:11:48.159 So let's go ahead and jump into our demo environment, and I'll show you how to do a vMotion. 00:11:48.719 --> 00:11:54.320 So here we have two ESXi hosts, and we have a VM in the cluster with these two hosts. 00:11:54.880 --> 00:12:03.280 So if we go look at this cluster, I can see that this demo VM, which is a Red Hat Linux VM, 00:12:04.000 --> 00:12:09.520 is on the host that has the address of .38. So what we can do in our demo is we'll go ahead and 00:12:09.520 --> 00:12:16.719 we'll migrate this VM from 38 to 39. So I'm going to go ahead and choose my virtual machine. 00:12:17.840 --> 00:12:22.000 I'm going to right-click and migrate, and just so you know, this first time we attempt it, 00:12:22.000 --> 00:12:27.119 it's not going to be successful. I'm going to go ahead and click on to change my compute resource, 00:12:28.080 --> 00:12:40.000 say next, and if I choose 38, it tells me it's compatible because it's already on 38, 00:12:40.000 --> 00:12:44.080 so I'm really not going to move anything. It's fine living there. If I choose 39, 00:12:45.039 --> 00:12:49.520 I'm going to get an error that there's incompatibility or there's compatibility 00:12:49.520 --> 00:12:53.760 issues that need attention. If I look to see, well, what are those compatibility issues? 00:12:53.760 --> 00:12:59.039 In this case, I have a no vMotion interface configured for these two hosts. Now, 00:13:01.440 --> 00:13:06.479 other things you might see is that the VM is on storage that one host can see and one host can't 00:13:06.479 --> 00:13:10.559 see. You know, things like that could also happen. So if there's a storage problem, it'll tell you 00:13:10.559 --> 00:13:16.239 that, you know, host number 39 can't see the storage on host 38 or something like that. 00:13:16.239 --> 00:13:20.960 So there's different things that can come up. But in this case, it's that we don't have a 00:13:20.960 --> 00:13:25.280 vMotion interface configured. So I'm going to go ahead and close this. I'm going to cancel this. 00:13:26.640 --> 00:13:33.520 And ideally, what you'd want to do is have a dedicated vMotion network. So in a perfect 00:13:33.520 --> 00:13:40.960 world, we would go to our configuration, and under our virtual switches, I would have a 00:13:40.960 --> 00:13:47.359 VMkernel port configured for a vMotion network. And this vMotion network would have a dedicated 00:13:47.359 --> 00:13:54.080 VLAN. So maybe it'd be on VLAN, you know, 30 or whatever you've chosen, just for vMotion. 00:13:54.080 --> 00:13:58.559 And a lot of times, these hosts are going to be all in the same physical location. 00:13:58.559 --> 00:14:03.760 And so I have a dedicated VLAN. And the only thing this VLAN is used for is for vMotion, 00:14:03.760 --> 00:14:10.719 and there's no routing happening. So for example, this host, 38, has an address of 192.168.51.1 00:14:10.960 --> 00:14:16.479 for this vMotion network. And 39 00:14:20.159 --> 00:14:27.679 has a vMkernel port of 192.168.51.2. So they're on the same LAN. They can be on the same VLAN. 00:14:27.679 --> 00:14:30.960 So vMotion is not going to be happening through a router, not going to be routing it. 00:14:30.960 --> 00:14:37.280 It's just going to go through a Layer 2 switch and connect. So then what I would normally do 00:14:37.359 --> 00:14:42.239 is I'm going to go in and edit this network, this port group here. I'm going to say edit settings. 00:14:46.400 --> 00:14:49.440 Actually, you know what? I'm sorry. This is the wrong place. I need to go to my vMkernel. My 00:14:49.440 --> 00:14:54.640 mistake. So my vMkernel, vmk1, this is the one that is on my vMotion network. This is where I'm 00:14:54.640 --> 00:15:01.200 going to go and edit. And I'm just going to just enable vMotion on that kernel. And I would do the 00:15:01.200 --> 00:15:08.320 same thing on both of these hosts. I go to the other host, and this is also my vMotion network. 00:15:09.440 --> 00:15:14.000 And I'm going to edit this and choose vMotion. Now, in this environment, because this is all 00:15:14.000 --> 00:15:20.640 virtualized, the virtual switch that's underlying all this environment isn't passing that traffic 00:15:20.640 --> 00:15:27.919 correctly. So this is kind of show you to make this work. What we're going to do is we're going 00:15:27.919 --> 00:15:34.960 to use vmk1. Normally, we wouldn't choose vmk1 because vmk1 is my management NIC. 00:15:35.760 --> 00:15:39.119 So you already have management configured on here. I would normally have a dedicated 00:15:39.119 --> 00:15:43.840 vMkernel port on a dedicated network just for vMotion. But for this demo, 00:15:43.840 --> 00:15:48.799 I'm going to go ahead and choose it here. And I'm going to go to this host. 00:15:48.799 --> 00:16:00.400 Let's see what's selected here. Make sure that's not there. Go to vmk0, edit, enable vMotion here. 00:16:04.239 --> 00:16:09.039 And I wanted to be a little bit extra, you know, sure. Another thing I might want to do 00:16:09.039 --> 00:16:18.239 is check my firewall and see that I have vMotion for incoming and vMotion for outgoing configured. 00:16:18.239 --> 00:16:26.239 And I do on this host. And for vMotion, it also is configured on this host. That is done by default. 00:16:26.239 --> 00:16:29.520 You don't need to configure that. But that's something you might want to be if you're being 00:16:29.520 --> 00:16:34.080 really, really thorough, you might want to check. So now that I've checked my firewall, I've got – the 00:16:34.080 --> 00:16:37.919 big thing I need to configure is I need to make sure my vMkernel adapters that can communicate 00:16:37.919 --> 00:16:47.200 with each other with that vM service selected. So I have vMotion enabled on this vMkernel adapter. 00:16:49.200 --> 00:16:55.840 And this vMkernel adapter also has vMotion enabled. So now I can go to this virtual machine. 00:16:55.840 --> 00:17:00.400 I'm going to select this. I'm going to say I want to migrate. Same thing. Again, I'm only 00:17:00.400 --> 00:17:14.239 going to change the compute resources. Say next. So again, it's on 38. And so, of course, that works. 00:17:14.319 --> 00:17:23.599 And if I choose 39, 39 is also successful. So I'm going to say next. And if I wanted to change 00:17:23.599 --> 00:17:29.359 the network from that host one is using to something different on host two, I could go in 00:17:29.359 --> 00:17:34.800 and choose a different vM network. Maybe I have one for sales configured or something like that. 00:17:34.800 --> 00:17:42.079 I'm going to leave it on vM network. We're good there. I can specify the priorities, 00:17:42.800 --> 00:17:47.119 a high priority or just normal. I'm going to say high priority. I always just leave it there. 00:17:48.479 --> 00:17:51.599 Next. And now I'm going to go ahead and say I want to finish this. 00:17:52.640 --> 00:17:58.079 And I'll see a task startup down here. All right. Is that 20%? Once it gets past 2021, 00:17:58.079 --> 00:18:01.439 that's a good indication. Not a guarantee, but a good indication is going to go through. That 00:18:01.439 --> 00:18:10.719 means that the kernels are talking. So right now what it's doing is copying all that memory over 00:18:10.719 --> 00:18:18.239 and it's making a record, a note of any changes to any pages in RAM that are changing. Okay. It 00:18:18.239 --> 00:18:23.359 did all that. It synchronized everything over, copied over to CP registers. So now it says it's 00:18:23.359 --> 00:18:32.000 completed. So if I go look at 38 and at VMs, that VM's gone. And if I go to 39, I see it's there. 00:18:32.000 --> 00:18:36.479 So all I needed to do in this situation is there are some prerequisites. Like, for example, 00:18:36.479 --> 00:18:48.719 this VM, if I go to look at storage, this VM is on my shared storage database. If the VM was on 00:18:48.719 --> 00:18:56.560 datastore 38, datastore 38 only connected to one host, whereas this datastore where the VM lives 00:18:56.560 --> 00:19:04.079 is on both hosts. So I need shared storage, right? And I see there's that demo VM that both the hosts 00:19:04.079 --> 00:19:09.439 can connect to. So I need it to be on shared storage. I need to have a shared network. It needs 00:19:09.439 --> 00:19:16.400 to be a low-latency network. You can actually do a VMotion over a metro network, so over a wide-area 00:19:16.400 --> 00:19:24.319 network. Your latency for round-trip traffic needs to be under 150 milliseconds. So 150 is kind of 00:19:24.319 --> 00:19:29.599 high. It's actually a pretty – that's not hard to achieve. So if you have a pretty decent network, 00:19:29.599 --> 00:19:35.920 you can do it under – as long as you have under 150-millisecond latency. So shared storage, 00:19:35.920 --> 00:19:43.040 a network that both the hosts can communicate on that has VMotion enabled on that interface, 00:19:43.040 --> 00:19:47.280 and you've got VMotion configured, and we can move hosts between – or VMs between different hosts. 00:19:47.280 --> 00:19:52.079 In this example, we only have two. In the same cluster, there might be 30 hosts. And in those 00:19:52.079 --> 00:19:57.119 30 hosts, I can move the VM to any of those hosts, as long as all the hosts in the cluster can see 00:19:57.119 --> 00:20:03.199 the storage, and as long as the hosts all have a VMkernel interface configured that can talk to 00:20:03.199 --> 00:20:06.479 the other hosts. And that's how you configure and do a VMotion.