Configuring Standard Switches

Introduction to Standard vSwitches

Version: vSphere 5.5

Introduction

Standard vSwitches have been around in VMware ESX since the very earliest days – they are a robust, well-known technology and despite the advances in networking with onset of Distributed vSwitches, VMware NSX, VMware VXLAN, and vSphere Networking and Security (vCNS) – they remain very popular. Standard vSwitches reside on the VMware ESX hosts and can be managed both in stand-alone way with the vSphere Client, or via the vCenter Server using the web-client. Additionally, there are extensive PowerShell cmdlets available, together with commands on the ESX host. These commands on the ESX host itself can be very useful when used in conjunction with scripted installation for laying down the basic networking layer required for other functions and features such as access IP-based storage (NFS and iSCSI) as well as advanced features such as vMotion and Fault Tolerance.

Standard Switches are packed with features – but they are not as functional or easy to manage as the Distributed vSwitch. You may find that other technologies available from VMware strongly recommend or require the use of Distributed vSwitches. For example VMware’s vCloud Director (vCD) leans heavily on the Distributed vSwitch, and although Standard vSwitches are supported – it is substantially more effort to manage vCD without Distributed vSwitches. With that said, Standard vSwitches remain popular for environments that are mainly geared around primary compute virtualization, and this due in no small part to the Standard vSwitch being available in all distributions of vSphere, whereas the Distributed vSwitch is currently only available within the Enterprize Plus editions of the platform.

Some organizations prefer to use a combination of both Standard vSwitches and Distributed vSwitches. In this scenario they use Standard vSwitches to manage all “host” based networking, and use Distributed vSwitches to manage all “VM” Networking.

Network Patching of Standard vSwitches

Mode 1: Internal Standard vSwitch

In this case no physical network card (referred to as vmnic’s in VMware terminology) is mapped to the virtual switch. In this case all network communication remains within the walls of the physical server, and only systems configured to the same “internal” Standard vSwitch can communicate with each other. As such their usage remains limited to specific situations such as:

  • Creating a test network within to run VMs isolated from others
  • Creating a “firewall-in-a-box” scenario were one VM contains two NICs connected to two different vSwitches for purposes of being the Firewall/NAT/Router between the two networks.
  • Used by VMware Site Recovery Manager to create a “bubble network” during tests to prevent network conflicts during the use of recovery plans for DR purposes

Mode 2: Basic Standard vSwitch

In this case just one vmnic is mapped to the vSwitch providing basic communication to outside the world. This could be used for network process where redundancy is not a priority. Alternatively, it maybe that a path from the host is duplicated elsewhere and redundancy is taken care of. For instance it’s not unusual to have two “management” interfaces for VMware High Availability – two provide two separate paths to validate the state of the cluster.

Mode 3: Teamed Standard vSwitch

In this case more than one physical vmnic is mapped to the Standard vSwitch. With this configuration all communication passing through the vSwitch is load-balanced and offers network redundancy. This a common configuration for traffic that needs to be highly redundant. For instance IP Storage such as NFS and iSCSI could be backed by vSwitch backed with multiple NIC to boost throughput and ensure the if a network card or physical switch, there would be an available path to the storage.

Types of Communication

Host Communication Every Standard vSwitch has portgroups as sub-component. Portgroups can be of a “vmkernel” type and hold an IP configuration (IP/Subnet Mask/Gateway). These can be enabled for different traffic including vMotion, Management and Fault-Tolerence as well as used to connect to IP storage. Portgroups supports a VLAN configuration using the 803.3q VLAN Tagging standard. As ethernet frames leave the ESX hosts, additional bytes are added to the header. This includes part that indicates the ethernet is tagged, and the VLAN ID itself.

Virtual Machine Communication Portgroups are used for virtual machine communication. When a VM is created it is patched to a portgroup on the vSwitch. Again, VLAN Tagging is supported and the VM and the guest operating system within uses the inherent load-balancing and redundancy – for this reason there is no need to configure VLAN information within the operating system, or any need to install special vendor drivers to support network teaming.

Typical Standard vSwitch Configurations

For a physical server with many network cards, it is feasible to create a Standard vSwitch for each type of traffic. This guarantees that bandwidth is dedicated to that function, and its very clear where the traffic is following. This possible with rack mounted equipment fitted with quad-port cards, or blade architectures that allow for I/0 virtualization where the management layer allows for appearance of many network adapters.

vSwitch0/vmnic0 – Management vSwitch1/vmnic1/2 – IP Storage vSwitch2/vmnic3/4 – Fault Tolerance vSwitch3/vmnic5 – vMotion vSwitch4/vmnic6 – High Availability Heartbeat vSwitch5/vmnic7/8 – Virtual Machines traffic with multiple portgroups for multiple VLANS

