So, one particularly interesting session I attended was TA2275, which basically involved the speaker, a crystal ball and the future of Virtual Networking in ESX. The content was set into two parts – what we can expect in the immediate future and then some speculation about where things are probably going for the future.
Immediate Horizon
On the immediate stage, VMware has rebranded the entire virtual networking layer into something they call vNetwork – which is their overall name for the “distributed virtual networking platform.” Past the branding, vNetwork will be bringing us some particularly cool new capabilities.
- Mobility awareness
- Abstract the control interfaces from the data being transported
- Provides an extensible framework
- Introduces the Distributed Virtual Switch (more on this further below)
- Allows for stateful vSwitch ports which transfer between ESX hosts
- Is where VMsafe will be implemented
- Allows for Third Party switches and appliances (both virtual and physical)
The biggest announcement for networking in VMworld ’08 is the introduction of the Distributed Virtual Switch. Gone are the days of managing each ESX vSwitch individually. Most ESX hosts have the exact same vSwitch config as the next host, so VMware is introducing a higher level of configuring the vSwitches. Distributed Virtual Switches allows for an overall vSwitch design to be created at the host level and then applied to each ESX host individually from a central console. Thank goodness I no longer need to add the same VLAN portgroup to each of my 8 hosts in the corporate cluster… I can do it with one click on the Distributed vSwitch. DVSwitches and DVPortGroups will be defined in the cluster and can be applied to different vmNics on each host. This was one of my biggest feature wants…
The vNetwork architecture will be a set of API’s which can be leveraged by partners and implemented with both their network and security devices. There will be two types – Forwarding Engines and Filters. The Forwarding Engines are the vNetwork Switch API’s, Filters the vNetwork Appliance API’s.
vNetwork Switch API’s allow vendors, like Cisco, to write their own switch implementations which supercede the default VMware vSwitch. Implementing a Cisco vSwitch would allow your Cisco network engineer to interact with the Cisco vSwitch the same way he/she interacts with their physical Cisco switches – same CLI, everything. In addition, because its built on the vNetwork Forwarding Engine API’s, the ESX administrator can interact with the Cisco vSwitch the same way he/she would interact with the default VMware vSwitch implementation. This is all accomplished by allowing network vendors to create and register their own data types within the framework. The vendor defines what is important to them and then is able to utilize this data within the framework.
Cisco, coincidentally, introduced its first vSwitch implementation during the conference – the Cisco Nexus 1000v.
The VMsafe initiative comes to life as the Filters. Filters use vNetwork Appliance API’s, previously known as VMsafe-net, to implement both physical and virtual IPS/IDS, firewalls, and antivirus appliances that can interact with the virtual datacenter. vNetwork Appliance API’s allow for state to be passed as necessary as app server vMotions occur and as appliances move as well.
Because the appliances are implemented at this lower level, there are no agents to install on the hosts to allow the appliances to do their job. By interacting with the API at this level, security services and sniff and watch the traffic or activity of a virtual machine, analyze and take action as necessary. Also, because these appliances are built within the VMware frameworks and constructs, they are assured future compatibility with the platform.
Longer View
In the longer view, which is mostly speculation and not any particular feature on the horizon, we can expect that more of the networking infrastructure will be collapsed in to the virutal environment.
As the virtual datacenter becomes more substantial than the physical datacenter, we will see more network services push onto the virtual – things like quality-of-service move onto the virtual and away from the physical switches. And the physical switches become basically just transport.
By virtue of the API’s, there will be less separation between the physical and virtual and the two would interact together very fluidly. Physical switches may become more tightly bound to the hypervisor to provide intelligent features.
