Four non-distributed vswitches

What is the vswitch strategy in your environment? Undoubtedly, server virtualization is an inevitable trend. If you are a Network Professional and you are working in an enterprise that does not need to cope with multiple virtual machines, I think you should look for a new environment. Few environments do not use DNS, LDAP, or DHCP to virtualize servers. As the virtualized server environment matures, their virtualized network environment also changes.

In most environments, the number of physical hosts running virtual machines and their vswitches is inevitably increased from one server to two, three or even a dozen physical servers. If your plan is not well thought out, you will eventually face the situation that dozens of dummies in the data center cannot be bound to your network management infrastructure and tools. This turns troubleshooting into a nightmare or impossible task. What happens when you need to obtain Cisco Netflow data from this pile of devices? What IP Address Should you point? Which ports are connected to these virtual machines? What happens if a virtual machine moves from one host to another?

You can refer to this article as an introduction to vswitches to network personnel who are not involved in x86 server virtualization. This article describes four major management programs and their vswitches. The four hypervisor programs are VMware vSphere, Microsoft Hyper-V, Citrix XenServer, and kernel-based Virtual Machine (KVM ).

Distributed and non-distributed vswitches

Vswitches are divided into two types: distributed and non-distributed. A non-distributed switch is a virtual switch that has many-to-one switches to the server relationship. A Distributed switch is a one-to-multiple switch to the server. Compared with distributed switches, non-distributed switches are simpler and have fewer functions. In addition, non-distributed switches do not need to be considered from the management perspective during deployment. If there is no interaction or collaboration between the Network Team and the server team in your environment, there may be many non-distributed switches in your environment. Even worse, you have a bunch of distributed switches that are not integrated into the physical network. Not all configuration standards need to be applied to the virtual distributed switch, but these standards must be taken into account when creating baseline configurations.

Non-distributed VMware vSphere vSwitch

VMWare vSphere cannot be ignored for virtualization. VSphere's default switch is called vSwitch, which is a non-distributed switch of VMware. A physical host can have multiple vswitches. A vSwitch is a basic function, similar to a physical "Stupid switch" with few management functions ".

VSphere has two distributed switch options. VWware has a powerful distributed switch that supports NetFlow and port ing across multiple management programs. Only vSphere supports Cisco Nexus 1000 v and v supports all management functions of most physical switches.

Non-distributed Microsoft Hyper-V Switch

It is said that Hyper-V only supports standard non-distributed switches. Similar to VMware's vSwitch. However, Windows Server 2012 always runs the Nexus 1000 v test version.

Open-source KVM/XENServer

Both KVM and XENServer are Open-source management programs and support Open vSwitch. Some of you may understand Open vSwitch as an Open-source switch software that runs on commercial hardware, but now the Open vSwitch function has been extended to serve as a virtual distributed switch.

Open vSwitch provides cross-management program connection options for these Open-source management programs, which is the same as that provided by VMware distributed switches to vSphere, including running a virtual switch across multiple hosts, allows virtual machines to move between hosts and maintain them on the same switch port. Both management programs support traditional non-distributed vswitches. Interestingly, XenServer 6.0 defaults to Open vSwitch.

In general, when you develop a vswitch deployment policy, you should spend time discussing network options with your x86 virtualization team.