Typically, a host maybe more limited when it comes to the number of physical NICs

Creating Standard vSwitch (Web-Client)

Creating an Internal Standard vSwitch

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

Screen Shot 2013-11-26 at 19.39.30.png

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

Screen Shot 2013-11-26 at 19.42.42.png

6. Select New Standard Switch

Screen Shot 2013-11-26 at 19.43.56.png

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Click Next to bypass the mapping of physical NICs to the Standard Switch

Screen Shot 2013-11-26 at 19.45.44.png

Click OK to the warning that you have chosen not to select a physical network adapters

Screen Shot 2013-11-26 at 19.48.42.png

8. Type a friendly name for the Portgroup. In this case the VLAN value is irrelevant as there is no communication to the physical switch where VLANs are defined

Screen Shot 2013-11-26 at 19.51.05.png

IMPORTANT: Portgroup names are case-sensitive and should be consistent from one ESX host to another.

9. Click Next and Finish to create the Internal Standard vSwitch.

The new Standard vSwitch should appear in the web-client – along side the built-in vSwitch0 which is generated during the time of installation.

Screen Shot 2013-11-27 at 08.17.37.png

Creating an Basic Standard vSwitch

Creating a basic Standard vSwitch that just has one physical vmnic connecting it to the outside world, is very similar to creating an Internal Standard vSwitch – the only difference is that you add a NIC during the configuration.

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

Screen Shot 2013-11-26 at 19.39.30.png

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

Screen Shot 2013-11-26 at 19.42.42.png

6. Select New Standard Switch

Screen Shot 2013-11-26 at 19.43.56.png

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Select Active Adapters, and click the green + to add a physical vmnic to the vSwitch

Screen Shot 2013-11-27 at 08.21.36.png

The web-client should refresh to indicate your selection

Screen Shot 2013-11-27 at 08.26.48.png

8. Type a friendly label for the portgroup name

Screen Shot 2013-11-27 at 08.28.49.png

9. Click Next and Finish to complete the configuration

The new Standard vSwitch should appear in the web-client – along side the built-in vSwitch0 which is generated during the time of installation.

Screen Shot 2013-11-27 at 08.32.23.png

Creating an Teamed Standard vSwitch with VLAN Tagging

In this scenario we will create a Standard vSwitch that supports multiple physical vmnic interfaces, as well as multiple tagged VLAN configurations.

1. Open the web-client and navigate to >Host and Clusters >Select the vCenter >Select the Datacenter > Select an ESX host

2. Select the Manage tab, and the Network column

3. Select the Virtual Switches option

4. Click the Add host networking icon

Screen Shot 2013-11-26 at 19.39.30.png

5. Select Virtual Machine Portgroup for a Standard Switch and click Next

Screen Shot 2013-11-26 at 19.42.42.png

6. Select New Standard Switch

Screen Shot 2013-11-26 at 19.43.56.png

Note: New Standard vSwitches are given a serial number vSwitch0, vSwitch1 and so on.

7. Select Active Adapters, and click the green + to add a physical vmnic to the vSwitch. Merely the act adding additional NICs enables load-balancing and redundancy.

Screen Shot 2013-11-27 at 08.42.03.png

8. Type a friendly label for the portgroup name, as well as the VLAN number

Screen Shot 2013-11-27 at 08.45.26.png

9. Click Next and Finish to complete the configuration

To configure additional VLANs we merely add additional portgroups to the same Standard vSwitch

10. Click the Add host networking icon

11. Select Virtual Machine Portgroup for a Standard Switch and click Next

12. Select the existing vSwitch that will host the new portgroup.

Screen Shot 2013-11-27 at 09.00.01.png

13. Click Next and Finish to complete the configuration

This workflow can be repeated for as many VLANs as need to be configured. Below vSwitch3 has three portgroups each configured for VLAN-tagging for VLAN 12, 13, and 14.

Screen Shot 2013-11-27 at 09.05.53.png

Creating an Teamed Standard vSwitch for Load-Balanced iSCSI communications

IMPORTANT: Simply configuring a Standard vSwitch on its own does not necessarily ensure that the multi-paths to the storage are indeed load-balanced. Further configuration of the Path Selection Policies (PSP) for the VMware Software iSCSI Initiator will be required. You should work closely with your storage vendor to ensure the correct configuration the PSP component. This is covered in the Storage Chapter in the Vendor Support on Path Selection Policies section.

