【IT168 技术】第一种方案是实现交换机与虚拟机管理软件的同步。BladeNetworks目前提供了一种在其交换机上运行的应用，而Force10公司的下一版操作系统也可以解决VLAN的配置问题。这两家公司的交换机会对vCenter进行查询，监测各种变化，也可以收到vCenter发出宣告变化的消息。如果交换机发现vCenter配置有变化，它会自动执行配置。虚拟化操作员不必与网络运营部门进行协调，因此能够使虚拟机的启动过程变得非常顺利。交换机查询间隔一定要小于一台虚拟机启动的时间，从而确保交换机能够以足够快的速度看到变化。在Force10的第一个版本中，它惟一监视的参数就是VLAN的参数。BladeNetwork则更进一步，根据vNIC或VM的UUID(通用唯一识别码)对网络交换机实施了全系列的协议。该解决方案仍然需要在vSwitch中实施协议。

第二种解决VLAN配置问题的方法是通过中间件协调控制虚拟机管理软件和交换机。例如，使用惠普或Juniper等厂商提供的协调软件，但这些软件只能在其原厂的交换机上运行。Scalent和CA等管理厂商也提供了自己的解决方案。在这种情况下，协调软件会与网络交换机和vCenter对话，并协调两个环境之间的配置变化。这种方法有一定的潜在优势，即能够广泛适用于众多交换机和虚拟化厂商。

第三种方案来自于思科。思科提供了一种称为"1000V"的软件交换机解决方案，用于替代vSwitch。1000V由两个组件组成：VSM(VirtualSwitchModule)是虚拟交换机模块，用于替代运行在Hypervisor内的vSwitch软件;VEM(VirtualElementManager)则用于配置和存储VSM网络协议。

首先根据虚拟机的UUID或vMAC地址，在VEM中对虚拟机的VLAN和协议进行配置。在步骤2中，vCenter启动一台新的虚拟机或移动一台虚拟机。在步骤3中，Hypervisor向VSM发出通知。接下来，VSM在第四个步骤中从VEM中提取协议信息。如果网络交换机属于Nexus产品线，它也可以从VEM中提取必要的VLAN和协议信息。至此，Hypervisor中的交换机和Nexus交换机都获得了处理虚拟机2的正确信息。当虚拟机2开始发送流量时，所有正确的协议都会在Hypervisor中的1000V交换机上开始实施。

思科方案的好处与第一种方法相同。如果将1000V与已经为虚拟化做好准备的Nexus交换机一同使用，那么就可以解决网络交换机中的VLAN问题。该方案的另一个好处在于，可以移动在网络管理软件的控制下的Hypervisor中的交换机，从而能够清楚地划分网络团队应担负的责任。当然，它也有不足的一面。目前，思科只能提供适用于VMware的解决方案，对于Xen和HyperV则无能为力。

第四种方法采用了一种以网络设备为中心的视角来解决问题。如附图3所示，在步骤1中，按照虚拟网卡在网络管理软件中对虚拟机进行了定义。在步骤2中，vCenter指导Hypervisor启动虚拟机。在第三个步骤中，Hypervisor会发送一个公告包，宣布它正在启动二号虚拟机。该公告中包含二号虚拟机的vNIC及其UUID。在步骤4中，交换机发现了该公告并发送其VLAN和其它协议信息的请求。接下来，交换机会向进入网络的任何流量实施这些协议。

该方案的重点是交换机只在网络交换机中实施协议，以蓝点表示，而不会在vSwitch中实施。交换机还会监视来自Hypervisor的消息，这些消息表明虚拟机是否移动。如果发现此类消息，交换机便会清除与该vNIC相关的VLAN和协议信息。使用该解决方案的厂商包括AristaNetworks、BladeandEnterasys，另外惠普和Juniper也在通过其协调方法使用该解决方案。Brocade等其它厂商也在计划提供该解决方案。ExtremeNetworks将该技术用于QoS和协议，但未用于VLAN。

这种方法努力想让虚拟化团队不再被牵连到网络协议的实施工作中来。然而，还有两个问题。首先是服务器虚拟化和联网团队仍然必须就VLAN的编号进行协调。目前，Enterasys可以向vSwitch自动提供VLAN编号，而Arista也计划在近期加入该功能。

这种方法最大的问题是，它没有在vSwitch上实施协议，因而使得同一服务器上的虚机之间的交通流量绕过访问控制列表和其它安全协议。为解决这一问题，Enterasys和Arista计划添加在vSwitch上实施协议的能力。

在未来，解决这一问题的办法之一是允许交换机做"180度急转弯"。这样，可对vSwitch进行配置，规定其将所有的流量，甚至包括虚拟机1至虚拟机2的流量，都直接发送给网络交换机。网络交换机接下来会实施协议并指定QoS。虚拟机1至虚拟机2的流量可以回传至vSwitch，由它将其发送至虚拟机2。