Datacenter virtualization with VMware, Cisco, EMC

I had the opportunity  to attend a seminar organized by VMware, Cisco and EMC. It was about virtualization in the datacenter and a presentation of VMware’s last product: vSphere4.

The idea is basically to take the cloud in the enterprise and not out – that is, opposed to the proprietary clouds (like AWS for instance). This echoes what I said in my last article “Second thoughts on Cloud Computing“.  It goes even further by giving the opportunity to companies to build “private clouds”, that is, an internal cloud in their very own DC, eventually connected to some rented cloud from a provider.

VMware’s vSphere provides several interesting features. vApp provides a software-defined SLA (scalability, availability, …) for one or a group of Virtual Machines. Fault tolerance is implemented by letting two instances of a VM run: the real one and copy (shadow) on different machines. If the first fails, the second becomes active seamlessly. Power management is also covered by letting unused hardware power down (ie by night), but taking in account the HA/FT. VMsafe is one last new feature that act as a global security agent, replacing the scanner you had to install previously on each individual VM.

One of the problems with virtualization is shared networking. When a packet goes from a VM to another VM on the same machine, via the ethernet interface, the switch to which the interface is connected will drop the packet. This is because the ethernet specifications say that an incoming packet cannot be forwarded to the same port. And this is why a virtual switch is needed in virtualized systems. VMware implement such a virtual switch and provide an API to access it.

Cisco presented their Nexus 1000v virtual switch. It actually use VMware’s virtual switch’s API to give a Cisco-like CLI and to interconnect easily with other physical Cisco switches. The hypervisor is software and can be run on a applicance or on VM. Linecards are actually the machines’ NICs. Configuration is not done at the traditional physical interface level but is done by defining “port profiles”. This feature should probably be added soon in physical switches (and I wonder why they didn’t implemented that before).

There is multiple advantages of using the Nexus 1000v in place of the VMware’s virtual switch. Its separates clearly the roles of the network and the system administrators, giving to the firsts the tools they are used to (Cisco CLI). Every aspect of configuration in the port profile (ACL, SPAN, Port security) follow the VMs seamlessly during vMotion and ease the work of the administrator by ensuring automaticaly that the configuration is consistent across the cloud. It also bundles automaticaly redundant links between the Nexus 1000v and a physical switch with help of CDP.