Note: In this tutorial the ESX host had insufficient NICs to create yet another Standard vSwitch to ensure the storage traffic existed on dedicated physical NICs separate from all other traffic. A compromised was reach by removing the previous examples, and mapping both vmnic0 and vmnic1 to built-in Standard vSwitch. This configuration will leave behind vmnic2/vmnic3 for use with Distributed vSwitches. This configuration change was made by selecting vSwitch0 in the web-client and clicking the “Manage the physical adapters connected to the selected switch”, and using the green + button to adding vmnic1.

Screen Shot 2013-11-27 at 09.14.19.png

VMware ESX ships with a built-in iSCSI Software Initiator used for making connections to iSCSI Storage Arrays. It supports a load-balanced configuration where two “vmkernel” ports each with their own IP configuration and fixed to separate physical NICs. As such its good example of both creating vmkernel ports, and also using the advanced functionality of the Standard vSwitch to achieve optimal performance. There two possible configurations

Option 1:

  • Two Standard vSwitches with one physical vmnic each
  • vmkernel portgroup on each vSwitch, with a valid IP address for the iSCSI Target

Option 2:

  • One Standard vSwitch with two physical vmnics assigned
  • Two vmkernel portgroups on the Standard vSwitch
  • Portgroup1 would use vmnic0 as “Active” and vmnic1 as “Not in Use”
  • Porgroup2 would use vmnic1 as “Active” and vmnic0 as “Not in Use”

It this second configuration that we will show here.

Step One: Create the VMkernel Portgroups

1. Select vSwitch0, and click the Add Host Networking button

2. Select VMkernel Network Adapter as the portgroup type

Screen Shot 2013-11-27 at 09.25.39.png

3. Ensure that vSwitch0 is the existing standard vSwitch

Screen Shot 2013-11-27 at 09.26.10.png

4. In the connection settings type a friendly portgroup name, and if required a VLAN tag value. In this case no special services are required

Screen Shot 2013-11-27 at 09.27.28.png

5. In most case organizations prefer a static IP configuration for something as critical as the hosts access to storage

Screen Shot 2013-11-27 at 09.28.29.png

6. Click Next and Finish.

Note: Repeat steps 1 to 6, this type specifying a different IP address for the second portgroup. This should give the Standard vSwitch two portgroups with two vmkernal ports calledd IPstorage1 and IPstorage2 each with vmkernel adatper identity of vmk1 and vmk2, with vmk0 being used as the management IP configuration.

Screen Shot 2013-11-27 at 09.38.51.png

Step Two: Reconfigure the Network Adapter Teaming on the Portgroups

Next we need to adjust the way the physical NICs are utlized on the portgroups. This is a good illustration of how flexible networking is in vSphere. Not only can we have generic teaming settings on the Standard vSwitch we can have settings which are specific to portgroups as well.

1. Select the portgroup link in the web-client, and click the Edit Setting button

Screen Shot 2013-11-27 at 10.03.16.png

2. Select the Teaming and Failover option

3. Enable the option to X Overide the default settings of the Standard vSwitch

4. Use the downward arrow to move vmnic1 to the Unused Adapters location

Screen Shot 2013-11-27 at 10.10.00.png

5. Click OK to confirm your changes

Note: Repeat steps 1 to 5 to reconfigure the second portgroup (in this case IPstorage2/vmk1) with inverse network adapter configuration with vmnic1 being active and vmnic0 set to be an “Unused Adapter”

Screen Shot 2013-11-27 at 10.19.17.png

Note: You can confirm your configuration by using the small (i) icon on the properties of a portgroup, rather opening the edit settings dialog every time…

Screen Shot 2013-11-27 at 10.23.04.png

Creating an VMkernel Port for VMotion

1. Select vSwitch0 (or create a new vSwitch), and click the Add Host Networking button

2. Select VMkernel Network Adapter as the portgroup type

Screen Shot 2013-11-27 at 09.25.39.png

3. Ensure that vSwitch0 is the existing standard vSwitch

Screen Shot 2013-11-27 at 09.26.10.png

4. In the connection settings type a friendly portgroup name, and if required a VLAN tag value.

5. Under Available Services, enabled the option X vMotion Traffic

Screen Shot 2013-12-13 at 14.44.38.png

6. Next configure a static IP address for the vMotion Traffic

Screen Shot 2013-12-13 at 14.46.31.png

Note: In order for vMotion to work, all the those need to be patched to the vMotion network, and configured with a valid IP address. This is generally a dedicated network with bandwidth allocated of 1Gps or higher. You can validate if vMotion has been enabled by checking the “Configuration” pane on the Summary Tab of an ESX host.

Screen Shot 2013-12-13 at 14.50.33.png

