In this post I would like to explain IP-Hash Load Balancing principles used for connecting VMware hosts to IP storage, like NFS, for better understanding how traffic balancement across various NICs occurs.
As reported in previous VMware: Uplink used by a VM in a LB NIC Teaming article Load Balancing policies are effective between vmnics and physical storage and all pSwitches inbetween.
Load Balancing does not occur between VMs, VMkernels and Port Groups in vSwitches.
IP-Hash Load Balancing is the LB technique that could potentially achieve the highest degree of efficiency since it uses different vmnics based on an algorithm that considers the destination IP address the packet has to be sent to and, unlike Route Based on originating virtual port ID it doesen't use a Round Robin vmnic assignation methodology.
Although IP-Hash Load Balancing lead to a better traffic load balancing it also brings the most complex set-up because it also requires particular configuration changes in all pSwitches packets will traverse to reach IP storage.
In pSwitches inbetween your VMware hosts and IP storage you will need to enable IEEE 802.3ad LACP, or Etherchannel if you deal with Cisco equipment, in order to benefit IP-Hash Load Balancing. LACP basically aggregates from 2 up to 8 ethernet channels providing a link with more aggregate bandwidth and resiliency.
Here's a simple connection schema, please bear in mind that in a real case scenario using a single pSwitch introduces a single point of failure in your infrastructure.
You should also consider VLAN implementation in order to isolate storage traffic. This, as you certainly know, is a thumb rule not just for storage traffic such as NFS or iSCSI but even for management traffic, vMotion traffic, FT traffic, etc.
Since my post is VMware related I will assume you have already configured LACP properly in your physical network. For more info on LACP setup please have a look at 1004048 KB.
Let's start by setting up our virtual networking. For sake of simplicity we will use just two vmnics.
We create a new vSwitch and a VMkernel for IP Storage (NFS in my case) assigning these two vmnics to it.
Please be sure that all vmnics are set as Active and that there are no vmnics set as Standby or Unused. IP-Hash Load Balancing must be set at vSwitch level and not overridden at VMkernel/PortGroup level.
IP-Hash Load Balancing algorithm chooses which vmnic utilize for any IP connection based on destination IP address upon the following equation:
vmnic used = [HEX(IP VMkernel) xor HEX(IP Storage)] mod (Number of vmnics)
where:
HEX indicates that the IP address has been converted in hexadecimal format. This is done octet by octet which means that for example 10.11.12.13 IP address in HEX base is 0A.0B.0C.0D that will be represented as 0x0A0B0C0D.
IP VMkernel is the IP address assigned to the VMkernel used for IP Storage
IP Storage is the IP address assigned to the NFS storage
xor is the exclusive or operand
mod is modulo operation
Now that we know how vmnic are choosen for data transfer let's examine how we can wisely assign IP addresses to our IP storage systems.
In this example I will use a NFS server with two NICs (no vIP). I've already assigned IP 192.168.116.10 to VMkernel responsible for carrying IP storage data.
1) Bad IP addresses choice
VMkernel = 192.168.116.10
NFS 1 = 192.168.116.50
NFS 2 = 192.168.116.60
Let's do some math:
vmnic used for NFS1 = [HEX(192.168.116.10) xor HEX(192.168.116.50)] mod (2)
= [0xC0A8740A xor 0xC0A87432] mod (2)
= [38] mod (2)
= 0 -> vmnic0 will be used
vmnic used for NFS2 = [HEX(192.168.116.10) xor HEX(192.168.116.60)] mod (2)
= [0xC0A8740A xor 0xC0A8743C] mod (2)
= [36] mod (2)
= 0 -> vmnic0 will be used
As you can see assigning these two IP addresses to NFS storage was a bad choice becase communications toward both NFS1 and NFS2 will utilize vmnic0 leaving vmnic1 unused.
2) Good IP addresses choice
VMkernel = 192.168.116.10
NFS 1 = 192.168.116.50
NFS 2 = 192.168.116.51
Let's do some math again:
vmnic used for NFS1 = [HEX(192.168.116.10) xor HEX(192.168.116.50)] mod (2)
= [0xC0A8740A xor 0xC0A87432] mod (2)
= [38] mod (2)
= 0 -> vmnic0 will be used
vmnic used for NFS2 = [HEX(192.168.116.10) xor HEX(192.168.116.51)] mod (2)
= [0xC0A8740A xor 0xC0A87433] mod (2)
= [39] mod (2)
= 1 -> vmnic1 will be used
These was a wise choice since communications with NFS1 will use vmnic0 and communications with NFS2 will use vmnic1 achieving traffic balance and both uplinks utilization.
Some useful links:
Best Practices for running VMware vSphere on Network Attached Storage
Sample configuration of EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi/ESX and Cisco/HP switches
That's all!!
sabato 21 settembre 2013
lunedì 9 settembre 2013
VMware: Uplink used by a VM in a LB NIC Teaming
In this post I will explain how to show the uplink used by a VM in a vSwitch with NIC Teaming Load Balancing.
Since we all put our uplinks in a Load Balancing NIC Teaming sometimes it could be useful for troubleshooting purpouses to see what's the specific physical uplink used by that particular VM to access the network.
To explain this I will use a real case scenario that happened to me today.
A customer reported that after vMotioning a VM from one physical host to another this VM was unable to reach a specific IP Address in his network (a router, fyi).
I checked the basic networking settings from vSphere Client like vSwitch configuration and if every vmnic reported network activity (i.e. plugged cable) and everything was fine.
vSwitch configuration was similar to this:
vm4 was the VM reporting issues.
Analyzing vSwitch0 settings this was the result:
As you can see all vmnics (vmnic0, vmnic1, vmnic2, vmnic3) are set as Active and Route Based on originating virtual port ID was selected as Load Balancing method.
Next step was to take a look at physical networking. Customer has a blade enclosure with 3 hosts, each blade (i.e. ESXi physical host) with 4 NIC: vmnic0, vmnic1, vmnic2 and vmnic3.
Each NIC was connected to a different physical switch to achieve path realiability and every switch is connected to the one 'core switch' (second switch from the top in picture below) EXCEPT switch 4...and here all yours bells and whistles will ring.
To make this story short, as most of you have already understood, this was the flaw in this configuration. By per se it's not an issue having a switch not connected to other switches but in this scenario it's a fault because it's used in conjunction with Route Based on originating virtual port ID Load Balancing.
Route Based on originating virtual port ID it's based on a Round Robin uplink assignation. This means that every VM powered on recieve in sequence the next available uplink (vmnic) in the vSwitch.
Take a look at this picture for better understandment:
VM power-on sequence in this case was:
POWER-ON SEQ. UPLINK ASSIGNED
vm1 vmnic0
vm2 vmnic1
vm3 vmnic2
vm4 vmnic3
vm5 vmnic0
...and so on...let's pretend for example a new vm6 will be powered on this VM will use vmnic1. If vm3 and vm6 are powered off and vm6 is powered on back again it will use vmnic2 as uplink. Pretty simple, right?
In my case vm4 reported network issues reaching the router IP Address (the rightmost grey block on the picture above) because after vMotion from one host to another vm4 ended on a host's vSwitch which assigned it to vmnic3 which is connected to an isolated physical switch. This is easily solvable either by adding the missing intra-switch link or by removing vmnic3 from the Load Balancing active adapters.
After this theorethical prologue let's dive a bit into practice by explaining how it's possible to display which uplink (in a LB NIC Team) is used by a VM.
Let's login into our ESXi host.
To retrieve port informations for a particular VM we need to use the following command:
~ # esxcli network vm port list -w <World_ID>
Where <World_ID> is the World ID of our VM. This World ID uniquely identificates a VM in a host and changes every time a VM is vMotioned and a power status change occurs (i.e. vm is powered off and back on again).
To display World ID for our VMs we need to execute following command. Informations about every VM running in the host are retrieved. To keep things clean I only show you the output of vm4.
~ # esxcli vm process list
vm4
World ID: 3307679
Process ID: 0
VMX Cartel ID: 3307678
UUID: 42 19 4a 84 a3 52 c7 ca-d9 28 93 bf 20 6c 2d bc
Display Name: vm4
Config File: /vmfs/volumes/51dc35ee-c4b96dc0-1c1c-b4b53f5110c0/vm4/vm4.vmx
World ID: 3307679 if the value of interest.
If we run the command above this time specifying World ID we get:
~ # esxcli network vm port list -w 3307679
Port ID: 33554444
vSwitch: vSwitch0
Portgroup: VM Network
DVPort ID:
MAC Address: 00:50:56:99:45:3b
IP Address: 0.0.0.0
Team Uplink: vmnic3
Uplink Port ID: 33554438
Active Filters:
As you can see Team Uplink: vmnic3 indicates that vmnic3 is used by this VM.
That's all!
Since we all put our uplinks in a Load Balancing NIC Teaming sometimes it could be useful for troubleshooting purpouses to see what's the specific physical uplink used by that particular VM to access the network.
To explain this I will use a real case scenario that happened to me today.
A customer reported that after vMotioning a VM from one physical host to another this VM was unable to reach a specific IP Address in his network (a router, fyi).
I checked the basic networking settings from vSphere Client like vSwitch configuration and if every vmnic reported network activity (i.e. plugged cable) and everything was fine.
vSwitch configuration was similar to this:
vm4 was the VM reporting issues.
Analyzing vSwitch0 settings this was the result:
As you can see all vmnics (vmnic0, vmnic1, vmnic2, vmnic3) are set as Active and Route Based on originating virtual port ID was selected as Load Balancing method.
Next step was to take a look at physical networking. Customer has a blade enclosure with 3 hosts, each blade (i.e. ESXi physical host) with 4 NIC: vmnic0, vmnic1, vmnic2 and vmnic3.
Each NIC was connected to a different physical switch to achieve path realiability and every switch is connected to the one 'core switch' (second switch from the top in picture below) EXCEPT switch 4...and here all yours bells and whistles will ring.
To make this story short, as most of you have already understood, this was the flaw in this configuration. By per se it's not an issue having a switch not connected to other switches but in this scenario it's a fault because it's used in conjunction with Route Based on originating virtual port ID Load Balancing.
Route Based on originating virtual port ID it's based on a Round Robin uplink assignation. This means that every VM powered on recieve in sequence the next available uplink (vmnic) in the vSwitch.
Take a look at this picture for better understandment:
VM power-on sequence in this case was:
POWER-ON SEQ. UPLINK ASSIGNED
vm1 vmnic0
vm2 vmnic1
vm3 vmnic2
vm4 vmnic3
vm5 vmnic0
...and so on...let's pretend for example a new vm6 will be powered on this VM will use vmnic1. If vm3 and vm6 are powered off and vm6 is powered on back again it will use vmnic2 as uplink. Pretty simple, right?
In my case vm4 reported network issues reaching the router IP Address (the rightmost grey block on the picture above) because after vMotion from one host to another vm4 ended on a host's vSwitch which assigned it to vmnic3 which is connected to an isolated physical switch. This is easily solvable either by adding the missing intra-switch link or by removing vmnic3 from the Load Balancing active adapters.
After this theorethical prologue let's dive a bit into practice by explaining how it's possible to display which uplink (in a LB NIC Team) is used by a VM.
Let's login into our ESXi host.
To retrieve port informations for a particular VM we need to use the following command:
~ # esxcli network vm port list -w <World_ID>
Where <World_ID> is the World ID of our VM. This World ID uniquely identificates a VM in a host and changes every time a VM is vMotioned and a power status change occurs (i.e. vm is powered off and back on again).
To display World ID for our VMs we need to execute following command. Informations about every VM running in the host are retrieved. To keep things clean I only show you the output of vm4.
~ # esxcli vm process list
vm4
World ID: 3307679
Process ID: 0
VMX Cartel ID: 3307678
UUID: 42 19 4a 84 a3 52 c7 ca-d9 28 93 bf 20 6c 2d bc
Display Name: vm4
Config File: /vmfs/volumes/51dc35ee-c4b96dc0-1c1c-b4b53f5110c0/vm4/vm4.vmx
World ID: 3307679 if the value of interest.
If we run the command above this time specifying World ID we get:
~ # esxcli network vm port list -w 3307679
Port ID: 33554444
vSwitch: vSwitch0
Portgroup: VM Network
DVPort ID:
MAC Address: 00:50:56:99:45:3b
IP Address: 0.0.0.0
Team Uplink: vmnic3
Uplink Port ID: 33554438
Active Filters:
As you can see Team Uplink: vmnic3 indicates that vmnic3 is used by this VM.
That's all!
domenica 18 agosto 2013
Oracle Database: PRVF-0002 Could not retrieve local nodename
If you encounter this error while installing Oracle Database 12c:
PRVF-0002 Could not retrieve local nodename
Having a look at Oracle's error documentation it simply tells us:
Cause: Unable to determine local host name using Java network functions.
Action: Ensure hostname is defined correctly using the 'hostname' command.
Here's how to solve it:
This is the standard file hosts
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
If you ever installed Oracle DB 11g you probably know you need to edit hosts file adding the current machine IP address and hostname. So file hosts resulted in something similar to:
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.116.230 vm1 vm1.localdomain
Unfortunately in Oracle DB 12c this is not enough, to solve the error above you need to point loopback address to the machine hostname.
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 vm1 vm1.localdomain localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 vm1 vm1.localdomain localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.116.230 vm1 vm1.localdomain
That's all!!
PRVF-0002 Could not retrieve local nodename
Having a look at Oracle's error documentation it simply tells us:
Cause: Unable to determine local host name using Java network functions.
Action: Ensure hostname is defined correctly using the 'hostname' command.
Here's how to solve it:
This is the standard file hosts
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
If you ever installed Oracle DB 11g you probably know you need to edit hosts file adding the current machine IP address and hostname. So file hosts resulted in something similar to:
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.116.230 vm1 vm1.localdomain
Unfortunately in Oracle DB 12c this is not enough, to solve the error above you need to point loopback address to the machine hostname.
[root@vm1 ~]# nano /etc/hosts
127.0.0.1 vm1 vm1.localdomain localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 vm1 vm1.localdomain localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.116.230 vm1 vm1.localdomain
That's all!!
giovedì 8 agosto 2013
VMware: VLANs and vSwitches
Switches work at Layer2 and basically their job is pretty simple: they just forward Ethernet frames received from one port to another port based on the content of their MAC Address Table.
Let's start giving some basic concepts about Ethernet frames and VLANs.
An IP Packet is encapsulated at Layer2 (Data Link) in an Ethernet Frame.
By default Ethernet packets at Layer3 have a maximum Ethernet payload MTU of 1500bytes. This MTU depends on network protocol and for example is 1478 for PPPoA, 1446 for PPPoE, but it cannot grow over 1500bytes (if it is >= 1501bytes it is a Jumbo Packet).
As depicted in image above an Ethernet frame is composed by:
-Preamble
-SFD (Start of frame delimiter)
-Destination MAC Address
-Source MAC Address
-VLAN ID - IEEE 802.1Q tag (optional)
-Ethertype
-Payload
-FCS (Frame check sequence)
At Layer2, by default, an Ethernet frame is 1518bytes long. Preamble and SFD are not computed in frame size because they are used for synchronization and not for actual data transmission.
When dealing with VLANs an 802.1Q tag of 4bytes is added by the switch between Source MAC Address field and Ethertype field. With VLANs an Ethernet frame grows up to 1522bytes. By default switches drops packets that are greater than 1518bytes so when using VLANs switches must be prior configured.
Actually the condition above doesn't always apply becase for example Cisco switches supports by default Ethernet frames up to 1548bytes to accomodate encapsulation of an Ethernet packet into an ISL packet.
VLAN tagging is performed ONLY by switches and despite a VM itself could tag frames, in this article we consider tagging is ONLY performed by switches.
A switch adds a VLAN ID when it recieves a packet from a port belonging to a VLAN. VLAN tag is added in the correct frame position and, since frame has been modified, Frame check sequence (32bit CRC) has to be recalculated.
When a frame reach the switch to which reciever is directly attached it:
-Read VLAN tag
-Perform a lookup to check if Destination MAC Address from recieved frame is contained in switch MAC Address Table and to which port frame has to be forwarded.
-If step above is successful it recalculates Frame check sequence
-Forward frame to destination
Let's now see how VLANs and vSwitches work in vSphere:
We have two VMs: VM1 and VM2
First scenario: VM1 and VM2 are on the same VLAN, same vSwitch and same PortGroup VM Network 100
Using vswitchInfo.sh from virtuallyGhetto we can retrieve port ID to which VMs are connected to vSwitches in order to allow us to build a MAC Address Table.
Launching from ESXi host via SSH:
~ # ./vswitchInfo.sh -l
We get the following:
This allow us to deduce how the vSwitch MAC Addres Table would look like. We suppose that MAC Addres Table is completely/correctly built so every switch either virtual and physical knows to what interfaces forward packets.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
100 00:50:56:8a:25:f9 50331669
Since VM1 and VM2 are both on same PortGroup on same vSwitch when Ethernet frame is send from VM1 to VM2 vSwitch1 recieves frame, it performs a lookup in MAC Addres Table and it find that VM2 is directly attached to it so it forward frame to port ID 50331669 WITHOUT VLAN tag.
VM1 is able to communicate with VM2
Second scenario: VM1 and VM2 are on the same VLAN, same vSwitch but different PortGroup (VM Network 100 and VM Network 100-2)
We have this:
Same MAC Addres Table from first scenario only Port ID has changed for VM2 since it has been moved to another PortGroup.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
100 00:50:56:8a:25:f9 50331668
Since VM1 and VM2 are both on same switch vSwitch1 recieves frame, it performs a lookup in MAC Addres Table and it find that VM2 is directly attached to it so it forward frame to port 50331668 WITHOUT VLAN tag.
Third scenario: VM1 and VM2 are on the same VLAN but different vSwitch. Both VM Network 100 and VM Network VLAN 100 PortGroups have VLAN ID=100.
Please note that when VMs are on different vSwitches frames are always forwarded to physical switches.
We have this:
Two MAC Addres Table one for vSwitch1 and one for vSwitch0.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
vSwitch0
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:25:f9 33554462
VM1 and VM2 are on different switches. vSwitch1 recieves Ethernet frame from VM1 addressed to VM2. Destination MAC Address is not contained in vSwitch1 MAC Addres Table so vSwitch1:
-Add VLAN tag specifying that frame destined to VM2 belongs to VLAN 100
-Recalculate FCS
-Forward frame to physical switch
Physical switch:
-Recieves frame from vSwitch1
-Forward frame to vSwitch0
Of course even physical switch uses a MAC Addres Table for frames forwarding.
Usually intra switch links are trunks. This means that a single port/cable can carry frames from multiple VLANs.
vSwitch0:
-Recieves frame
-Read VLAN tag
-Perform a lookup to check if VM2 Destination MAC Address (00:50:56:8a:25:f9) is contained in its MAC Address Tableand is connected to port 33554462
-Since previous step is successful it recalculates Frame check sequence
-Forward frame to VM2 via port 33554462
VM1 is able to communicate with VM2
Fourth scenario: VM1 and VM2 are on different VLAN, same vSwitch, different PortGroup (VM Network 100 and VM Network 200)
We have this:
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
200 00:50:56:8a:25:f9 50331671
VM1 and VM2 are on different VLANs, vSwitch1 recieves frame lookup in MAC Addres Table and find out that VM2 is on a different VLAN than VM1. vSwitch1 drops the frame.
VM1 is NOT able to communicate with VM2
Fifth scenario: VM1 and VM2 are on different VLAN and different vSwitch
We have this:
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
vSwitch0
Vlan Mac Address Ports
---- ----------- -----
200 00:50:56:8a:25:f9 33554462
As in third scenario VM1 and VM2 are on different switches so frames will be forwarded to physical switch. vSwitch1 recieves Ethernet frame from VM1 addressed to VM2.
Destination MAC Address is not contained in vSwitch1 MAC Addres Table so vSwitch1:
-Add VLAN tag specifiyng that frame destined to VM2 belongs to VLAN 100
-Recalculate FCS
-Forward frame to physical switch
Physical switch:
-Recieves frame from vSwitch1
-Forward frame to vSwitch0
vSwitch0:
-Recieves frame
-Read VLAN tag
-Perform a lookup to check if VM2 Destination MAC Address (00:50:56:8a:25:f9) is in its MAC Address Table
-Since VM2 is on a different VLAN vSwitch1 drops the frame
VM1 is NOT able to communicate with VM2
So, it's important to understand that in vSphere when a VM sends packets/frames to another VM on a different vSwitch those packets/frames will always hit physical switch.
Another major concept to remember is that VLAN tagging occurs only when frames leave vSwitch. Intra-vSwitch communications are not VLAN tagged.
That's all!!
Let's start giving some basic concepts about Ethernet frames and VLANs.
An IP Packet is encapsulated at Layer2 (Data Link) in an Ethernet Frame.
By default Ethernet packets at Layer3 have a maximum Ethernet payload MTU of 1500bytes. This MTU depends on network protocol and for example is 1478 for PPPoA, 1446 for PPPoE, but it cannot grow over 1500bytes (if it is >= 1501bytes it is a Jumbo Packet).
As depicted in image above an Ethernet frame is composed by:
-Preamble
-SFD (Start of frame delimiter)
-Destination MAC Address
-Source MAC Address
-VLAN ID - IEEE 802.1Q tag (optional)
-Ethertype
-Payload
-FCS (Frame check sequence)
At Layer2, by default, an Ethernet frame is 1518bytes long. Preamble and SFD are not computed in frame size because they are used for synchronization and not for actual data transmission.
When dealing with VLANs an 802.1Q tag of 4bytes is added by the switch between Source MAC Address field and Ethertype field. With VLANs an Ethernet frame grows up to 1522bytes. By default switches drops packets that are greater than 1518bytes so when using VLANs switches must be prior configured.
Actually the condition above doesn't always apply becase for example Cisco switches supports by default Ethernet frames up to 1548bytes to accomodate encapsulation of an Ethernet packet into an ISL packet.
VLAN tagging is performed ONLY by switches and despite a VM itself could tag frames, in this article we consider tagging is ONLY performed by switches.
A switch adds a VLAN ID when it recieves a packet from a port belonging to a VLAN. VLAN tag is added in the correct frame position and, since frame has been modified, Frame check sequence (32bit CRC) has to be recalculated.
When a frame reach the switch to which reciever is directly attached it:
-Read VLAN tag
-Perform a lookup to check if Destination MAC Address from recieved frame is contained in switch MAC Address Table and to which port frame has to be forwarded.
-If step above is successful it recalculates Frame check sequence
-Forward frame to destination
Let's now see how VLANs and vSwitches work in vSphere:
We have two VMs: VM1 and VM2
First scenario: VM1 and VM2 are on the same VLAN, same vSwitch and same PortGroup VM Network 100
Using vswitchInfo.sh from virtuallyGhetto we can retrieve port ID to which VMs are connected to vSwitches in order to allow us to build a MAC Address Table.
Launching from ESXi host via SSH:
~ # ./vswitchInfo.sh -l
We get the following:
This allow us to deduce how the vSwitch MAC Addres Table would look like. We suppose that MAC Addres Table is completely/correctly built so every switch either virtual and physical knows to what interfaces forward packets.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
100 00:50:56:8a:25:f9 50331669
Since VM1 and VM2 are both on same PortGroup on same vSwitch when Ethernet frame is send from VM1 to VM2 vSwitch1 recieves frame, it performs a lookup in MAC Addres Table and it find that VM2 is directly attached to it so it forward frame to port ID 50331669 WITHOUT VLAN tag.
VM1 is able to communicate with VM2
Second scenario: VM1 and VM2 are on the same VLAN, same vSwitch but different PortGroup (VM Network 100 and VM Network 100-2)
We have this:
Same MAC Addres Table from first scenario only Port ID has changed for VM2 since it has been moved to another PortGroup.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
100 00:50:56:8a:25:f9 50331668
Since VM1 and VM2 are both on same switch vSwitch1 recieves frame, it performs a lookup in MAC Addres Table and it find that VM2 is directly attached to it so it forward frame to port 50331668 WITHOUT VLAN tag.
Third scenario: VM1 and VM2 are on the same VLAN but different vSwitch. Both VM Network 100 and VM Network VLAN 100 PortGroups have VLAN ID=100.
Please note that when VMs are on different vSwitches frames are always forwarded to physical switches.
We have this:
Two MAC Addres Table one for vSwitch1 and one for vSwitch0.
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
vSwitch0
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:25:f9 33554462
VM1 and VM2 are on different switches. vSwitch1 recieves Ethernet frame from VM1 addressed to VM2. Destination MAC Address is not contained in vSwitch1 MAC Addres Table so vSwitch1:
-Add VLAN tag specifying that frame destined to VM2 belongs to VLAN 100
-Recalculate FCS
-Forward frame to physical switch
Physical switch:
-Recieves frame from vSwitch1
-Forward frame to vSwitch0
Of course even physical switch uses a MAC Addres Table for frames forwarding.
Usually intra switch links are trunks. This means that a single port/cable can carry frames from multiple VLANs.
vSwitch0:
-Recieves frame
-Read VLAN tag
-Perform a lookup to check if VM2 Destination MAC Address (00:50:56:8a:25:f9) is contained in its MAC Address Tableand is connected to port 33554462
-Since previous step is successful it recalculates Frame check sequence
-Forward frame to VM2 via port 33554462
VM1 is able to communicate with VM2
Fourth scenario: VM1 and VM2 are on different VLAN, same vSwitch, different PortGroup (VM Network 100 and VM Network 200)
We have this:
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
200 00:50:56:8a:25:f9 50331671
VM1 and VM2 are on different VLANs, vSwitch1 recieves frame lookup in MAC Addres Table and find out that VM2 is on a different VLAN than VM1. vSwitch1 drops the frame.
VM1 is NOT able to communicate with VM2
Fifth scenario: VM1 and VM2 are on different VLAN and different vSwitch
We have this:
vSwitch1
Vlan Mac Address Ports
---- ----------- -----
100 00:50:56:8a:7e:34 50331665
vSwitch0
Vlan Mac Address Ports
---- ----------- -----
200 00:50:56:8a:25:f9 33554462
As in third scenario VM1 and VM2 are on different switches so frames will be forwarded to physical switch. vSwitch1 recieves Ethernet frame from VM1 addressed to VM2.
Destination MAC Address is not contained in vSwitch1 MAC Addres Table so vSwitch1:
-Add VLAN tag specifiyng that frame destined to VM2 belongs to VLAN 100
-Recalculate FCS
-Forward frame to physical switch
Physical switch:
-Recieves frame from vSwitch1
-Forward frame to vSwitch0
vSwitch0:
-Recieves frame
-Read VLAN tag
-Perform a lookup to check if VM2 Destination MAC Address (00:50:56:8a:25:f9) is in its MAC Address Table
-Since VM2 is on a different VLAN vSwitch1 drops the frame
VM1 is NOT able to communicate with VM2
So, it's important to understand that in vSphere when a VM sends packets/frames to another VM on a different vSwitch those packets/frames will always hit physical switch.
Another major concept to remember is that VLAN tagging occurs only when frames leave vSwitch. Intra-vSwitch communications are not VLAN tagged.
That's all!!
mercoledì 7 agosto 2013
VMware: manage networking with esxcfg
In this post I will explain how to manage vNetworking using esxcfg.
For explanation purpouses let's simulate a scenario. Pretend we need a second management network for redundancy's sake (network heartbeating for HA). For this management network we will use a dedicated network adapter.
Here's what we want to achieve:
These are our steps:
-Create an additional vSwitch
-Assign a network adapter to this vSwitch
-Create a new vmkernel
-Enable Jumbo Frame on vmkernel
-Use this vmkernel for Management Traffic
Let's start by connecting to the host via SSH (I use Putty) and listing all network adapters attached to host:
~ # esxcfg-nics -l
List all vSwitches with corresponding network adapters
~ # esxcfg-vswitch -l
As you can see in this scenario I only have one vSwitch named vSwitch0. It would be advised to add the new vmkernel for management to vSwitch0 itselfs but for the sake of this post I will create another vSwitch and then add the management vmkernel to that vSwitch.
Please bear in mind that by creating a new vSwitch you introduce a new element in your environment so when you are in "troubleshooting mode" the less items you have to check the faster you are in identifying trouble causes. A thumb rule is to use as less vSwitches as possible.
Command above told us vmnic3 it's the only available network adapter so we will use that in our new vSwitch.
If there are no vmnics available it is also possible to remove some from vSwitch0.
For example to remove vmnic2 from vSwitch0
~ # esxcfg-vswitch -U vmnic2 vSwitch0
Now let's first create a vSwitch named vSwitch1
~ # esxcfg-vswitch -a vSwitch1
Then we add network adapter vmnic3 to vSwitch1
~ # esxcfg-vswitch -L vmnic3 vSwitch1
Create a Management Network 2 vmkernel in vSwitch1
~ # esxcfg-vswitch -A "Management Network 2" vSwitch1
Assign it an IP/netmask
~ # esxcfg-vmknic -a -i 10.0.1.100 -n 255.255.255.0 "Management Network 2"
Set VLAN ID 300 for Management Network 2 vmkernel
~ # esxcfg-vswitch -v 300 -p "Management Network 2"
Let's pretend we need to use Jumbo Frames. For your interest it's pretty pointless enabling Jumbo Frames in a management only vmkernel since benefits of transmitting Ethernet packets with a bigger payload are primarily pointed out when there is a heavy network activity. Jumbo frames could be useful on vMotion or iSCSI/NFS vmkernels. Anyway to enable Jumbo Frames we need to edit the Maximum Transmission Unit setting it to 9000bytes.
You also need to change MTU on you physical switch in order to use Jumbo Frames. If your vSwitch sends packets with an MTU of 9000bytes and your pSwitch expects them of 1500bytes (default Ethernet packet MTU) packets could be either fragmented or dropped. Here's a good article by Cisco!
~ # esxcfg-vmknic -m 9000 -p "Management Network 2"
We created a "general purpouse" vmkernel and since we need to use this for Management Traffic we need to specify it.
First we retrieve informations on newly created vmkernel:
~ # esxcfg-vmknic -l
As you can see in picture above our vmkernel is vmk3.
William Lam in this VMware Community post explains how to bind specific traffic to a vmkernel.
As for management traffic the following command is used:
~ # vim-cmd hostsvc/advopt/update Net.ManagementIface string vmk3
To briefly recap we used esxcfg to manage our vSphere networking. We introduced a fictional scenario to point out what commands need to be used in order to edit/create/manage networking in ESXi hosts.
That's all!!
For explanation purpouses let's simulate a scenario. Pretend we need a second management network for redundancy's sake (network heartbeating for HA). For this management network we will use a dedicated network adapter.
Here's what we want to achieve:
These are our steps:
-Create an additional vSwitch
-Assign a network adapter to this vSwitch
-Create a new vmkernel
-Enable Jumbo Frame on vmkernel
-Use this vmkernel for Management Traffic
Let's start by connecting to the host via SSH (I use Putty) and listing all network adapters attached to host:
~ # esxcfg-nics -l
List all vSwitches with corresponding network adapters
~ # esxcfg-vswitch -l
As you can see in this scenario I only have one vSwitch named vSwitch0. It would be advised to add the new vmkernel for management to vSwitch0 itselfs but for the sake of this post I will create another vSwitch and then add the management vmkernel to that vSwitch.
Please bear in mind that by creating a new vSwitch you introduce a new element in your environment so when you are in "troubleshooting mode" the less items you have to check the faster you are in identifying trouble causes. A thumb rule is to use as less vSwitches as possible.
Command above told us vmnic3 it's the only available network adapter so we will use that in our new vSwitch.
If there are no vmnics available it is also possible to remove some from vSwitch0.
For example to remove vmnic2 from vSwitch0
~ # esxcfg-vswitch -U vmnic2 vSwitch0
Now let's first create a vSwitch named vSwitch1
~ # esxcfg-vswitch -a vSwitch1
Then we add network adapter vmnic3 to vSwitch1
~ # esxcfg-vswitch -L vmnic3 vSwitch1
Create a Management Network 2 vmkernel in vSwitch1
~ # esxcfg-vswitch -A "Management Network 2" vSwitch1
Assign it an IP/netmask
~ # esxcfg-vmknic -a -i 10.0.1.100 -n 255.255.255.0 "Management Network 2"
Set VLAN ID 300 for Management Network 2 vmkernel
~ # esxcfg-vswitch -v 300 -p "Management Network 2"
Let's pretend we need to use Jumbo Frames. For your interest it's pretty pointless enabling Jumbo Frames in a management only vmkernel since benefits of transmitting Ethernet packets with a bigger payload are primarily pointed out when there is a heavy network activity. Jumbo frames could be useful on vMotion or iSCSI/NFS vmkernels. Anyway to enable Jumbo Frames we need to edit the Maximum Transmission Unit setting it to 9000bytes.
You also need to change MTU on you physical switch in order to use Jumbo Frames. If your vSwitch sends packets with an MTU of 9000bytes and your pSwitch expects them of 1500bytes (default Ethernet packet MTU) packets could be either fragmented or dropped. Here's a good article by Cisco!
~ # esxcfg-vmknic -m 9000 -p "Management Network 2"
We created a "general purpouse" vmkernel and since we need to use this for Management Traffic we need to specify it.
First we retrieve informations on newly created vmkernel:
~ # esxcfg-vmknic -l
As you can see in picture above our vmkernel is vmk3.
William Lam in this VMware Community post explains how to bind specific traffic to a vmkernel.
As for management traffic the following command is used:
~ # vim-cmd hostsvc/advopt/update Net.ManagementIface string vmk3
To briefly recap we used esxcfg to manage our vSphere networking. We introduced a fictional scenario to point out what commands need to be used in order to edit/create/manage networking in ESXi hosts.
That's all!!
martedì 6 agosto 2013
VMware: Locate VMs snapshots using PowerCLI
Here's another PowerCLI post.
Everyone who is dealing with vSphere knows about snapshots pros and cons. To be honest I've had in the past some issues with snapshots, typically when visiting customers datacenters I found out VMs that were running on snapshots so old that they were bigger in size than base vmdk itself or, as once happened, that a backup software created almost 200 snapshots of a VM because, once backup was performed successfully, it was not able to revert back the snapshot.
That's why a common suggestion is to use snapshots just for updating purpouses like OS patching and revert them as soon as possible because as they grow up in size it could be unconfortable to revert them back.
After this introduction here's the main topic of this post: a PowerCLI script that locates snapshots of your VMs.
Save this code as a file with .ps1 extension:
From code above you can see we are retrieving all VMs in our environment, then the hard disk files of that VMs.
Of these hard disks we want to display snapshots only.
As you know VMware snapshots disk are named:
<VM_NAME>-<SNAPSHOT_NUMBER>.vmdk
Example: Win2008-000001.vmdk
So with:
$_.Filename -like "*-??????.vmdk"
we are looking for disks that contains -<SNAPSHOT_NUMBER>.vmdk and with
$_.Filename -match "\d{2,7}" -eq "True"
we are verifying that those esclamation marks *-??????.vmdk are numbers and NOT letters.
Without this control the PowerCLI script would return any vmdk which has a "-" and 6 letters before ".vmdk"
For example it would also return a VM disk named:
Win2008-DVLPMT.vmdk
which clearly is NOT a snapshot disk.
As always to run this script you need to connect to a vCenter server (or ESXi host) by using Connect-VIServer cmdlet.
That's all!!
Everyone who is dealing with vSphere knows about snapshots pros and cons. To be honest I've had in the past some issues with snapshots, typically when visiting customers datacenters I found out VMs that were running on snapshots so old that they were bigger in size than base vmdk itself or, as once happened, that a backup software created almost 200 snapshots of a VM because, once backup was performed successfully, it was not able to revert back the snapshot.
That's why a common suggestion is to use snapshots just for updating purpouses like OS patching and revert them as soon as possible because as they grow up in size it could be unconfortable to revert them back.
After this introduction here's the main topic of this post: a PowerCLI script that locates snapshots of your VMs.
Save this code as a file with .ps1 extension:
foreach($vm in ($VMs = Get-VM)){
$vm | Get-HardDisk | %{
if($_.Filename -like "*-??????.vmdk" -and ($_.Filename -match "\d{2,7}" -eq "True")){
$_.Filename |Ft -autosize | out-string -width 4096
}
}
}
From code above you can see we are retrieving all VMs in our environment, then the hard disk files of that VMs.
Of these hard disks we want to display snapshots only.
As you know VMware snapshots disk are named:
<VM_NAME>-<SNAPSHOT_NUMBER>.vmdk
Example: Win2008-000001.vmdk
So with:
$_.Filename -like "*-??????.vmdk"
we are looking for disks that contains -<SNAPSHOT_NUMBER>.vmdk and with
$_.Filename -match "\d{2,7}" -eq "True"
we are verifying that those esclamation marks *-??????.vmdk are numbers and NOT letters.
Without this control the PowerCLI script would return any vmdk which has a "-" and 6 letters before ".vmdk"
For example it would also return a VM disk named:
Win2008-DVLPMT.vmdk
which clearly is NOT a snapshot disk.
As always to run this script you need to connect to a vCenter server (or ESXi host) by using Connect-VIServer cmdlet.
That's all!!
mercoledì 31 luglio 2013
VMware: Deploy VMs from Template using PowerCLI
After yesterday's introductive post, today I would like to share a simple, yet powerful, PowerCLI script that allows you to deploy VMs from a Template.
This is the script structure:
Where:
<N> is the number of VMs you need to deploy.
<ESX_HOST> is the host where you will deploy your VMs
<TEMPLATE> is the template from which your VMs will be created
<DATASTORE> is the datastore that will contain your VMs
[-OtherOptions] are additional options that can be used in conjunction with New-VM command.
As you can see it's really basic, but New-VM cmdlet is really powerful and it has a lot of options. To go through all on New-VM options:
Get-Help New-VM -Detailed
Here's how I used it today for deploying 6 VMs that will be Oracle RAC nodes.
Open a text editor and paste this code in it saving file with .ps1 extension.
As you can see we are deploying 6 VMs, named RAC1 to RAC6 from a template called OL6.
RAC1 and RAC2 will be deployed on host esx1.testdomain.com, RAC3 and RAC4 on host esx2.testdomain.com and RAC5 and RAC6 on host esx3.testdomain.com.
RAC3 and RAC4 will be placed in a resource pool called TestResourcePool.
RAC5 and RAC6 will be powered on after deployment due to Start-VM cmdlet.
To run this simple script just open VMware vSphere PowerCLI, connect to your vCenter (or host) using Connect-VIServer cmdlet as stated in VMware: vSphere PowerCLI 101 post.
A progress bar will appear in your PowerCLI console
That's all!!Happy VMware Automation!!
This is the script structure:
1..<N> | Foreach {
New-VM -vmhost <ESX_HOST> -Name <VM_NAME> -Template <TEMPLATE> -Datastore <DATASTORE> [-OtherOptions]
}
Where:
<N> is the number of VMs you need to deploy.
<ESX_HOST> is the host where you will deploy your VMs
<TEMPLATE> is the template from which your VMs will be created
<DATASTORE> is the datastore that will contain your VMs
[-OtherOptions] are additional options that can be used in conjunction with New-VM command.
As you can see it's really basic, but New-VM cmdlet is really powerful and it has a lot of options. To go through all on New-VM options:
Get-Help New-VM -Detailed
Here's how I used it today for deploying 6 VMs that will be Oracle RAC nodes.
Open a text editor and paste this code in it saving file with .ps1 extension.
1..2 | Foreach {
New-VM -vmhost esx1.testdomain.com -Name RAC$_ -Template OL6 -Datastore datastore1
}
3..4 | Foreach {
New-VM -vmhost esx2.testdomain.com -Name RAC$_ -Template OL6 -Datastore datastore2 -ResourcePool TestResourcePool
}
5..6 | Foreach {
New-VM -vmhost esx3.testdomain.com -Name RAC$_ -Template OL6 -Datastore datastore3 | Start-VM
}
As you can see we are deploying 6 VMs, named RAC1 to RAC6 from a template called OL6.
RAC1 and RAC2 will be deployed on host esx1.testdomain.com, RAC3 and RAC4 on host esx2.testdomain.com and RAC5 and RAC6 on host esx3.testdomain.com.
RAC3 and RAC4 will be placed in a resource pool called TestResourcePool.
RAC5 and RAC6 will be powered on after deployment due to Start-VM cmdlet.
To run this simple script just open VMware vSphere PowerCLI, connect to your vCenter (or host) using Connect-VIServer cmdlet as stated in VMware: vSphere PowerCLI 101 post.
A progress bar will appear in your PowerCLI console
That's all!!Happy VMware Automation!!
Iscriviti a:
Commenti (Atom)































