WEBVTT 00:00:00.000 --> 00:00:04.880 Welcome back to vSphere 8 in the real world. Now we're going to discuss additional features and troubleshooting for your network. 00:00:07.720 --> 00:00:09.720 So traffic shaping. 00:00:09.760 --> 00:00:15.080 Traffic shaping is one of those things that not a lot of people do because they kind of want to see their stuff just 00:00:15.080 --> 00:00:17.400 run and not have interruptions and things like that. 00:00:18.040 --> 00:00:24.240 You will see it in environments though where there's a lot of machines that are maybe like low priority. 00:00:24.719 --> 00:00:31.240 They're not really worried about their performance and things like that. And maybe they are noisy on the network though, right? 00:00:31.240 --> 00:00:33.439 They have a tendency to take up a lot more bandwidth than needed. 00:00:33.439 --> 00:00:38.680 So they'll go ahead and put some traffic shaping on a port group for those really less important virtual machines 00:00:38.720 --> 00:00:46.680 so that the more important virtual machines running will have, you know, higher levels of access, less impeded access to network resources. 00:00:46.799 --> 00:00:49.880 But again, it's not something I see out there a lot. 00:00:50.560 --> 00:00:56.439 You can set there an average bandwidth. So a VM is not saying average is not the max, obviously, right? 00:00:56.439 --> 00:01:01.480 It's saying that VMs can can peak above that. They can even burst, right, to a certain level. 00:01:02.439 --> 00:01:07.120 But those peaks and bursts have to average out to not above a certain amount. 00:01:07.120 --> 00:01:12.720 So you can go and you can say that on a VM that you want the average to be less than, you know, 00:01:13.959 --> 00:01:18.080 500, you know, megabits or 500 kilobits or some crazy thing like that, right? 00:01:19.080 --> 00:01:22.440 And you can say what the maximum peak can be, what the maximum burst can be. 00:01:22.599 --> 00:01:28.199 So a peak and a burst are different in that a peak is going to be a spike up and down and a burst will be sustained for a little bit longer. 00:01:29.279 --> 00:01:33.480 But again, we have to average out to be within a certain average. 00:01:33.480 --> 00:01:37.559 So you can't run a peak or a burst for very long because they'll start to exceed your average. 00:01:37.559 --> 00:01:44.279 Once you start to hit that average, it's going to make it come back down to be at or below average until there's room for another peak or another burst. 00:01:44.639 --> 00:01:46.879 All right, so that's your traffic shaping policy. 00:01:49.080 --> 00:01:53.440 So MAC addresses, are you going to allow MAC address changes or not? 00:01:53.440 --> 00:01:57.519 Most of the time in most environments, you don't want to allow MAC address changes. 00:01:59.239 --> 00:02:02.839 Most of the time, MAC address changes are going to be managed by your vCenter. 00:02:02.839 --> 00:02:13.320 And so I've seen environments and different environments with different hypervisors where you have hosts running and they start assigning MAC addresses to VMs. 00:02:13.320 --> 00:02:17.320 No problem. And then all of a sudden you have another hyper-v environment, for example, maybe. 00:02:17.720 --> 00:02:22.720 And all of a sudden you start getting duplicate MACs because these guys aren't communicating with each other. 00:02:22.720 --> 00:02:27.279 And then you have to go in there and do some manual editing and say, this one can use MACs between here and here. 00:02:27.279 --> 00:02:29.559 And you can allow other ones at a different range. 00:02:30.479 --> 00:02:37.160 vCenter is going to manage that and make sure you don't have duplicates and make sure that they're unique within your virtual environment. 00:02:38.240 --> 00:02:44.679 If you have a standalone ESXi host, then the host obviously is the one that's going to manage those MAC address assignments. 00:02:44.679 --> 00:02:50.479 You can also go in and set a range of what they can use. 00:02:50.479 --> 00:02:56.160 I've never really seen in a VMware environment where you – because it's always using vSphere. 00:02:56.160 --> 00:03:00.119 I've never seen where you needed to manually set a range for MAC addresses. 00:03:00.119 --> 00:03:04.720 I have seen with other hypervisors where you had to do that, but not with a vSphere environment. 00:03:05.559 --> 00:03:11.119 So they can be assigned by the individual host or they can be assigned and managed by vSphere. 00:03:11.119 --> 00:03:14.600 So that way you don't have to worry about, you know, things like conflicts and things like that. 00:03:17.240 --> 00:03:18.600 Paravirtual RDMA. 00:03:18.600 --> 00:03:21.919 So paravirtual RDMA is like regular RDMA. 00:03:21.919 --> 00:03:27.919 RDMA basically means that we have systems that can read the memory of another system 00:03:27.919 --> 00:03:34.399 without having to go through the operating system, without using the CPU on that remote system. 00:03:34.399 --> 00:03:39.039 So in order to do this, you need physical adapters that support RDMA. 00:03:39.039 --> 00:03:44.880 Well, if you want virtual machines that can do the same kind of RDMA access, 00:03:44.880 --> 00:03:51.039 then you need to have a paravirtual RDMA network adapter in that virtual machine. 00:03:51.039 --> 00:03:53.759 So what you will do when you're building your virtual machine 00:03:53.759 --> 00:03:56.440 or if you're adding a new adapter to a virtual machine, 00:03:56.440 --> 00:04:01.720 rather than using the normal one most of the time you'll use as a VMXnet 3 or E1000, 00:04:01.720 --> 00:04:07.320 you'll actually use the PVRMA, RDMA network adapter. 00:04:07.360 --> 00:04:13.919 So this will allow this paravirtual RDMA access between virtual machines. 00:04:13.919 --> 00:04:14.600 All right. 00:04:14.600 --> 00:04:19.640 So this is going to be more commonly used environments where you need very fast communication 00:04:19.640 --> 00:04:21.480 between virtual machines. 00:04:21.480 --> 00:04:24.200 And this is going to be done, like, for example, if you have any kind of, like, 00:04:24.200 --> 00:04:29.279 high-performance compute environments or if you're doing machine learning, AI type of things 00:04:29.279 --> 00:04:33.920 where very fast communication is important between machines in a cluster, 00:04:33.920 --> 00:04:36.000 then you might want to enable this. 00:04:37.440 --> 00:04:44.600 It was introduced with ESX 6.5, so you need ESX 6.5 or later, vCenter 6.5 or later. 00:04:44.600 --> 00:04:47.239 You need to be using a distributed virtual switch, right? 00:04:47.239 --> 00:04:52.640 You need version hardware 13 or later because that's what's going to support the 00:04:52.640 --> 00:04:56.399 paravirtual RDMA adapter, obviously, or something obviously, 00:04:56.399 --> 00:04:59.040 but you'll also have a Linux operating system. 00:04:59.040 --> 00:05:04.480 And there's this thing here that the paravirtual RDMA is automatically enabled in vSphere 7. 00:05:04.480 --> 00:05:07.720 You don't have to go into enable like you would in 6 and 6.5. 00:05:11.079 --> 00:05:16.320 So here, if we want to enable a paravirtual RDMA on a virtual machine, 00:05:16.320 --> 00:05:18.200 so basically what we're going to do is we're going to go to the VM. 00:05:18.200 --> 00:05:19.720 It's going to be powered off. 00:05:19.720 --> 00:05:22.079 We can go to edit the settings of the virtual machine. 00:05:22.079 --> 00:05:26.359 We can select the virtual hardware we want to go in there and configure and add. 00:05:26.359 --> 00:05:28.600 We're going to add a device. 00:05:28.600 --> 00:05:30.239 We're going to go in and we go to add. 00:05:30.239 --> 00:05:31.720 We're going to say add a network card. 00:05:31.720 --> 00:05:34.359 We're going to expand that network card because normally what you'll see is just 00:05:34.359 --> 00:05:37.480 be able to choose the port group you want to assign to it. 00:05:37.480 --> 00:05:42.320 If you expand it, you'll also be able to go in there and change the type of adapter 00:05:42.320 --> 00:05:44.760 it's going to be virtualizing. 00:05:44.760 --> 00:05:47.440 And by default, normally it goes to the VMXSAT3. 00:05:47.440 --> 00:05:51.200 You'll just change that to the PVRDMA adapter. 00:05:51.200 --> 00:05:55.760 And then you can go ahead and say next and install that virtual adapter on there. 00:05:55.760 --> 00:05:57.399 So it's pretty easy. 00:05:57.399 --> 00:06:00.519 So if I can install any other NIC, but you just need to make sure that you choose a 00:06:00.519 --> 00:06:06.480 pair of virtual RDMA adapter instead of the default VMXSAT3 or you might sometimes use 00:06:06.480 --> 00:06:10.600 the E1000 in your environment depending upon if you have VMware tools installed or not. 00:06:10.600 --> 00:06:19.160 VMXSAT3 does require VMware tools, but so will the pair of virtual adapter. 00:06:19.160 --> 00:06:25.000 So vSphere 6 – I'm sorry, vSphere 6 – and vSphere IPv6. 00:06:25.000 --> 00:06:30.119 So IPv6 is – one of those things that's been – people have been saying for 25 years 00:06:30.119 --> 00:06:32.920 that it's like, oh, everyone, we're going to have to use it here soon, and for 25 years 00:06:32.920 --> 00:06:36.079 we haven't had to go from version 4 to version 6 yet. 00:06:36.079 --> 00:06:41.640 But you are starting to see more companies making a push to do that. 00:06:41.640 --> 00:06:44.600 Not that it's this imminent disaster around the corner. 00:06:44.600 --> 00:06:48.720 I think more people are starting to see like, okay, there's not only are we running out 00:06:48.720 --> 00:06:55.239 of IPv4 addresses like we've been saying for 25 years, but also there's benefits to IPv6 00:06:55.239 --> 00:06:58.679 and so people are starting to consider going there. 00:06:58.679 --> 00:06:59.679 It's easier address space. 00:06:59.679 --> 00:07:03.880 I don't have to worry about overlapping with, you know, things out in the public area, the 00:07:03.880 --> 00:07:04.880 internet. 00:07:04.880 --> 00:07:08.399 Multicasting isn't something that's used a ton. 00:07:08.399 --> 00:07:12.200 There's certain use cases where multicasting is important, but it's starting to be used 00:07:12.200 --> 00:07:17.920 more and more for certain services, and IPv6 is built to make multicasting really efficient, 00:07:17.920 --> 00:07:19.359 really fast. 00:07:19.359 --> 00:07:24.920 And routing is a real simple operation with IPv6, a little easier than with IPv4. 00:07:24.920 --> 00:07:31.480 So if you want to enable IPv6 in your host, you can go to your DCUI, you're going to log 00:07:31.480 --> 00:07:35.359 into there, you're going to go and configure your management network, and you'll just go 00:07:35.359 --> 00:07:38.079 in and configure and add the IPv6. 00:07:38.079 --> 00:07:41.839 And then, of course, you'll have to say do you want to use DHCP or static assignment 00:07:41.839 --> 00:07:43.079 address. 00:07:43.079 --> 00:07:45.839 But you can just do it through basically through the console. 00:07:45.839 --> 00:07:48.079 You can go in there and enable IPv6. 00:07:48.079 --> 00:07:53.640 Once you've enabled IPv6, you might want to also then go in and disable IPv4. 00:07:53.640 --> 00:07:57.559 So it just depends if you want to run a dual stack or if you want to run a single IPv6-only 00:07:57.559 --> 00:07:58.559 stack. 00:07:58.559 --> 00:07:59.559 That's going to be up to you. 00:07:59.559 --> 00:08:00.559 All right. 00:08:00.559 --> 00:08:09.040 But you can also, in through the DCUI, go in there and you can disable IPv4. 00:08:09.040 --> 00:08:12.480 So enabling IPv6 on the host and in vCenter. 00:08:12.480 --> 00:08:16.720 So going into the DCUI, as we just discussed, you know, on our host, we can enable it. 00:08:16.720 --> 00:08:19.160 You might also want to enable it in vCenter. 00:08:19.160 --> 00:08:23.760 There might be some gotchas when you enable it on a host that's been running for a while. 00:08:23.760 --> 00:08:27.399 So you might want to be kind of aware that there might be some things you'll need to 00:08:27.399 --> 00:08:28.399 do. 00:08:28.399 --> 00:08:31.160 So you probably want to – well, if you're rebooting the host and going to the DCUI, 00:08:31.160 --> 00:08:34.280 you have to put it in maintenance mode and evacuate all the VMs off. 00:08:34.280 --> 00:08:37.960 But before you take it out of maintenance mode and bring it back online, start putting 00:08:37.960 --> 00:08:42.520 VMs back, you'll probably want to do some testing and make sure that everything's working 00:08:42.520 --> 00:08:44.960 the way you're expecting it to work. 00:08:44.960 --> 00:08:45.960 Okay? 00:08:46.960 --> 00:08:53.760 So, for example, if you're using IPsec on your ESXi host and you enable IPv6, you might 00:08:53.760 --> 00:08:56.400 find that there's some communication problems afterwards. 00:08:56.400 --> 00:09:02.039 You can probably fix it pretty easily just by going in there and removing IPsec and then 00:09:02.039 --> 00:09:09.039 re-enabling IPsec with IPv6 enabled, and that will probably clear up your problem for you. 00:09:09.039 --> 00:09:12.539 Change IP address for the VCSA deployment with a static IP. 00:09:12.539 --> 00:09:16.419 So you're going to need to update your DNS records, wait for any kind of caching to clear 00:09:16.419 --> 00:09:18.299 out and some things like that, right? 00:09:18.299 --> 00:09:19.780 So that's something you need to be aware of. 00:09:19.780 --> 00:09:21.940 When you change any IP address, this can happen. 00:09:21.940 --> 00:09:24.539 It's not just a unique thing to go into IPv6. 00:09:24.539 --> 00:09:30.299 Any time you change vCenter's IP address, there might be some gotchas and some delays 00:09:30.299 --> 00:09:33.299 and other devices realizing that's changed. 00:09:33.299 --> 00:09:39.539 Delay when removing an NSX-distributed virtual port group, which is located, attached, or 00:09:39.539 --> 00:09:40.539 deleted. 00:09:40.539 --> 00:09:41.539 Okay? 00:09:41.539 --> 00:09:46.700 So what they're saying here is that if you're running IPv6 and you want to remove a port 00:09:46.700 --> 00:09:52.780 group from a distributed virtual switch, you might see it take a while and really you have 00:09:52.780 --> 00:09:53.780 one real option. 00:09:53.780 --> 00:09:56.380 You need to be patient and wait for it to happen. 00:09:56.380 --> 00:09:57.380 It takes longer now. 00:09:57.380 --> 00:10:02.539 They did say you can reconfigure and lighten the load, but that's not really changing because 00:10:02.539 --> 00:10:04.179 now you're just not deleting the port group. 00:10:04.179 --> 00:10:05.500 You're reconfiguring the port group. 00:10:05.500 --> 00:10:06.700 You're shrinking the port group. 00:10:06.700 --> 00:10:09.099 If you want to actually delete it, it's just going to take a while. 00:10:09.099 --> 00:10:10.900 You need to be patient and wait for it to run.