Creating an VMkernel Port for Fault Tolerance

VMware Fault-Tolerance (FT) is feature that allows all the activity taking place in one VM to mirror to a second VM on a different ESX host. In this situation the VMs are considered to be held in a “lock step”. Should the “Primary” VM fail, then the “Secondary” VM instantaneously takes over. One requirement for FT to work is a dedicate network which can provide 1Gps or higher bandwidth. FT is covered in greater detail in the High Availability section of the vmWIKI.

1. Select vSwitch0 (or create a new vSwitch), and click the Add Host Networking button

2. Select VMkernel Network Adapter as the portgroup type

Screen Shot 2013-11-27 at 09.25.39.png

3. Ensure that vSwitch0 is the existing standard vSwitch

Screen Shot 2013-11-27 at 09.26.10.png

4. In the connection settings type a friendly portgroup name, and if required a VLAN tag value.

5. Under Available Services, enabled the option X Fault Tolerance Logging

Screen Shot 2013-12-13 at 14.58.11.png

6. Next configure a static IP address for the Fault Tolerance Traffic

Screen Shot 2013-12-13 at 15.03.22.png

Note: You can validate if FT has been enabled by checking the “Configuration” pane on the Summary Tab of an ESX host. However, other requirements must also be met for this to be flagged as Yes. Firstly, the physical host must support the correct CPU chipset requirements, and the ESX host most be part of VMware High-Availability cluster. In the screen grab below a VMware High Availability cluster has been created.

Screen Shot 2013-12-13 at 15.15.28.png

Creating an VMkernel Port for Management/VMware HA Heartbeat

In order for VMware High-Availability to function without errors redundancy must be delivered to the management network. This ensure scenarios like “Split Brain” where two or more hosts consider each other as “down” because they have become unreachable across the network – are unlikely to happen. Network redundency could be provided by furnishing the management vSwitch with two VMnic plugged into two independent physical switches or by adding a second management network to different vSwitch to the one mainly used for Management

1. Select vSwitch0 (or create a new vSwitch), and click the Add Host Networking button

2. Select VMkernel Network Adapter as the portgroup type

Screen Shot 2013-11-27 at 09.25.39.png

3. Ensure that vSwitch0 is the existing standard vSwitch

Screen Shot 2013-11-27 at 09.26.10.png

4. In the connection settings type a friendly portgroup name, and if required a VLAN tag value.

5. Under Available Services, enabled the option X Management Traffic

Screen Shot 2013-12-13 at 15.20.28.png

6. Next configure a static IP address for the Management Traffic

Screen Shot 2013-12-13 at 15.22.07.png

Note: There is no special way of checking you have redundency to the management network – but VMware HA will warn you if it detects redundancy isn’t present.

Configuring Standard vSwitch Settings

Standard vSwitch support a rich array of different configuration settings together these settings could be regarded as policy. The settings can be on the vSwitch itself, or on the portgroups. A system of “over-rides” exists such that the vSwitch could have setting Y, but the portgroup would have setting X. This allows for scenario where you have rules, and exceptions to those rules. These setting extend to include functionality such as performance, security, traffic management and NIC Teaming and Failover parameters.

Settings on the vSwitch can be modified by selecting the ESX host and the vSwitch, and clicking the “pencil” icon to Edit Settings.

Screen Shot 2013-12-13 at 15.30.59.png

What follows below is explanation of each of the settings with examples of situations which would merit their modification:

Maximum Transmission Unit (MTU) aka Jumbo Frames

Screen Shot 2013-12-13 at 15.33.13.png

The MTU value (aka Jumbo Frames) controls the size of the Ethernet frame on the network. Increasing this value, increases the MTU allowing the Ethernet Frame to carry more real data for the same overhead. In some circumstances supporting a larger MTU can improve performance. Care must be taken when increasing beyond the default of 1500 Bytes. The physical switch must be reconfigured to support the large MTU size – additionally performance can be degraded if a large MTU ethernet frame encounters a device configured for a smaller MTU size. The subsequent packets are fragmented into a stream of smaller packets. There has been some debate as to whether the benefits of a large MTU makes a great deal of difference in 10g environments, and if the administrative penalty of enabling the feature is smaller than the perceived performance improvements. This complexity increases if your intention is not to just provide a large MTU to the ESX network traffic but to the virtual machines as well. Generally, performance does improve – and Michael Websters (VCDX) blogpost “Jumbo Frames on vSphere 5” is good starting point in understanding the benefits. For instance MTU could be enabled on desecrate communication for traffic such as vMotion or IP-Storage where the benefits may be more immediately realised.

Security Settings

