第一步是服务器部门定义用于虚拟机的所有网络特性和协议。操作者告知vCenter启动步骤2中的虚拟机2。这个过程包括vCenter和服务器上运行的管理程序之间的多个信息，其中一个将网络协议信息传递给管理程序。在步骤3中，管理程序用来配置带有正确虚拟局域网，QoS和协议信息的虚拟交换机（vSwitch）。当虚拟机2上的应用软件开始发送信息包，虚拟交换机上应用的协议就由蓝点来表示。

这个方法可以解决在第一个交换机上应用网络协议的问题，但是无法解决网络交换机中虚拟局域网配置的问题。虚拟化部门必须在虚拟机开始发送流量之前，告知网络管理部门在交换机端口上配置虚拟局域网，这需要快速的实现同步或者交换机必须事先进行配置。当虚拟化部门将虚拟机进行迁移时这种同步就演变的更加复杂。然后虚拟化部门必须与网络部门保持一致，因为网络部门要负责迁移服务器，网络部门还必须在成功迁移后清理老交换机上的配置。

与这种方式关系最大的是虚拟化部门和网络部门之间所需的协调一致性。虚拟化部门必须在由网络部门所控制的vCenter上配置参数，比如虚拟局域网数量，QoS和访问控制清单等。这意味着在服务器虚拟化部门和网络部门之间必须具备良好的协调性。虚拟局域网或者协议发生任何变化都必须立即在虚拟服务器配置上反馈出来，否则会导致其他可能的故障点。

另一个相关问题就是网络部门部署的网络组件虚拟交换机缺乏透明度。虚拟交换机是在vCenter的控制下，而不是传统网络管理软件的控制下。另外，网络管理团队对虚拟机的认知度不高。这种透明度问题可以由几家网络厂商来解决，让vCenter通知网络团队所发生的变化或者对变化进行轮流检测，然后将这些信息和传统的网络数据一起展示出来，这对问题的判断帮助很大。

第一个解决方案

Blade Networks目前有一款可以在其交换机上运行的应用软件，Force10的新版本可以解决虚拟局域网的问题。交换机会检测vCenter来寻找任何发生的变化，或者有选择的倾听vCenter来发送宣布这种变化的信息。如果交换机发现了任何变化，就会自动执行配置。虚拟化操作者不必在网络运行中协调这种变化，帮助虚拟机顺利运转。轮流检测的间歇期必须小于启动虚拟机来确保交换机快速发现这种变化的时间。

在Force10的第一个版本中，所监控的唯一参数就是虚拟局域网。Blade Network后来进一步将全系列的洗衣都应用在以虚拟网络接口卡或者虚拟机的UUID为基础的网络交换机上。这种解决方案仍然需要在虚拟交换机上执行协议。

解决配置问题的第二种方法是使用来自惠普和Juniper这种公司的协调软件，他们的软件可以在他们自己的交换机上使用。

还有来自Scalent和CA公司这种管理软件厂商的解决方案。在这种情况下，协调软件会协调网络交换机和vCenter之间的通信，协调这两种环境之间配置的变化。这种方法潜在的好处是适用于大范围的交换机和虚拟化厂商。

更多请关注《DoSERV分析：服务器虚拟化的黑暗面（一）》
《DoSERV分析：服务器虚拟化的黑暗面（三）》
《DoSERV分析：服务器虚拟化的黑暗面（四）》