WEBVTT

0:00:02.960000 --> 0:00:07.640000
 Hello and welcome to this video titled Virtualization
 Networking and Management

0:00:07.640000 --> 0:00:14.000000
 Considerations. In this video we're going
 to talk about some considerations

0:00:14.000000 --> 0:00:17.420000
 you have to think about when it comes
 to addressing a VM's both with layer

0:00:17.420000 --> 0:00:21.880000
 2 MAC addresses and layer
 3 IP addresses.

0:00:21.880000 --> 0:00:26.820000
 We'll talk about networking usage considerations
 and things you have to

0:00:26.820000 --> 0:00:29.940000
 think about when monitoring
 your virtual machines.

0:00:29.940000 --> 0:00:34.420000
 So let's start by looking
 at addresses.

0:00:34.420000 --> 0:00:40.440000
 Now if the only way you plan on accessing
 a virtual machine is by logging

0:00:40.440000 --> 0:00:44.380000
 into the hypervisor itself and then
 once you're logged into the GUI of

0:00:44.380000 --> 0:00:48.220000
 the hypervisor accessing the virtual
 machine from in there.

0:00:48.220000 --> 0:00:50.560000
 In other words if that virtual machine's
 not going to talk to anybody

0:00:50.560000 --> 0:00:54.440000
 else, not going to be visible on the
 network, then we could care less

0:00:54.440000 --> 0:00:55.960000
 about addresses.

0:00:55.960000 --> 0:01:00.100000
 But 99% of the time when you create
 a virtual machine it's because you

0:01:00.100000 --> 0:01:05.220000
 want the network and people on the network
 to be able to access that resource.

0:01:05.220000 --> 0:01:08.580000
 So we have to start thinking about things
 like addressing of that virtual

0:01:08.580000 --> 0:01:13.100000
 machine. So each guest operating system,
 regardless of what that guest

0:01:13.100000 --> 0:01:17.640000
 is, whether it be a router, a firewall,
 Windows operating system, whatever

0:01:17.640000 --> 0:01:21.340000
 it is, is going to need some kind of
 an IP address so people can reach

0:01:21.340000 --> 0:01:26.220000
 it. So some things we have to think about
 now when we think about addressing,

0:01:26.220000 --> 0:01:29.680000
 do we want the VMs to have
 a static IP address?

0:01:29.680000 --> 0:01:34.200000
 Now if this VM is going to represent a
 server like a Windows Server instance

0:01:34.200000 --> 0:01:39.180000
 or an Apache Server instance or something
 else, then yes we probably do

0:01:39.180000 --> 0:01:41.660000
 want to give it a
 static IP address.

0:01:41.660000 --> 0:01:45.300000
 Alright, well if we give it a static
 IP address number one, just like

0:01:45.300000 --> 0:01:48.780000
 anything else with a static IP address,
 we want to make sure we select

0:01:48.780000 --> 0:01:52.520000
 an address that's currently unused, we
 don't want to overlap with somebody

0:01:52.520000 --> 0:01:54.380000
 else's static IP address.

0:01:54.380000 --> 0:01:59.080000
 Now something else to think about, that
 host that that VM is sitting on,

0:01:59.080000 --> 0:02:05.180000
 what if that host fails, that host was
 in a cluster and another host takes

0:02:05.180000 --> 0:02:10.420000
 up its job so that VM now has been replicated
 or I should say moved over

0:02:10.420000 --> 0:02:11.800000
 to another host.

0:02:11.800000 --> 0:02:16.120000
 Well if it had a static IP address clearly
 we need that static IP address

0:02:16.120000 --> 0:02:19.900000
 to be preserved when it moves
 over to the next host.

0:02:19.900000 --> 0:02:24.820000
 That might not sound like much of something
 to think about but what if

0:02:24.820000 --> 0:02:28.480000
 that other host was in a
 different data center?

0:02:28.480000 --> 0:02:32.100000
 What if our cluster of hosts were not
 actually physically right next to

0:02:32.100000 --> 0:02:35.860000
 each other but host number one that
 had all these VMs on it was maybe

0:02:35.860000 --> 0:02:41.180000
 in the east section of the building
 when that host fails, host number

0:02:41.180000 --> 0:02:45.340000
 two that takes up all of its VMs and replicates
 them as in the west section

0:02:45.340000 --> 0:02:46.520000
 of the building.

0:02:46.520000 --> 0:02:50.860000
 Okay now there's something to think
 about because previously that VM may

0:02:50.860000 --> 0:02:55.780000
 have had the IP address of
 2.2.2.2 just as an example.

0:02:55.780000 --> 0:03:00.200000
 Now the VM's showing up
 over here as 2.2.2.2.

0:03:00.200000 --> 0:03:03.320000
 Now we have to think about okay it's
 in a completely separate section

0:03:03.320000 --> 0:03:08.240000
 of the building the IP address of that
 static machine has just moved.

0:03:08.240000 --> 0:03:12.140000
 How are the routing tables and our router
 is going to be aware of that?

0:03:12.140000 --> 0:03:15.660000
 Do we have any access list that all of
 a sudden might get screwed up because

