Welcome back to vSphere 8 in the real world, and now we're going to talk about setting up your networking.
So, one of the things you're going to want to do is you're going to need to add an adapter, a physical adapter, to your physical switches.
Now, first you need to create a physical switch, and once you've created a physical switch, you can go in there and you can enable the adapter that you want to assign to that switch.
You can either make it an unclaimed adapter, you can make it an active adapter, a standby adapter, or an unused.
Unclaimed means that the adapter isn't assigned to any virtual switch, and unused means it's assigned to the switch, but currently it's not set to be an active or a standby, and then all you do is just move it up.
If it's assigned to a switch but unused, then another switch can't use it. If it's unclaimed, it can be assigned to a switch.
A physical NIC on a host can only belong to one virtual switch.
Now, that virtual switch might have multiple port groups, so you can have multiple different policies for that NIC based on what port group it's assigned to, based on the traffic coming from that port group, but a NIC can only belong to one virtual switch.
So, if it's unclaimed, it can be assigned to another virtual switch. If it's claimed and unused, it's still claimed by that switch, and so another switch can't claim it.
For your adapters, as it's showing here, you're going to go to the host, you're going to go to Networking, Virtual Switches, select the switch and say Manage Adapters.
So, there is when you'd go and you would claim that adapter. So, in order to do this, you'd have to already have a virtual switch created.
So, I know it says it's Step 1, but it's Step 1 after you've created your switch, and the next step we're going to talk about is creating the switch.
So, you can go to your adapters, you can add an adapter, and then you can set your policy for that adapter.
All right. So, there you're seeing, select your target device. So, we're going to say, are we going to create a new virtual switch, or are we going to use an existing virtual switch?
If we want to just manage the adapter and assign it to a switch, we can then go and say we want to create a virtual switch.
It's like when we create a port group. It can say, do you want to create a new port group for an existing switch, or do you want to create a new switch, right?
Or you can also create that switch in advance. I think most likely you'd create your virtual switch first, get any configuration you want on that, and assign your adapters to that switch with all the configuration for the switch on there.
So, here we're talking about creating a switch. All right. So, here we're going to go into our host, because if we're going to the host and creating a switch, we're creating a standard virtual switch.
We'll talk about distributed virtual switches in a little bit where we'd go into vSphere and create one for the data center.
But right now, we're creating standard virtual switches, which means we're going to the host and then going to their network configuration, and we're creating our virtual switch.
So, we're going to say we're going to configure our networking virtual switches, and then we can add and we can create that switch.
We can go in, we can give it a name, we can assign it a VLAN tag. There's other things we can do as well for a virtual switch, and we'll talk about, like, policies and things like that coming up.
And then we could, you know, finish that. Now, once you have created your virtual switch and probably assigned a physical adapter to it, the next thing you'll probably want to do is create a port group.
And there's a lot of settings, and usually we create port groups if we want to change all these settings.
They can inherit settings from their virtual switch, or you can override certain ones.
So, let's say, for example, for security, we have a standard security policy that we want all of our port groups to use without exception.
We do not allow forged transmit. We do not allow promiscuous mode. We do not allow MAC address spoofing.
We don't allow any of those things, any on our network at all, ever.
So, then I can create that policy on the virtual switch, and all my port groups are going to inherit that, and I just don't override that policy on the port group.
But maybe I am going to change the adapter settings. I'll have some adapters be active, some be standby. They'll be different.
Each port group might have a different VLAN tag on each of them, so that would be different.
So, I can change certain things, and I can leave certain things the same, but the things are going to be the same.
I can set on a switch level and not have to even worry about them on the port group level.
It gets inherited down through all of them. All right.
So, here we're seeing port groups. Now, this is for a VM kernel port.
So, here I can give the VM kernel port a name, and maybe I'm creating this VM kernel port for my vMotion network.
I'm going to have two adapters on my host that I'm dedicating just to vMotion traffic, and I don't want any other traffic on those.
So, I can create a virtual switch for this if I wanted to, and then I can go in and create a VM kernel port on that switch that uses those adapters.
If I am okay with it going over the same network as my virtual machines, not usually considered a best practice,
but if I am okay with that, I can use the same virtual switch that has my virtual machines on it,
and then I can create a VM kernel port on that switch, give it a name.
Maybe in this situation, I'd call it the vMotion, you know, kernel port.
I can give it a VLAN tag. My vMotion network is going to be VLAN 150.
If I'm going to set up IPv4, which I'm sure I will set up IPv4 on there, if I'm going to use a different MTU size.
So, if I change the MTU here, if I don't use the standard default 1,500, I want to go to 9,000 and use jumbo frames instead,
I need to make sure I've enabled jumbo frames on my physical switch as well.
My NIC needs to be, you know, able to accept jumbo frames of 9,000, and my switch port needs to be configured for that as well.
Nowadays, it's pretty common where people go in there and they'll set the MTU on all their switch ports to like 9,100 or something like that,
and that way they can enable jumbo frames when they need to, when it's appropriate for them.
Then I'm going to have to say what services for this VM kernel port I want to use.
If I don't check any of these boxes, then this VM kernel port is just a management VM kernel port.
I can use it to manage the host. I can use it to connect to vSphere, or I can connect to that IP address and manage the host directly.
If I want to use it for something else, like say, for example, for vMotion, then I'm going to check that vMotion box, and now I can use it for vMotion.
If I want to use it for fault-tolerant VMs, right, for the machines that manage fault-tolerant VMs across the host, then I could check fault-tolerant logging, things like that, okay?
So, you'll have to go in there and enable the services. vSAN, obviously, another one that's really common that probably gets checked quite a bit.
So, it depends on what services you're using for that kernel port, you can configure it here.
So, this is how you would also create a VM kernel port just for vMotion, and you might create another one just for vSAN.
And if you have iSCSI, then you would create a VM kernel port for iSCSI and assign that VM kernel port to your iSCSI software initiator, all right?
So, we'll cover that when we get, you know, further into this lessons, but you'll see coming up, you can create different types of VM kernel ports based upon different services you want to use those kernel ports for.
So, adding a VM kernel port, so after you've, you know, you have a switch, you have the switch configured you want.
So, if we're going to, in the example I just mentioned, if we want to have an iSCSI network with iSCSI adapters that are dedicated just for iSCSI, maybe you have a SmartNIC that has iSCSI offloading.
And so, for those SmartNICs that have the iSCSI offloading, you want those dedicated to your iSCSI network, create a virtual switch, assign those two adapters to that virtual switch, create a VM kernel port on that virtual switch, okay?
So, in here you see all the steps, you know, there's add networking, choose an adapter, select the switch, add your VLAN tag, set your IP address.
If you're going to change the MTU, change all that stuff, right, choose what service you want, and then next and finish and review.
So, all the things we saw in that last slide.
So, here's going just to a quick demo of a, just like a standard virtual switch on an ESXi host.
All right, here we are in our vSphere environment, and I'm going to go ahead and go to my Houston data center, and I have my prod cluster, and I have a host in my prod cluster, and one place that we can go to look at our networking is we can just go to networks.
And from here, I can see I have a port group called VM networks, just on a standard, you know, network type, but what I want to do, here's just showing the vCenter server is on there.
What I want to do is I want to go to configure, and under networking, I have my virtual switches.
And here I can see I do have virtual switch zero, which has my management VLAN with a VM kernel port.
I got my VM network.
I've got a vMotion network with another VM kernel port, and I've got another switch, which I have, I call my storage switch.
And I have an iSCSI VM kernel port on this storage switch, right?
So, for this demo, let's just go ahead, and we're going to say we want to add networking.
And I'm just going to create a virtual machine port group for a standard switch, and I can say I want to create a new standard switch, and I can set the MTU size.
If I wanted to use jumbo frames, I would change this to 9,000, but I'll go ahead and leave it on the standard 1,500.
Do I want to use any unclaimed adapters right now?
Here's the unclaimed.
Are there any active ones set on here?
Nothing like that.
All right.
I can go ahead and click on this adapter and say move it down.
That would be unused.
Or I can leave it under unclaimed.
The reason why I might create a switch and not assign an adapter to it, that would create what's called an internal-only virtual network.
And an internal-only virtual network, what that means is VMs on this host specifically that are connected to this switch or to port groups on this switch can all talk to each other, but they can't talk outside of that network, only to each other.
All right?
So, I might leave it unclaimed and say next.
I'm going to say no active adapters, okay.
Do I want to give this a label?
Maybe I'll go in there and just call this Demo 1.
Maybe I'll put a VLAN tag on here if I want to.
Maybe I'll put this on VLAN 200.
Say next.
Now, if I'm doing an internal-only virtual switch, you know, I'm using that going forward that way, I really don't need a VLAN tag.
I can leave a no VLAN tag on there if I wanted to.
I can say finish.
And let's see.
So, update network configuration.
That says that's completed.
Oh, there.
Down there.
I didn't scroll far enough.
So, here is that new switch 1 that I created.
And notice there's no adapters on this.
So, if I wanted to, I could go in and say I want to manage physical adapters.
I could choose that unclaimed NIC that's on there.
I can see the status on there, speed, and all that kind of good stuff.
All right?
I'm going to go ahead and say choose that adapter.
I'm going to move it down to my active adapters.
I can say okay to that.
And now I do have an active adapter on there.
So, if I go down to my physical adapters here, I can see all the different adapters I have configured on this guy.
Now, I added some more adapters real quick behind the scenes, a little virtualization magic, to this virtual host.
Right?
So, we had adapters 0 through 3, and I've added 4, 5, 6, and 7.
So, now I can go back to my virtual switch, this guy here.
I can say I want to manage physical adapters.
Notice I have 4, 5, 6, and 7 unclaimed, and 2 is the active one that I chose during my setup.
I'm going to go ahead and move that up to unclaimed.
I'm going to move 4 down to standby.
5.
I had too many things selected.
My apologies.
Let me fix this real quick and move that back up.
All right.
Let me move 4, get rid of 2, move down, standby, and 5 down to 6 and 7, not 4, just 6 and 7.
Move those down.
So, now I have 6 and 7 active, and I have 4 and 5 are my standby for that particular switch.
And notice that you see all the adapters here.
So, now what I want to do is I want to create a port group on this switch.
So, I'm going to say add networking, and I'm going to create a port group, and I'm going
to create a port group on that new switch I just created, and I'm going to call this
port group test port group 1.
Maybe I'll add a VLAN tag to it.
I'll add VLAN tag.
If I can get this selected here, 210.
Next, and I'm going to complete that.
And I'm going to create another port group.
Again, select an existing switch, test port group instead of 01.
I want it to be 02, and I'll make it be 220 for that VLAN tag.
Next, and finish.
So, what I want to show you is between these two port groups, I have these four NICs selected,
and I said 6 and 7 were my active, 4 and 5 are my standby.
If I look at demo 1, view its settings, and I look at my failover, I can see my active
are 6 and 7, and my standbys are 4 and 5, which is what my switch is configured for,
and so my demo port group inherited those settings, right?
Here, I want to go in, and I want to edit settings, and I'm going to go to traffic shaping,
or no, sorry, teaming and failover, and I see that I have the same thing.
My standbys are 4 and 5, and my actives are 6 and 7.
Now, what I can do is say I want to override the failover order.
So, this is the failover order it inherited from my switch, but for this port group,
I actually want to move 6 and 7 down, and I want to move 4 and 5 to be active.
So, they're the exact opposite.
So, what happens is for one port group, the traffic's going over 6 and 7, and for the
other port group, traffic's going over 4 and 5, and if everything's healthy and everything's
good and everyone's happy, then these adapters are used by certain machines, and these ones
are used by the other machines on the other port group.
But what happens if I have a failure?
What happens if NICs 4 or 5 were to fail?
Well, what happened is NIC 6 could take over if one failed, and then 7 could take over
if another one failed, and now all the traffic for both port groups are going over these
two NICs, but traffic's still flowing.
If they're all up, I have traffic divided across the different port groups, and I have
this good even division of network traffic, but I don't have to survive a failure happen
and all of a sudden VMs are going down if other physical adapters are still up.
So, I can say okay to that, and now the port group settings are different right between
those two.
I can go to port group test 2 and edit its settings, and again, I can go to failover.
I can override that, and what I could do is something completely different.
I could say I want 7 to be standby, and I want 5 to be active.
Whoops, did that again.
Down, down.
I want 5 to be active with 6, and I want 4 and 7 to be my standby.
Now, here it's saying that 7 would be used first and then 4, but if I want that not to
be so, I just move it down, or if I don't want 7 to ever back up on this particular
port group for some reason, I can just call it unused.
It's still claimed by the switch, right?
The virtual switch is still using it, but it's not being used by this port group at
all, okay?
And I can say okay to that.
So, now the only thing I've changed are the active adapters on this particular port group,
right?
I could set other options.
For example, I could go to edit settings.
I have my VLAN tag already set.
Now, for security, do I want to allow promiscuous mode, which means all the traffic is going
to be sent over to this port group, all layer 2 traffic.
Right now, it's set to inherit it because override is not selected, so it's inheriting
it from the switch, and the switch is saying to reject this, accept, accept, right?
But I could go in and say MAC address changes.
What MAC address changes means is that are we going to allow the virtual machine to change
the MAC address of it?
Can we use software to change this MAC address?
Forge transmit means that I can actually send packets using MAC addresses other than the
ones that are configured for my virtual machine in its settings in its BMX file, all right?
All right.
So, I could say, yeah, override that, and I want it to reject, reject.
So, I have this locked down security for these particular – for this port group for these
security settings.
Traffic shaping, are we going to configure traffic shaping or not, right?
Right now, it's currently disabled, but I could go in there and enable if I chose to,
right?
So, I can go in on a port group by port group level.
I can choose what adapters I want them to use in what order for failover.
I can configure traffic shaping on the port group level, security on the port group level,
and the basic properties for, you know, for example, my VLAN tags, right?
And I can say okay to that.
So, this port group has different network adapter settings and security settings than
these two, and these two have the same security settings as the switch, but different adapter
settings than each other.
This one is getting it from the switch.
This guy inherited theirs, right?
So, this is a quick little example of how virtual switches can be configured that way.
The other thing we can quickly do is we can create a VMkernel port as well.
So, this VMkernel port, I can go in and I'll say add networking, and I'll create a VMkernel
adapter and select a target.
I can say I want to select an existing switch, my switch one I have created here.
Say next.
The name of it, demo01.
Do I want to add a VLAN to this?
Yeah, I'll just use VLAN 230 for this one.
Do I want to change the MTU?
TCP-IP stack, right?
What kind of options I want to set on here, right?
I can create a custom one.
I can create custom IP settings on this one.
I can say am I using it for vMotion, for vSAN, for management?
What am I using this for, right?
Here, I'll just say I'm using it for vMotion, right?
I think I already have one configured for that, so I'm going to create another one.
Next, I'm going to my IPv4 settings, static.
I'm just going to say 10.10.10.11, 255.255.255.0, my gateway.
Now, if I don't select this right here, it will use the default gateway that's
configured by default on my original VMkernel port or it has a gateway on there,
or I could give it another gateway that's on this network here.
I'm going to just go ahead and leave it the way it is so that way
router check would go through that interface.
Because for my vMotion network, it's not going to go outside this network anyway.
Now, if I was doing, like, metro, like, long-range vMotions and things like that,
I'd probably put a gateway on there.
And finish.
And this is going to go through.
It went through actually really quick.
If I wanted to, like, see what's going on, I could see here, oh, look,
except that virtual NIC, no problem.
Got my VMkernel port configured on my virtual switch, on my virtual switch here.
I have my port groups, and here's my new VMkernel demo.
So, I've created a VMkernel port.
I've created a virtual switch.
I've managed my physical adapters.
Okay.
I've pretty much done everything that we can, you know,
do here on these standard virtual switches.
Not a lot of settings, but there's plenty of settings, you know,
for a standard switch, a lot to remember.
So, that was a standard virtual switch.
Next, we're going to discuss distributed switches
or distributed virtual switches.
A distributed virtual switch is not created on a host-by-host basis.
We create a distributed virtual switch on our data center,
and then we can assign it to hosts within that data center.
And from there, we can assign options to that distributed virtual switch.
We can assign a VLAN tag.
We can do all the same things we did on a standard switch.
We can set our security.
We can set our load balancing and our failover policies
and our MTU size and all that kind of stuff.
We can also create port groups on a distributed virtual switch,
and we can assign different adapter settings, different failover,
different active standby, different security settings.
You'll see there's also more advanced options we'll get into
for distributed virtual switches as well.
And we can set all that up on the distributed virtual switch.
Then we can assign it to a host.
Now, I might say on my distributed virtual switch
that I want it to have four uplinks.
And we don't assign physical adapters to that distributed virtual switch.
When we create it, we say how many uplinks we want it to have.
Then when we assign it to a host, we say on that host that we want you
to use adapters 1, 2, 3, and 4.
Or we can say 4, 5, 6, and 7, or whatever it is.
We can choose whatever adapters.
And we can say I want adapter 4 to go to uplink 1,
and adapter 5 to go to uplink 2,
and adapter 6 to go to uplink 3, and things like that, obviously.
And so now I have assigned physical adapters to the uplinks
on that distributed virtual switch.
I said what NIC goes to what uplink.
And the reason why you might want to do that is maybe for some reason
this is not probable, but maybe like adapter 4 is a 1 gig,
and the other three are 10 gigs.
So I want adapter 4 to always go to uplink 1,
because uplink 1 is going to go to a VM kernel port that is just going to
use that 1 gig connection, and it's just for simple management,
and that 1 gig connection is fine.
And then the other three uplinks are my 10 gigs, or 25 gigs.
25 is getting really common now on your ESXi hosts,
are these 25 gig uplinks.
And so I want to know which one is my 1 gig and which ones are my 25 gigs,
because that uplink is going to only be attached to that VM kernel port,
and then the other three are going to be for VMs
or for whatever you're going to be using them for, right?
So by knowing what physical NIC on the host I've assigned to the uplink,
I now know my configuration will be valid across all of them.
If I were to say just these four NICs and they land wherever they happen
to land, then maybe my 25 gig is going to that VM kernel port,
and that 1 gig is used for VMware traffic or something like that.
Obviously, that would be a horrible thing.
So by being able to assign an adapter to a specific uplink,
and then that specific uplink is going to be used for my adapter policies,
for my load balancing and my failover order and all that kind of stuff,
I now know that my configuration is going to be valid
across my infrastructure, okay?
And I don't have to reconfigure it again over and over and over
and over and over across 25, 30, 40 hosts.
I only have to configure it once and then assign it to the host,
choose my adapters to my uplink mapping, and I'm done.
So let's go ahead and take a look at this.
So distributed virtual switches created off the data center level.
We go to our vSphere client, and we're going to go into there,
and we're going to build the distributed virtual switch,
and we're going to map it to our host.
We allow folks to create configurations that are going to be assigned
to multiple hosts and not have to reconfigure them every single time
and worry about things like typos and things like that.
One point for management, if down the road, let's say in a year,
all of a sudden I need another VLAN in my vSphere environment,
I can go to my distributed virtual switch,
I can create a new port group on that switch, assign it a new VLAN,
and all my hosts are going to get that new port group with that new VLAN.
Then I need to edit my virtual machines
and tell them to use that new port group that I just now pushed out,
or maybe it's not changing VNs, maybe I'm going to add a new group of VNs.
I'm deploying a new security appliance that needs its own VLAN.
So I'm going to map it to that when I deploy it.
So here we're seeing the distributed virtual switch architecture.
What we're seeing on the far left,
we have a host that at the top has a distributed virtual switch,
and below that it has a regular standard virtual switch.
We call it a host switch here.
And that distributed virtual switch is going to be mapped to a certain adapter
on the host that goes to the switch.
Now in the middle we also see a host that has a host switch only.
Now that host with a host switch only is not using that distributed virtual switch.
And then the last host only has a distributed virtual switch.
So you can see you can use distributed virtual switches exclusively on a host
or you can mix them with standard virtual switches on a host.
So the created distributed virtual switch is basically pretty easy to do,
but there are a lot of questions,
and you want to be really careful when you do it that you're basically the
biggest challenge or the thing you need to be most careful about,
it's not really a challenge,
is choosing the host when you apply it to the host,
making sure you choose the right adapters.
You don't want to choose the wrong adapters or the wrong configuration
or something like that.
You want to make sure you get this all configured correctly.
So here we can go into our data center,
distribute switches and create a new distributed switch.
We're going to give it a name.
We're going to set a location for the distributed virtual switch,
and we'll see there's a bunch of options we can start configuring.
So when you are creating new distributed virtual switches,
this is not software that gets installed on a host.
It's integrated into the ESXi operating system.
And because it is integrated with the ESXi operating system,
different versions of ESXi may have different versions of distributed
virtual switches.
So if when I create this,
I say I want to create a distributed virtual switch that's compatible with
ESXi 8 and I have hosts that are running 7 or, you know,
some older version, 7 update 3 or, you know, 6.5 maybe,
that distributed virtual switch won't be compatible with those older
versions of ESXi.
If I know my entire infrastructure or at least everything in this data
center is all going to be 8, then I can choose 8.
But if I know I have to be compatible with some older hosts,
I would need to choose a version that's compatible with that older
host.
And then that older version might have limitations on features or,
you know, the size it can grow to and things like that.
Right?
So I'm going to choose a version.
Then I'm going to say how many ports do I want it to use?
Now it's possible that we want it to be a set physical size and it's
going to be, you know, 48 ports or whatever we're going to choose,
a number.
We can also set it to be an initial size of, say,
let's say, for example, 8.
But we want to be able to grow as needed.
If you choose a switch that can, you know,
expand and grow as needed and you set a number of ports on it,
say, for example, 8, every time it grows, it'll grow by 8.
If I set 24, every time it grows, it grows by 24.
So you probably want to choose a relatively smallish number, like,
you know, 8 is probably a pretty decent number, 12,
something like that, so that when it grows,
it doesn't grow in huge increments.
And I only needed one more port and I got 24 more ports.
I got 48 more ports.
I only needed one and I got 12.
So that gives me some room to add some more VMs to this switch on this
host as needed, right?
So how many ports do we want to use?
Are we going to enable I-O control?
So basically I-O control will allow us to prioritize traffic,
and we're going to say basically that certain port groups can't overrun
other port groups.
We can, you know, set up how much I-O is going to be allowed to be used.
We can put a limit on there.
We can say that we want to basically do it based on shares,
and we can say that as long as there's no contention,
use what you want.
But if there is contention, it's divided 50-50.
Or if there's contention, this one gets 60 and that one gets 40,
things like that.
You can set basically the amount of access that can be used for I-O.
And you'll probably want to create a default port group, right?
And, of course, port groups require a name.
So location of the distributed virtual switch,
the distributed virtual switch port groups,
the name of the port group,
and you're going to select the distributed virtual switch to put the port
group on when you create that port group.
So set bindings, static bindings of port to virtual machine mapping.
So what that means is that when a VM is connecting to the virtual switch,
if it gets connected to port 8, it's always going to use port 8.
If you shut down the VM and you restart it up a week later,
it goes to port 8.
Ephemeral means there's no binding.
So when you start it up, it goes to port 8.
You shut it down, another machine takes port 8.
And when it starts back up again, it says, oh, I'm going to take port 6
or I'm going to take port 9, whatever's available.
So ephemeral, there's no binding from VM to port,
and with static bindings,
that VM is going to always attach to the same port on the virtual switch.
So port allocation, elastic means there's no set certain size for the
virtual switch.
That's when we're talking about if you said the switch, you know,
it's going to be elastic and we're going to create it with 24 ports.
When it fills up the 24 ports, it adds 24 more.
If I had said 8, when it fills up 8, it'll add 8 more.
So you probably want to choose a smaller number
and let it grow in smaller increments, but not ridiculous.
You don't want to make it too small where it's growing constantly.
You want it to grow occasionally when needed.
So 8 or 12 or something like that might be a good start.
In the beginning, it might grow several times,
but then it'll kind of settle into a rhythm
and you won't have to keep growing it all the time.
Fixed means it's 48 ports, always going to be 48 ports,
it'll never be more than 48 ports, right,
or 24 or 80 or whatever number you choose.
So how many ports do you need, right?
That's one that we just discussed.
Network resource pool, you can assign a network resource pool
to the port group or distributed virtual switch.
So basically when you assign it to a port group on a distributed virtual
switch, you can specify a maximum amount of bandwidth it uses.
You can say it's unlimited, you can use as much as you need,
or you can put a cap on there and say the maximum it can use is
1,000 megabits, right?
If you've got a 10-gig NIC and you give it 1,000 megabits,
it's got a gig, but it can't exceed that ever, all right?
The other things on your resource pool you can say are shares.
So you can say this resource pool has got 100 shares
but its usage is unlimited.
What that means is it can use all it wants if there's no contention for
the resource.
If there's contention for the resource,
what's going to happen is they'll look at the shares and say, oh,
100 and 100, so it's 50-50.
If one port group has 10 VMs in it, it gets half the bandwidth.
If the other port group has 30 VMs in it, three times more,
but the same number of shares,
those 30 VMs have the same amount of bandwidth that share amongst them,
as those 10 have, right?
So obviously the 10 have a lot more bandwidth.
You could also go in and say that the one with 30 VMs has 300 shares,
and then the one with 10 VMs only has 100 shares, right?
So that way the VMs would kind of be more equal.
But then, of course, if you take away VMs or add VMs,
it starts to change, the map changes again.
But you can assign a port group more shares,
giving it access to more bandwidth.
Now, that bandwidth is only up to its cap.
So if you put a limit on there of, say, you know, 5,000 megabits a second,
when it hits that 5,000, it will never be able to exceed it,
even if it's available, even if there's no contention.
No one else is using that adapter for anything.
There's 5,000 megabits still available.
When you hit that limit, it's a limit you can't exceed it.
So just be careful of that.
Limits are useful.
There's reasons to use them, but you don't use them all the time
because you don't want to be wasting resources that could be used for something.
An example when you probably would use something like a limit is,
let's say you're a cloud provider and you're reselling a resource,
and a customer is paying for a certain amount of bandwidth.
You put a cap on there, you put a limit on there,
and don't let them exceed that because they're not paying for more than that.
It's available.
You have it available to them.
But if you let them use it and then later on you take it away because now you
added more customers and so now you get to enforce your limits,
you add a limit on there, now they're going to see their performance
degradate and they're going to complain.
And also you're hurting your own revenue because they're not paying for more
than that, so why would you give them more than that?
If they need more, they should pay you for more.
So VLAN types, you can say there's no VLAN configured.
We are going to add a VLAN, so then, of course,
it's going to put a VLAN tag on there.
VLAN trunking is exactly like what it would be if you were on a switch.
So maybe on a switch you have the physical interface and the switch says,
I'm going to allow VLANs, you know, 10, 20, 30, and 40.
On a port group, you might just say this port group is VLAN 20
and the next one is VLAN 30.
But the next one might be 40 and 50 or 40 through 50 or something like that.
Now, of course, 40 through 50 would have to be enabled on your switch.
And the reason why you might do that on a port group is because you might have
VMs in there that are able to assign their own VLAN tags.
Like a Windows VM doesn't usually do that.
Linux VMs don't usually do that.
Macs aren't usually VMs, but they don't usually do that either.
But certain types of appliances might be able to do that.
They might be configured to assign their own VLAN tag.
And if they are, then you can just put them into a port group if you want them
to share that, and you can trunk multiple VLANs.
Let me use an application.
And one part of the application uses VLAN 31.
The other part of the application is on VLAN 32.
You can put them on the same port group,
and then you can trunk both those VLANs to that port group.
A private VLAN is a little bit kind of different.
So a private VLAN is that there's ports on your virtual switch,
and a device on port one cannot talk to a device on port two
or a device on port three on that same private VLAN.
They can only talk to what would be an uplink port or a link port.
That port might then connect out to the Internet only.
So what you just did is you created a bunch of a network
with a bunch of machines on there.
It would be virtual machines or if this is in your physical environment,
physical, you know, machines on a private VLAN.
In this case, virtual machines that are all on the same VLAN,
on the same virtual switch, that can only talk to out to the Internet.
They cannot talk and see each other.
All right?
So if you want to create some kind of security rule like that,
you could do that with a private VLAN.
It's kind of like what you see a lot of times on Wi-Fi, on guest networks,
where the guest network will let, you know,
your phone connect to the Wi-Fi and then get up to the Internet,
but you can't see the guy sitting next to you who's on the same Wi-Fi,
on the same SSID.
It's kind of like that.
So security for port groups.
We have promiscuous mode, MAC address changes, and forged transmit.
Promiscuous mode means that if you have set to accept,
that it's going to allow all the different traffic,
even if it's not destined to your MAC address, to come in on that port.
So if you were running some kind of a network monitoring tool
or something like that,
you would probably enable promiscuous mode on there.
If you have set to reject, then that's rejected.
So MAC address changes means the guest OS can change its MAC address,
right,
and send out packets on the network with a different MAC address than what
it's configured for.
Reject means that it can't.
Forged transmit means all outbound frames are allowed by the switch,
regardless of what MAC address they're using.
So they can actually use a whole bunch of different MAC addresses.
They're forging a whole bunch of different MACs and sending them out,
whereas the guest OS is saying, this is my MAC address.
But the guest OS MAC address is different than what's in the VMX file.
That's the configuration file for that VM.
The VMX file says one thing.
The guest OS is saying, nope, my MAC address is this.
That's a MAC address change.
Forged transmit means that it's just putting in different MAC addresses,
the application is, and sending those out.
And it could be the same one over and over or a bunch of different ones.
Traffic shaping.
So basically what you're doing with traffic shaping is you're saying how
much traffic you're allowed to use.
You can say the average over time needs to be this.
You're allowed to peak, right, because here's the most that you can use.
A burst means you can go even higher, but it can't exceed the average.
So you can say the average is this, but the peak could be this.
A burst could be even higher.
But none of these can exceed what your average is, right?
So if your average has to be 1,000 megabits,
maybe your peak would be 1,500.
But you can't peak to 1,500 for so long that you exceed your average over
time, and you can't burst, which means like a spike and back down, again,
that would exceed your average.
So all those have to be enforced, all right?
So each port receives traffic shaping policies individually.
What that means is that when you set a traffic shaping policy,
it's on a port-by-port basis.
That is assigned to the port.
So you're saying what the average, what the peak,
and what the burst is for a VM on a port,
not for all the VMs on the port group.
So a 10-minute failover, we discussed this actually quite a bit already,
right, but it basically allows the traffic to be shared across the adapters
that are assigned to the virtual switch or to the port group.
What happens if an adapter fails?
Is there a failover order?
Do you have ones reserved for failover?
And so how do you configure this?
It's if you're teaming in your failover options, right?
So load balancing.
So your load balancing is saying,
if I have more than one adapter selected as my active adapter,
how is traffic divided across those adapters?
First of all, a VM is only going to use one adapter.
It's not going to send traffic from a single VM across multiple adapters.
It's only going to use one adapter.
So how do I know what adapter it's going to use?
So you have different options.
You have an IP hash where it just hashes the IP address of the VM,
assigns it to a port.
There is a source MAC address hash, right?
Physical NIC load,
that actually is going to only be done on a distributed virtual switch.
That is not an option on a standard switch, okay?
And then you also have your explicit failover.
So if one adapter were to fail, which one becomes next in that load?
And then the hash has to be redone to use that new adapter.
You wouldn't have to redo the hash, actually.
Just all the ones that were going to the failed adapter would go to the
new replacement adapter.
So I slightly misspoke there.
Failure detection.
How do we know if an adapter fails?
How do we know an adapter fails?
And I need to take that one out and put a standby in its place.
There's two different options.
One is link status, which means if the adapter goes dark,
if the little link light on there were to go out, that adapter is down.
But what happens if, for example, the switch it's connected to shows up,
but it can't connect to anything else past that switch?
You could use beaconing for that.
So if this adapter can still talk to it, you know,
the adapter is able to get sent out traffic and it's seen by other hosts
or by other adapters, then everything's good.
But if I can't see anything else, I see a link light on,
but I can't see any traffic from my beacons, then I consider it down.
Most people do link status.
They don't do the beaconing.
They just do link status.
If you're doing an IP hash, then you don't use beaconing.
You just use link status.
So what happens if a adapter were to fail?
So I have my link status.
The link light goes out.
The adapter goes down.
I see the adapter status is down.
I take it out of my active.
I put a standby adapter in its place.
What do I do now?
Well, most of the time, you're going to want to say you want to notify
your switches.
You want to check the box that says notify switches.
Because what will happen is by notifying the switches,
what it does is it sends a packet out with the MAC address of all the VMs
that were using that adapter.
So the switch says, oh, because think about it,
the adapter that failed was on interface one.
The one that took its place is on interface five.
You don't want the switch to keep sending traffic to interface one or to
say, oh, interface one went down.
I don't know where those MACs are anymore.
You put interface, you know, two in its place,
attach it to interface five on the switch,
and then the host is going to send out packets using the MAC address for
the source MAC address for the VMs, one for, you know, all the VMs.
So if you have 30 VMs on there,
it sends out 30 packets for those different VMs to interface five on that
switch.
Now the switch just learned where those VMs are and how to get back to
that.
So you probably want to notify your switches most of the time.
It's not very often there will be a reason not,
so you don't want to do that.
Failed back.
So my NIC one goes down, five takes over.
And then my interface two comes back up again.
What do I do?
Do I fail back, meaning put five back in my standby and two back in my
active, or does two become my new standby?
That's kind of up to you.
People sometimes will say, yes,
fail back because they want to have a predictive setup.
They want to know one and two are always my active and three and four are
always my standby.
And so if two goes down, it fails over to three.
But when two comes back, because I got an alert and I fixed the problem,
I know one and two are active again.
So if I want to know a predictive setup for all my hosts,
you might want to fail back.
And if you fail back, what's going to do,
it's going to send out packets again from those VMs on that adapter to,
to whatever interface on the switch is plugged into the switch changes,
it's Mac address table and start sending traffic over there.
You may not want to fail back because that predictive,
knowing the configuration isn't as important to you as just a stable
environment.
I don't want it to be flapping back and forth and changing back and forth.
Just if it's working, leave it alone.
I'm fine with two being my standby.
I know that my active adapters are going to be one and two or three and
four.
It's going to be one of them.
I'm fine with it being whichever ones it is,
as long as I know it's one of these four, that kind of thing.
Fail over order.
You can set, as we discussed in our last demo, which ones are my active,
which ones are standby and which ones are not used at all.
I can set adapters to also just not be used on a port group.
They're on the switch, but they're not on the port group.
So NetFlow,
NetFlow is we can configure NetFlow on a distributed virtual switch.
And basically what it does is it sends layer three traffic from a switch
to a NetFlow appliance.
So setting up a NetFlow appliance is a whole separate outside of,
you know, a vSphere configuration.
It could be a VM, but it's not a vSphere configuration.
You set up a NetFlow server,
and then you can configure this port group to use that particular NetFlow
server.
And it sends information,
samplings to that NetFlow server to give you information about your
network, okay?
And block ports.
You can say you want to block all the ports or block none.
So you might just want to block, you know,
bring down that virtual switch for a moment without actually unplugging
things or anything like that.
You can block all the ports.
And then when you're done doing your maintenance,
you can unblock them.
So verify.
Once you have, you know, done a configuration,
if you go to your host, like, well, it's not there.
I don't see it.
Go to your tasks.
You'll see at the bottom of your vSphere client that when you say okay
to something, it creates a task.
It shows you the progress of that task.
Maybe it hasn't completed yet.
Deploying a new virtual switch to hosts can be somewhat time consuming,
especially if you did quite a few.
And so it could take a little bit.
So just watch the task, wait for it to complete completely.
Then you can go to the host and refresh,
and you should see all the changes there, okay?
Check the ports on your switch.
If you are using distributed virtual switches,
and if you configured things like lags and things like that,
you need to configure your switch to also use those lags.
A standard switch cannot do a dynamic lag.
A standard switch is going to do what's called a static lag.
A distributed virtual switch can do either a static lag
or an LACP dynamic lag.
So however you have your virtual switches configured,
make sure that your ports on your physical switch match that configuration.
Same thing with VLANs.
Make sure all your VLANs that you configured on your port groups
and things are tagged on the switch itself, the physical switch.
So in conclusion, we discussed standard virtual switches,
and we discussed distributed virtual switches.
Before we wrap up this lesson,
let's go ahead and go back to our demo environment,
and I'll show you how to set up and configure a distributed virtual switch.
So here we are back in our demo environment.
We have our Houston data center.
We have our production cluster here, and I've got a couple of hosts in here,
and these hosts have some unused unclaimed adapters on both these hosts.
One thing that's really cool, I can point out here too,
switch nothing claimed here also,
is notice that, like, for example, when I was here
and I went to adapters and showed you, when I click on the other host,
I stayed on that same screen.
It didn't take me, for example, to the summary screen right away, right?
So if I go to this host now, notice when I stayed on my summary screen,
I didn't jump back to where I was last in this host.
It took me to wherever I was.
It makes it really easy if I'm trying to configure certain things on multiple
hosts to say I want to look at virtual switches.
Okay, I see this.
Let me compare it to this guy here and take me to the same spot on that host.
That's a really cool feature that I really like.
So from here I'm going to go to my networking option in vSphere.
I have my Houston data center, right,
and I can see the networks that are configured on there.
So here I want to say I want to create a distributed switch,
and I want to create a new distributed virtual switch.
I'm going to give it a name.
I'm going to call this distributed virtual switch,
and I'm going to put it in that data center.
Now, this is where you choose the version.
I know all my hosts are going to be eight, so I can say eight or later.
If I knew I had some seven update three hosts still in my environment
or later, then I might choose that option, right?
So I'm going to go ahead and choose eight.
I got all version eight hosts in this environment.
I'm going to say next.
So are we doing the offload capabilities?
So what that basically means is do we have a smart NICs?
Do we have, like, you know,
NICs that are able to do ISCSI offloading or TCP offloading or, you know,
SSL offloading, that kind of thing.
I'm going to say none.
Number of uplink ports, I'll do four.
Network IDLE control, you can enable it or not.
That's an option for you
if you're going to be using the network IDLE control or not.
If you're not, you can go ahead and turn it off.
Do you want to create that default port group?
I'm going to go ahead and uncheck that and just go ahead
and we'll create one after we're done.
And I'll say next.
And it's all set.
It's going to go ahead and create my distributed virtual switch.
And that happened actually really fast.
So from here, I have that DemoDB uplink port group there, our uplink group.
I'm going to go in and say I want to create a distributed port group, right,
a new distributed port group.
So this will be my port group,
and I'll just call it a distributed port group demo.
I'm going to put it on that demo distributed virtual switch.
Now, here are all the settings we talked about in our lesson.
All right, do we want to do port bindings, right, ephemeral, no binding?
That's usually fine.
You can say static if you wanted to, right.
If you're going to say you want it to be bound, elastic, what size,
notice they give you a really small number to start.
If you're just going to say it's going to be a fixed size, then it says,
well, then you might want to choose a lot of ports.
But if you're going to say it's elastic so it can grow,
you start with a small number of ports,
and that's the increment in which it's going to grow in, okay.
Are we going to do a network resource pool?
I'm not going to assign a network resource pool.
I don't want to, you know, limit the amount of IO it's going to use
and things like that.
VLAN, now here you might choose a VLAN that you've configured before
in a distributed switch, a standard distributed switch,
and now we're going to migrate this to this distributed virtual switch
from a standard switch, right.
Do you want to customize any of these other policies that we talked about?
Do you want to do, you know, security settings
and, you know, MAC address spoofing, that kind of thing?
Right now we just go ahead and say next and finish.
And there is my port group.
I can say edit settings here.
I can look at my teaming and failover to have my uplinks,
and here it's showing that all my uplinks on this group are active.
I can choose, you know, three and four, move those down, they're standby.
I can create another port group and make three and four my active
and one and two standby for that one, just like we did on the standard switch.
I'll say next.
It's okay there.
Now I reconfigured that, and that's completed successfully.
So now what I can do, I can add VM kernel adapters to here if I wanted to.
I can migrate VMs to this port group that are on, you know,
other configurations, other standard switches.
On the standard switch itself, I can do that.
On the standard switch itself, I can say add managed hosts.
So I'm going to add hosts.
Managed hosts need to be changing settings for hosts that are already here.
I have no hosts here yet, so I'm just going to add some hosts.
I'm going to add these two hosts.
Which adapters do I want to use?
I'm going to say I want four to go to uplink one, five to go to uplink two,
six to go to uplink three, and seven to go to uplink four, right?
And that's because my adapter started at zero.
So I have eight on here, and zero is the first one,
one is the second one, and so forth.
So four is actually five, six, seven, and eight.
So uplinks one, two, three, and four.
I'm going to say next.
And are we going to move any VM kernel ports?
I don't have to move any of these, right?
I can leave them on the standard switches they're on, and that will work fine.
If I wanted to create a VM kernel port on my distributed virtual switch
and assign it somewhere, I could do that.
If I wanted to migrate virtual machines that were on the standard switch to
over to my kernel, my port groups on this switch, I could do that as well.
But we're not going to migrate any of the VMs.
And we can say finish.
So we're reconfiguring the vSphere distributed switch, right?
We're adding the host, and that completed.
So if I go back to my host, and if I were to look at virtual switches,
now you see I have the distributed virtual switch here, right?
I have the distributed virtual switch.
I have my uplinks on there, all configured, right?
So that's pretty cool, right?
I was able to deploy a switch to a host, right?
Same thing here.
I deployed this switch to this host.
It's got the uplinks all configured on there, and it's all ready to go.
So that's pretty exciting.