03.29.09
The Great vSwitch Debate – Part 2
Table of Contents
- The Great vSwitch Debate – Part 1
In this post, I discuss vSwitch functions, Port Groups, VLAN tagging/trunking, valid communications paths, and some other basic vSwitch information. - The Great vSwitch Debate – Part 2
In Part 2, I cover the vSwitch security features (Promiscuous Mode, MAC Address Change, and Forged Transmits) as well as network traffic shaping options. - The Great vSwitch Debate – Part 3
Here I discuss the various load balancing options that are available in a VMware vSwitch. - The Great vSwitch Debate – Part 4
In Part 4, I cover fault detection and the Cisco Discovery Protocol. - The Great vSwitch Debate – Part 5
In Part 5, I talk about the various networks that you have to contend with in an ESX environment as well as an approach to help in deciding which networks to combine, if you have to. - The Great vSwitch Debate – Part 6
I introduce the first host configuration. In this part, I talk about my recommendations for when you have eight pNICs and offer up a couple alternatives, including one for using an iSCSI initiator from within a VM. - The Great vSwitch Debate – Part 7
I discuss configurations for systems with two, four, and six pNICS. - The Great vSwitch Debate – Part 8
In this, the final article in the series, I discuss the importance of naming standards.
Part 2
This article is a continuation of the first in a series. See The Great vSwitch Debate – Part 1 for the beginning of the series.
In this Part Two of the series on vSwitch configurations, I want to address some of the advanced configuration options, but first – I need to go back and revisit the end of Part 1. There, I was discussing the routing of traffic between VMs on the same and different port groups on a single vSwitch. I presented the figure below (Figure 1) to describe what I was talking about.
Figure 1. Port Group Communications Paths
The Great vSwitch Debate – Part 1
Table of Contents
- The Great vSwitch Debate – Part 1
In this post, I discuss vSwitch functions, Port Groups, VLAN tagging/trunking, valid communications paths, and some other basic vSwitch information. - The Great vSwitch Debate – Part 2
In Part 2, I cover the vSwitch security features (Promiscuous Mode, MAC Address Change, and Forged Transmits) as well as network traffic shaping options. - The Great vSwitch Debate – Part 3
Here I discuss the various load balancing options that are available in a VMware vSwitch. - The Great vSwitch Debate – Part 4
In Part 4, I cover fault detection and the Cisco Discovery Protocol. - The Great vSwitch Debate – Part 5
In Part 5, I talk about the various networks that you have to contend with in an ESX environment as well as an approach to help in deciding which networks to combine, if you have to. - The Great vSwitch Debate – Part 6
I introduce the first host configuration. In this part, I talk about my recommendations for when you have eight pNICs and offer up a couple alternatives, including one for using an iSCSI initiator from within a VM. - The Great vSwitch Debate – Part 7
I discuss configurations for systems with two, four, and six pNICS. - The Great vSwitch Debate – Part 8
In this, the final article in the series, I discuss the importance of naming standards.
Part 1
There are many articles out discussing “best practices” for configuring virtual switches (vSwitches) in a VMware Infrastructure 3 (VI3) environment – well, here’s the first in a series of articles that present vSwitch recommendations that conform to the rules of “Virtualization According to Ken”.
For purposes of clarity, unless otherwise specified, all discussion herein applies to both VMware ESX Server (ESX) and VMware ESXi Server (ESXi). When I want to make it clear that I’m referencing both, I’ll use the construct ESX/i.
First, let’s start out by defining exactly what a VMware vSwitch is: Read the rest of this entry »
03.09.09
When is it OK to default on your VI?
I’ve noticed something about engineers. They’re never happy with the way something is configured out of the box – there’s always a better way! Well, I have a different philosophy:
“If you don’t have a very good reason to change a default value, don’t change it!”
To me, this seems totally obvious – in most cases, the default values are there for a reason.
Reaction to “Say it isn’t so: Hyper-V and XenServer outperform ESX”
Jason Boche posted an interesting article on his blog today, and I thought I’d offer my thoughts on it.
First, here’s the article from Virtualization Review magazine that started all this furor!
My guess is that part of the difference comes from both Hyper-V & Xen requiring VT capable CPUs (i.e. the VM always runs within a VT jail) while ESX supports binary translation (BT) for some 32-bit x86 instructions. The first generation of chips that supported VT weren’t very good, and VMware’s BT would often do a better job of executing the protected instructions than the hardware assist provided by the CPU. Intel has gotten better in the hardware support for virtualization which is shown in the subject test.
My FIRST Blog Post
OK, so all my friends have been trying to get me to start blogging – here goes!
We’ll start with some background on me. That will help you decide whether there’s any reason to believe what I post here.
I’ve been using technology to help get the job done since I was in high school. Back then, I was working on a (then antique!) IBM 402 accounting machine – and yes, I did ‘program’ them with those control panels!