Screen Shot 2013-12-13 at 15.43.53.png

WARNING:

Consistency is king. If two ESX hosts have different security settings this can cause functions like vMotion to break. All vSwitch and Portgroup ship with standard security settings called Promiscuous Mode, MAC Address Changes and Forged Transmits – these configured by default as Reject, Accept and Accept. It would be more secure to set all these options as reject – however care must be taken to not over tighten the security screws and unintentionally break process running inside the guest operating systems within the virtual machines.

By default Promiscuous Mode is set to reject – and this prevents packet capturing software installed to compromised virtual machine for being used to gather more network traffic to facilitate a hack. Nonetheless it could modified by a genuine network administrator to capture packets as part of network troubleshooting. Even with this option enabled it would not stop an administrator from receiving packets to the VM. Another reason to change this option to Accept if you want to run intrusion detection software inside a VM. Such intrusion detection needs to be able to sniff network traffic as part its process of protecting the network. Finally, a less well-known reason for loosening the security on promiscuous mode is to allow so called “Nested ESX” configurations. This is where ESX is installed into a VM. This generally done in homelab and testing environments, not generally recommended for production use.

MAC Address Changes and Forged Transmits are both related to MAC address. Certain availability allows the guest operating system to send out traffic even if the traffic is being sent using a MAC address that is different from the one assigned virtual machine. This can happen in certain clustering environments such as Microsoft NLB or Microsoft Clustering Services (MSCS) where a “virtual IP” address is assigned a “virtual MAC” address to allow inbound/outbound access to the cluster. Configuring Reject for MAC Address Changes and Forged Transmits would cause such software to malfunction, as such the setting is compromise between security and usability.

Traffic Shaping

Screen Shot 2013-12-13 at 17.25.40.png

By default traffic shaping is disabled on both the vSwitch and the portgroup. Once enabled it allows the administrator to control bandwidth used as exits the physical server. Traffic Shaping does not control traffic as enters the server, and for this reason many organization do not consider it advantag

NIC Teaming and Failover

Screen Shot 2013-12-13 at 16.15.53.png

The NIC Teaming and Failover settings control a rich array of possible configurations and options. Load-Balancing supports four different options including (1) Route based on IP Hash, (2) Route based on MAC Hash, (3) Route based on Originating Port and (4) Use explicit failover order. Route based on originating port essentially load-balancing controlled by a round-robin on the teamed network interfaces, and is the default because its highly compatible with many physical switch configurations. Route based on IP Hash is consider the most optimal for performance . However, for this method to function the physical switches must be enabled for the 802.3 (AD) Link Aggregation standard and IP data is used to select the best physical NIC with which to send the traffic. Although a load is placed on all the NICs the maximum throughput is limited to the maximum transfer of the given physical NIC.

With the Explicit Failover Order option it is possible mark on VMnic as Active and another as Standby. Such a configuration looks like this:

Screen Shot 2013-12-13 at 16.31.03.png

This option works in conjunction with the Failback option of Yes/No. With Failback set to Yes. If VMnic0 failed, VMnic1 would take over – when VMnic0 became available then traffic would failback (return to) the Active NIC. If the setting is changed to No, even if the Active NIC becomes available again – the traffic stays with the vmnic1 device until such time that it experiences a failure. Such a configuration guarantees dedicated allocation of bandwidth and is highly reliable. However, its is an uncommon configuration as many consider dedicating a NIC into a standby mode a waste of precious bandwidth. A configuration where all the physical vmnics are marked as Active looks like this from the web-client

Screen Shot 2013-12-13 at 16.41.41.png

Whereas a Active/Standby configuration is represented like so – with the yellow line indicating which vmnic is taking the network load currently:

Screen Shot 2013-12-13 at 16.40.02.png

Network Failover Detection controls how VMware ESX discovers that a physical network path is unavailable. It supports two options Link Status Only and Beacon Probing. Link Status Only merely checks the NIC and its primary connection to the physical switch. It cannot validate if further upstream paths are valid. In contrast Beacon Probing sends out a discover packet to check the state of the networking. In theory it is a more intelligent method of detecting the true state of the network. However, in practise many switching architectures including those from Cisco often don’t benefit from the use of beacon probing. Consult your switching vendors best practises and recommendations before enabling beacon probing.

Notify Switches this option when set to Yes, sends out a reverse ARP (RARP) packet which helps keep the physical switch aware of changes occurring in the network. Typical leaving the default in place is the best practise as it helps with the vMotion process when VMs are being moved across the network. Although the virtual MAC address of the VM does not change when it is moved from one host to another – the MAC addresses of the physical world certainly are different from one ESX to another. Microsoft NLB software when configured in a unicast mode is incompatible with Notify Switches set to Yes. If Microsoft NLB is configured with multi-cast functionality then this is not a problem. Therefore if you are using Microsoft NLB within a VM using Multi-cast is recommended. Alternatively, a portgroup can be created merely for the Microsoft NLB cluster with the Notify Switches set to No.

