Posted by: MikeLaverick
Struggling to find the real session name for this one, I left early because I spotted my pal, Charles Gautreaux leaving the hall (Charles invited me to North Carolina this year to open his VMware User Group Summit)…
This session was all about the new network layer which we will see in Vi4. It was all about a concept called a “Distributed Switch”. From ESX1.x.x to ESX3.x.x the virtual switch configuration was “host” specific. That is to say we had to configure each and every ESX host to have matching network configurations right down to port group names and security settings. A distributed switch is part of the new vNetwork platform – and introduces a layer of networking which actually spans ESX hosts. When you create a distributed switch is create across the datacenter/cluster and is usable by any ESX host – and you can set globally wide settings with such as VLAN settings. The key thing remember about distributed vswitch is that they are more than just tatooing or pushing out your regular vSwitch configuration from a central source.
Of course we will still be able to configure hardware specific, ESX host specific settings on these switches using “Host Profiles”. The host profile is a collection of popular settings for an ESX host. You can copy, paste and modify host profiles to reflect specific requirements to the ESX host. By combining both “host profiles” together with the distributed switch – you reduce your administrative burden of having to create switches on each-and-every ESX host, whilst retaining the ability to have custom settings per-ESX hosts.
The distributed switch will be a key componenent in the “Fault Tolerance” (AKA Continious HA) feature ensuring that a shadowed/mirrored VM gets exactly same network settings across the FT cluster it inhabits.
In the next release we will get the ability to set privileges on a vSwitch to control how “users” patch their virtual machines to the network – this should reduce the possibility of conflicts and misconfigurations.
There was some additional features mentioned in this session as well, such as the ability to “reboot” virtual switches. There are currently some settings such as increasing the number of ports on virtual switch which require a full reboot of the ESX host (together with a bulk/maintenance mode to move all the VMs off the host). The new reboot feature will not stop VMs communicating to the network (because it will be so quick) but will allow us to apply settings without downtime. I can see this going to be important compliament to the Cisco Nexus Virtual Switch announced this week.
Finally, the presenter outlined how the new APIs allow security vendors to hook into the vSwitch to do such things as TCP port filtering, and Intrusion Detection. These new APIs allow security orientated virtual appliances to apply settings to individual VMs, the Hypervisors or virtaul switch port group level.