0:03:15.660000 --> 0:03:20.480000
 the 2 network was accessible over here
 but it's not accessible over here.

0:03:20.480000 --> 0:03:25.400000
 So if a VM with a static IP address might
 move due to some like redundancy

0:03:25.400000 --> 0:03:29.660000
 or failure we have to consider that
 as well as how is the network going

0:03:29.660000 --> 0:03:31.560000
 to respond to that.

0:03:31.560000 --> 0:03:37.760000
 Now maybe a VM will have a DHCP address
 that's perfectly acceptable for

0:03:37.760000 --> 0:03:47.240000
 example if a VM is or a Microsoft desktop
 VM or a Ubuntu desktop VM it

0:03:47.240000 --> 0:03:51.980000
 would be natural that those things might
 be given an IP address via DHCP.

0:03:51.980000 --> 0:03:55.340000
 Alright well then you have to ask yourself
 alright where is the DHCP server

0:03:55.340000 --> 0:03:59.300000
 going to be located that's going
 to provide that IP address.

0:03:59.300000 --> 0:04:03.020000
 Is it going to get the IP address from
 a real physical DHCP server that's

0:04:03.020000 --> 0:04:07.680000
 in another section of our network or
 do we want to create another virtual

0:04:07.680000 --> 0:04:12.840000
 machine inside this host and that other
 virtual machine will be the DHCP

0:04:12.840000 --> 0:04:16.800000
 server for all these other virtual
 machines that are sitting around it

0:04:16.800000 --> 0:04:19.800000
 that's possible as well.

0:04:19.800000 --> 0:04:24.600000
 Also some Mac address considerations
 a lot of times when a virtual machine

0:04:24.600000 --> 0:04:30.160000
 spins up the hypervisor will dynamically
 allocate it a Mac address it'll

0:04:30.160000 --> 0:04:35.920000
 just pick one from like a pool of Mac addresses
 that came with that hypervisor.

0:04:35.920000 --> 0:04:41.360000
 Well once again if that's the case and
 that VM has a sort of an unpredictable

0:04:41.360000 --> 0:04:48.300000
 Mac address that was just assigned
 to it what if that host fails that

0:04:48.300000 --> 0:04:53.720000
 VM now spins up in a different host
 for redundancy sake what if it now

0:04:53.720000 --> 0:04:57.400000
 has a completely different Mac address
 that could screw up the way people

0:04:57.400000 --> 0:05:01.720000
 access that VM how are they going to
 learn about that Mac address how's

0:05:01.720000 --> 0:05:06.220000
 that going to affect your switching
 tables on the flip side if we decide

0:05:06.220000 --> 0:05:10.760000
 hey I want to give that VM a static
 Mac address I want to program it so

0:05:10.760000 --> 0:05:13.960000
 when I'm creating that VM in the first
 place that's one of the things

0:05:13.960000 --> 0:05:17.120000
 I'm going to do is I'm going to assign
 a static Mac address to it all

0:05:17.120000 --> 0:05:20.660000
 right well that's all well and good
 but once again if that host fails

0:05:20.660000 --> 0:05:25.080000
 and now that VM spins up over here in
 a different section of the network

0:05:25.080000 --> 0:05:29.080000
 is that going to screw up our network
 how are the Mac address tables of

0:05:29.080000 --> 0:05:33.120000
 our various switches going to know that
 that VM has moved from this point

0:05:33.120000 --> 0:05:39.760000
 to this point if we have some security
 in place like port security or

0:05:39.760000 --> 0:05:44.360000
 VLAN access lists or something are we
 now going to have problems because

0:05:44.360000 --> 0:05:48.400000
 our Mac address which was once over
 here has now moved to a completely

0:05:48.400000 --> 0:05:51.800000
 different section of our switch network
 these are all things you have

0:05:51.800000 --> 0:05:55.620000
 to think about when it comes to addressing
 of our VMs how is going to

0:05:55.620000 --> 0:06:01.480000
 interact with the network now speaking
 of the network itself we know that

0:06:01.480000 --> 0:06:05.980000
 all the VMs are going to share the uplink
 of the physical hosts net card

0:06:05.980000 --> 0:06:11.880000
 so it's very possible that we could
 oversubscribe that net card which

0:06:11.880000 --> 0:06:16.740000
 will cause very poor performance on
 the VMs themselves so a VM remember

0:06:16.740000 --> 0:06:22.340000
 a VM does not have visibility to the
 actual real resources in the host

0:06:22.340000 --> 0:06:29.180000
 when you program that VM and you gave
 it a V-NIC it assumed that V-NIC

0:06:29.180000 --> 0:06:34.560000
 was let's say one gigabit but it might
 not be aware that the actual physical

0:06:34.560000 --> 0:06:38.940000
 NIC is completely saturated and then
 the host might just be saying hey

0:06:38.940000 --> 0:06:43.040000
 I'm getting really slow performance
 its V-NIC is fine there's nothing

0:06:43.040000 --> 0:06:47.860000
 wrong with its V-NIC the problem is
 with congestion on the real NIC card