Configuring Standard Portgroup Settings

The settings of a portgroup can be access by selecting the underlined text of the portgroup, and clicking the “pencil” icon to edit the settings:

Screen Shot 2013-12-13 at 17.08.51.png

Many of the portgroup settings are exactly the same as the settings found on the vSwitch. The only difference is that effect only the virtual machines or vmkernel traffic configured for those portgroups. For example the security settings on a portgroup are exactly the same as the vSwitch – and merely allow the administrator to over-ride the settings from the vSwitch. Nonetheless there are some settings that are unique to the portgroup that may require reconfiguration dependent on the organizations requirements.

Screen Shot 2013-12-13 at 16.59.30.png

Note: Here the security settings on the portgroup are the same as can be found on the vSwitch. Notice the “override” options which allow portgroup settings to act as an “exception to the rule” that is found on the vSwitch.

VLAN Tagging Settings

Screen Shot 2013-12-13 at 17.07.40.png

VLAN Tagging is the Standard vSwitches primary method to support the access of many VLANs on a physical switch with a small number of physical interfaces required on the ESX host. VLAN Tagging enabled when a portgroup is defined. However, thought operator error the wrong VLAN Tag may have been assigned, and so it can be modified after the wizard has completed. The portgroup also supports the use of VLAN ID 4095. This is required when enabling “Virtual Guest Tagging” (VGT). This is where the tagging takes place inside the guest operating system running within the virtual machine. VGT isn’t a common configuration as it essentially “turns off” the ESX tagging process in favour of one managed by the virtual machine. However, there certain circumstance where this is desirable. For example if you are running a virtual appliance that acts a firewall – it maybe easier to manage the VLAN configuration within the firewall management software than using VMware ESX. Another more tangental use case is when “Nested ESX” is being used. This when VMware ESX has actually being installed into a virtual machine. This generally used in lab and testing environments to save on hardware costs. In order for the VLAN Tagging function to work within the Nested ESX environment, VGT is required.

Network Protocol Profiles (IP Pools)

vSphere introduced contains profile type referred to as “Network Protocol Profiles”. The profile contains a feature which has been present in vSphere for some years, namely IP Pools. IP Pools allow the administrator define a range of available IPv4 and IPv6 IP addresses. This is often leveraged by multi-VM appliances distributed in the “vApp” format. IP Pools are optional, but they do often easy the process of deploying multi-VM appliance some of which are available from VMware including Horizon Suite and vCenter Operations Manager. It is fair to say that not all virtual appliance are enabled for IP Pools – it depends on the vendor.

Thus a vSphere Administrator has many ways to set the IP address for given number of VMs including:

  • DHCP on the same network as the VM
  • Statically configured inside the Guest Operating System
  • Statically configured during the “Guest Customization” of the VM when deploying from a template
  • IP Pools

By default vSphere ships with a default network protocol profile called the “Management Protocol Profile”, and is associated with a portgroup – in our case the “Management” virtual machine portgroup. To modify it so it supports an IP pool follow these setups:

1. Navigate to the Networking view, and select the datacenter – under Manage tab select the Network Protocol Profile column

Screen Shot 2014-04-28 at 14.18.31.png

2. Select the pencil icon to edit the Management Practical Profile and select the Configure IPv4 option

Screen Shot 2014-04-28 at 14.20.36.png

3. Type in the Subnet ID that is valid for this network, in our case this was 10.20.0.0/16. If a DHCP server operates on the same network enable the option to indicate that DHCP Server is present. Add additional DNS servers to indicate your primary/second DNS servers. Enable the IP Pools, and specify an IP Pool Range – this is done by specifying an starting IP followed by the # character followed by the number of IP addresses required.

Screen Shot 2014-04-28 at 14.29.56.png

The option to use a management pool will appear in the “Setup Network” part of importing an OVA/OVF template into vCenter. In this case vCenter Operations Manager (vCOPS) was deployed as an example. Here the option “Transient – IP Pool” is used to acquire an IP address from the IP Pool, and have it statically assigned to the VMs that make up the vCOPS appliances. If the administrator selected from list “Static – Manual” the import wizard would change to allow the administrator to assign a static IP address to each VM in the OVA/OVF template

Screen Shot 2014-04-28 at 14.53.05.png

Creating Standard vSwitch (PowerCLI)

