服务器虚拟化在数据中心领域中正得到越来越广泛的实际应用。经济因素与这一趋势密不可分。服务器虚拟化可减少服务器的数量，所需的制冷能力和功率都更小，同时也大幅增加了灵活性，因此可以有效地降低总体拥有成本(TCO)。对于业务和服务器团队而言，这的确是好消息，但对于网络的管理来说，它又会产生怎样的影响呢？事实情况是，它会使网络管理变得更加复杂。

　　服务器虚拟化会牵涉到两项重大的网络问题。首先是虚拟局域网(VLAN)的配置问题。网络管理者必须确认当物理服务器运行虚拟机时，同样的交换机端口也被分配给了虚拟机使用的虚拟局域网。

　　解决方法之一是，服务器虚拟化团队将虚拟机可能启动的每一台服务器告诉网络管理团队，并且对交换机端口进行预先配置。但这并不是理想的解决方案，因为这将导致在很大比例的交换机端口上定义VLAN。由于服务器团队可能并不清楚镜像启动时所用的所有服务器，特别在灾难恢复情况下他们要采取紧急措施的时候，情况将变得更加复杂。

　　第二个问题是指定服务质量(QoS)和执行网络协议，例如访问控制列表(ACL)。传统上，这项工作是在与应用所运行的服务器相连的网络交换机上完成的。当有了服务器虚拟化后，就出现了运行在物理服务器的Hypervisor下的软件交换机，而非传统意义上的连接到物理服务器的物理网络交换机。

　　在软件交换机上执行协议还是很重要。例如，有两台虚拟机，我们本意是这两台虚拟机相互通信，但如果有人控制了虚拟机1，便可以打开与虚拟机2的连接并盗取数据。而我们如果对服务器上的软件交换机实施了访问控制列表，这种入侵活动便可被阻止。

　　在虚拟化之前，此类行为一般都可阻止，由于虚拟机1和虚拟机2运行在不同的服务器上，因而可以通过在网络交换机上定义访问控制列表来阻止这种通信。在软件交换机上执行这种协议可以保持安全性。但问题在于，如何让软件来实施协议。

　　要想使服务器虚拟化顺利开展，克服这些挑战将至关重要。虚拟化厂商的应对之法。市场上有多家提供虚拟化解决方案的厂商，例如VMware、思杰、微软、红帽等。不过，Vmware的解决方案应用最为广泛，因此我们以它来举例说明。

　　在图1中，VMware的vCenter控制着虚拟流程并指导虚拟机应在哪里启动。Hypervisor控制着服务器和运行在物理服务器上的虚拟机。vSwitch是VMware提供的一种2层软件交换机。每台虚拟机都有一个虚拟网卡(vNIC)。vNIC使用的是来自虚拟化厂商的访问控制清单地址池，或者是企业建立和分配的访问控制清单地址。该图的目的并不是显示真实环境下所有可能的变化情况，它只是展示整个虚拟化流程是如何运转的。

　　步骤1是由服务器团队定义出虚拟机的所有网络特性和协议。操作员会告诉vCenter在步骤2中启动虚拟机2。该过程中，vCenter和服务器上的Hypervisor之间会互相传递多条消息，例如，vCenter会将网络协议信息推送给Hypervisor。在步骤3中，Hypervisor会为vSwitch配置正确的VLAN、QoS和协议信息。当虚拟机2上的应用开始发送包时，该协议会在vSwitch上实施(图1中的蓝点表示)。

　　这种方法解决了在vSwitch上实施协议的问题，但并没有解决网络交换机中的VLAN配置问题。虚拟化团队需要告诉网络管理团队，应在虚拟机开始发送流量之前，为VLAN配置交换机端口，这就要求进行快速协调或者对交换机进行预先配置。当虚拟化团队需要对虚拟机进行动态迁移时，协调问题会变得更加复杂。在移动服务器时，虚拟化团队需要与网络团队进行协调，而且网络团队需要在成功迁移后完全清除老交换机上的配置。

　　使用该方法最大的问题是，虚拟化和网络团队之间进行协调的工作量将很大。虚拟化团队必须对vCenter中的参数进行配置，例如VLAN编号、QoS和ACL等，而这些参数又是由网络团队控制的。这意味着服务器虚拟化团队和网络团队之间需要不间断的良好协调。VLAN或协议中的任何变化都必须立即反映到虚拟服务器配置中，而这其实意味着一个潜在的故障点。

　　另外一个值得担忧的问题是，网络团队难以了解vSwitch内部的工作情况。因为vSwitch处在vCenter的控制下，而非传统的网络管理软件。此外，对网络团队而言，虚拟机的透明度也极低。一些网络厂商已经要求vCenter将变化或者对变化的抽样调查通知给网络团队，并将其与传统的网络数据一同显示出来。这些方法在一定程度上解决了可视性的问题。