0:06:47.860000 --> 0:06:51.920000
 of the actual host so how many NIC cards
 do we want to give the host two

0:06:51.920000 --> 0:06:56.600000
 three four how many are supported do
 we want to provide fast ethernet

0:06:56.600000 --> 0:07:00.520000
 NIC cards gigabit ten gigabit NIC cards
 we want to make sure that physical

0:07:00.520000 --> 0:07:06.300000
 host has enough actual network bandwidth
 to spread around to all the virtual

0:07:06.300000 --> 0:07:16.120000
 machines sitting inside of it as far as
 VM segmentation's need to be separated

0:07:16.120000 --> 0:07:22.660000
 at layer two we're going to probably utilize
 VLANs for this so the physical

0:07:22.660000 --> 0:07:28.680000
 host uplinks will perform 802.1q trunking
 so as an example maybe I've

0:07:28.680000 --> 0:07:36.020000
 got five VMs which are part of payroll
 so those five VMs are going to

0:07:36.020000 --> 0:07:47.200000
 be in their own subnet either with static
 different subnet than another

0:07:47.200000 --> 0:07:51.700000
 five VMs owned by engineering we're
 going to want to sign VLANs to those

0:07:51.700000 --> 0:07:56.000000
 and those VLANs are going to be maintained
 as those VMs create traffic

0:07:56.000000 --> 0:08:00.240000
 that pops out of the physical NIC card
 on the host we're going to have

0:08:00.240000 --> 0:08:06.220000
 802.1q tags on there with VLAN identifiers
 so we got to remember the physical

0:08:06.220000 --> 0:08:16.220000
 switch that's connecting to that host has
 to be configured for that segmentation

0:08:16.220000 --> 0:08:21.140000
 that we're looking for and then lastly
 when you create a bunch of virtual

0:08:21.140000 --> 0:08:25.180000
 machines you want to be able to monitor
 that environment you want to be

0:08:25.180000 --> 0:08:28.960000
 able to monitor the individual virtual
 machine see how it's doing see

0:08:28.960000 --> 0:08:33.100000
 what its health is we also want to be
 able to monitor the whole environment

0:08:33.100000 --> 0:08:39.160000
 monitor the hypervisor well as I mentioned
 the guest operating systems

0:08:39.160000 --> 0:08:45.620000
 can only see what the hypervisor wants them
 to see so when you buy a monitoring

0:08:45.620000 --> 0:08:50.060000
 application some sort of network monitoring
 application or host monitoring

0:08:50.060000 --> 0:08:55.900000
 application if you install it on the
 guest so let's say I have a VM that's

0:08:55.900000 --> 0:09:02.060000
 running Microsoft Microsoft Windows 10
 so I say okay what's an application

0:09:02.060000 --> 0:09:08.920000
 I can purchase and install in Microsoft
 Windows 10 that monitors a Microsoft

0:09:08.920000 --> 0:09:13.820000
 Windows 10 device so I can see what
 its health is I can do that I can

0:09:13.820000 --> 0:09:18.880000
 install that on that VM I can log into
 that VM run that application see

0:09:18.880000 --> 0:09:24.760000
 how that VM is doing but that application
 doesn't have the full big picture

0:09:24.760000 --> 0:09:29.960000
 right it only can see what's going on
 inside that virtual machine it can't

0:09:29.960000 --> 0:09:34.720000
 tell me what the actual resources are
 of the host it can't tell me how

0:09:34.720000 --> 0:09:39.380000
 the actual CPU is doing how much actual
 RAM is being consumed by all these

0:09:39.380000 --> 0:09:45.340000
 VMs so we want to purchase network or
 just basic monitoring applications

0:09:45.340000 --> 0:09:50.080000
 that reside both within the guest and
 they're designed to operate within

0:09:50.080000 --> 0:09:57.500000
 the hypervisor itself so the best solution
 is to have a blended approach

0:09:57.500000 --> 0:10:03.940000
 of monitoring software one example of
 this is by SolarWinds so SolarWinds

0:10:03.940000 --> 0:10:08.200000
 is a company they offer a software package
 called the virtualization manager

0:10:08.200000 --> 0:10:13.300000
 here's a screenshot of that this particular
 screenshot is showing us how

0:10:13.300000 --> 0:10:19.760000
 much network traffic is being used by
 each VM if you actually do a Google

0:10:19.760000 --> 0:10:23.680000
 search on this or use this this URL
 right here what's kind of neat about

0:10:23.680000 --> 0:10:27.380000
 the SolarWinds virtualization manager
 is that they have a website where

0:10:27.380000 --> 0:10:31.180000
 you can try this out you can log into
 an example of this and you can click

0:10:31.180000 --> 0:10:35.780000
 on it see various boxes see various
 charts and see how this particular

0:10:35.780000 --> 0:10:39.960000
 monitoring software works before you
 decide to download it and use it

0:10:39.960000 --> 0:10:44.660000
 for yourself so this is just an example
 of one type of monitoring software

0:10:44.660000 --> 0:10:52.480000
 that can monitor individual VMs as
 well as monitor the host itself so