Creating an Internal Standard vSwitch

Screen Shot 2013-10-21 at 14.01.16.pngInternal Standard vSwitch:

Foreach ($vmhost in (get-vmhost))
{
$vswitch1 =  New-VirtualSwitch -VMHost $vmhost -Name vSwitch1
New-VirtualPortGroup -VirtualSwitch $vswitch1  -Name IsolatedNetwork
}
Creating an Basic Standard vSwitch

Screen Shot 2013-10-21 at 14.01.16.pngBasic Standard vSwitch:

Foreach ($vmhost in (get-vmhost))
{
$vswitch2 =  New-VirtualSwitch -VMHost $vmhost -Name vSwitch2 -Nic vmnic1 
New-VirtualPortGroup -VirtualSwitch $vswitch2  -Name BasicConnectivity 
}

Note: Previous editions of VMware ESX would also require the -NumPorts parameter to indicate the number of ports on the vSwitch. This setting is no longer significant in vSphere 5.5 since Standard vSwitch support the “elastic” creation of ports on demand.

Creating an Teamed Standard vSwitch with VLAN Tagging

Screen Shot 2013-10-21 at 14.01.16.pngTeamed Standard vSwitch with VLAN Tagging:

Foreach ($vmhost in (get-vmhost))
{
$vswitch3 =  New-VirtualSwitch -VMHost $vmhost -Name vSwitch2 -Nic vmnic2,vmnic3 
New-VirtualPortGroup -VirtualSwitch $vswitch3  -Name VLAN12  -VLanID 12
New-VirtualPortGroup -VirtualSwitch $vswitch3  -Name VLAN13  -VLanID 13
New-VirtualPortGroup -VirtualSwitch $vswitch3  -Name VLAN14  -VLanID 14
New-VirtualPortGroup -VirtualSwitch $vswitch3  -Name VLAN15  -VLanID 15
}

Note: Previous editions of VMware ESX would also require the -NumPorts parameter to indicate the number of ports on the vSwitch. This setting is no longer significant in vSphere 5.5 since Standard vSwitch support the “elastic” creation of ports on demand.

Adding a new VLAN Portgroup to an existing Standard vSwitch

Screen Shot 2013-10-21 at 14.01.16.pngAdd new VLAN Portgroup to existing Standard vSwitch:

Foreach ($vmhost in (get-vmhost))
{
$vswitch3 =  Get-VirtualSwitch -VMHost $vmhost -Name vSwitch3
New-VirtualPortGroup -VirtualSwitch $vswitch3  -Name VLAN16  -VLanID 16
}
Adding a range VLAN Portgroups to an existing Standard vSwitch

Screen Shot 2013-10-21 at 14.01.16.pngAdd new VLAN Portgroup to existing Standard vSwitch:

This PowerCLI script uses a range to add portgroups named VLAN20 to VLAN25 on to vSwitch0 each with the VLAN Tagging Value set accordingly

20..25 | Foreach {
$Num = $_

(Get-VMHost | sort-object name) | foreach {
 New-VirtualPortGroup -VirtualSwitch (Get-VirtualSwitch -Name vSwitch0 -VMHost $_) -Name VLAN$num -VLanId $num
  }
}
Creating a Teamed Standard vSwitch for Load-Balanced iSCSI communications

Screen Shot 2013-10-21 at 14.01.16.pngTeamed Standard vSwitch for iSCSI Communication:

In this case a .CSV file is configured with the unique IP addresses used for IP Storage Communication

Screen Shot 2013-12-16 at 18.43.28.png

Using the import-csv cmdlet the variables of vmhost, storage0ip and storage1ip are read. They are then referenced in a ForEach-Object loops that configures each VMware ESX.

Import-CSV vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
$ipstorage0 = $_.storage0ip
$ipstorage1 = $_.storage1ip

 $vswitch4 =  New-VirtualSwitch -VMHost $hostname -Name vSwitch4 -Nic vmnic2,vmnic3
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch4 -PortGroup IP-Storage0 -IP $ipstorage0 -SubnetMask 255.255.255.0
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch4 -PortGroup IP-Storage1 -IP $ipstorage1 -SubnetMask 255.255.255.0 
 Get-VirtualPortGroup -VMHost $HostName -VirtualSwitch $vswitch4 -Name IP-Storage0 | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic2 -MakeNicUnused vmnic3 
 Get-VirtualPortGroup -VMHost $HostName -VirtualSwitch $vswitch4 -Name IP-Storage1 | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic3 -MakeNicUnused vmnic2
}
Modifying a Teamed Standard vSwitch for Load-Balanced iSCSI communications

Screen Shot 2013-10-21 at 14.01.16.pngModifying Teamed Standard vSwitch for iSCSI Communication:

In this case a .CSV file is configured with the unique IP addresses used for IP Storage Communication

Screen Shot 2013-12-16 at 18.43.28.png

In this Get-vSwitch, Get-VMhost, and Get-VMHostNetworkAdapter are used to retrieve the details of vSwitch0. Then the cmdlet Add-VirtualSwitchPhysicalNetworkAdapter is used to add vmnic1 to vSwitch0. This used to be done with Set-VirtualSwitch -nic but this method has since become depreciated. This something to watch out for as you upgrade from one flavour of vSphere to another – PowerCLI can and does change, and that does sometime necessitate the gradual removal of redundant methods that are no longer needed.

Screen Shot 2013-12-17 at 10.08.42.png

Import-CSV vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
$ipstorage0 = $_.storage0ip
$ipstorage1 = $_.storage1ip

 $vswitch0 =  Get-VirtualSwitch -VMHost $hostname -Name vSwitch0
 $vmnic1 = Get-VMhost $hostname | Get-VMHostNetworkAdapter -Physical -Name vmnic1
 Add-VirtualSwitchPhysicalNetworkAdapter -VirtualSwitch $vswitch0 -VMHostPhysicalNic $vmnic1 -confirm:$false
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch0 -PortGroup IP-Storage0 -IP $ipstorage0 -SubnetMask 255.255.255.0
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch0 -PortGroup IP-Storage1 -IP $ipstorage1 -SubnetMask 255.255.255.0 
 Get-VirtualPortGroup -VMHost $HostName -VirtualSwitch $vswitch0 -Name IP-Storage0 | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic0 -MakeNicUnused vmnic1 
 Get-VirtualPortGroup -VMHost $HostName -VirtualSwitch $vswitch0 -Name IP-Storage1 | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic1 -MakeNicUnused vmnic0
}
Creating an VMkernel Port for VMotion

Screen Shot 2013-10-21 at 14.01.16.pngVMotion Configuration:

In this case a .CSV file is configured with the unique IP addresses used for VMotion

Screen Shot 2013-12-16 at 18.43.28.png

In this case cmdlet Add-VirtualSwitchPhysicalNetworkAdapter is used to enable VMotion on a portgroup called VMotion.

Import-CSV vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
$vmotion = $_.vmotionIP

 $vswitch0 =  Get-VirtualSwitch -VMHost $hostname -Name vSwitch0
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch0 -PortGroup VMotion -IP $vmotion -SubnetMask 255.255.255.0 -VMotionEnabled $true
}
Creating an VMkernel Port for Fault Tolerance

Screen Shot 2013-10-21 at 14.01.16.pngFT Configuration:

In this case a .CSV file is configured with the unique IP addresses used for FT.

Screen Shot 2013-12-16 at 18.43.28.png

In this case cmdlet Add-VirtualSwitchPhysicalNetworkAdapter is used to enable the Fault Tolerance attribute on a portgroup called FT. Remember for FT to work the VMware ESX host must be part of VMware High-Availability enabled cluster.

Import-CSV vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
$FT = $_.ftIP

 $vswitch0 =  Get-VirtualSwitch -VMHost $hostname -Name vSwitch0
 New-VMHostNetworkAdapter -VMHost $hostname -VirtualSwitch $vswitch0 -PortGroup FT -IP $FT -SubnetMask 255.255.255.0 -FaultToleranceLoggingEnabled $true
}
Creating an VMkernel Port for Management/VMware HA Heartbeat

Screen Shot 2013-10-21 at 14.01.16.pngHigh Availability Configuration:

In this case a .CSV file is configured with the unique IP addresses used for High Availability.

Screen Shot 2013-12-16 at 18.43.28.png

In this case cmdlet Add-VirtualSwitchPhysicalNetworkAdapter is used to enable the Management Network attribute on a portgroup called HA. Remember for FT to work the VMware ESX host must be part of VMware High-Availability enabled cluster.

NEED HELP!
Removing the Default “VM Network”

Screen Shot 2013-10-21 at 14.01.16.pngRemoving “VM Network:

Some administrator do not like to see the default “VM Network” that is created on the vSwitch0. It can be easily removed with a PowerCLI oneliner. If if this case – then its best done earlier in the configuration of the host before any administrator configures VMs to use it.

Get-VirtualPortGroup -Name "VM Network" | Remove-VirtualPortGroup -Confirm:$false

Source: http://www.mikelaverick.com/wiki/index.php?title=Configuring_Standard_Switches

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s