VMworld has a bit disappointing for core vSphere users this year. Its the first VMworld since at least 2008 where a major release of vSphere wasn’t made during the show. This year, we all have to settle for the vSphere 6 beta which was already publicly available. No news on timelines or release datas for vSphere 6. That’s not to say there isn’t plenty of news on other horizons (pun intended) and initiatives from the company, but for core virtualization, not a lot has been discussed.
VMware did publicly discuss some of the features of the upcoming vSphere 6 release, something everyone who has participated in the beta was unable to do because of non-disclosure agreements. Here is a quick run-down of the features that were publicly discussed:
- Compute > Multi-vCPU Fault Tolerance support
- Network > vMotion Enhancements across virtual switches and vCenter instances & support for routed vMotion
- Storage > Virtual Volumes (vVols) support for storage
vSphere 6 will be bringing a number of improvements in terms of scale and sizing that customers will appreciate. The specifics weren’t covered in the keynote and I have not seen them publicly discussed.
Compute > SMP-FT
vSphere 6 adds multi-vCPU support for Fault Tolerance (SMP-FT), extending this technology to a wider range of uses. Most mission critical apps where Fault Tolerance would likely be adopted were more than 1 vCPU, so this is welcome news for administrators. There are still some limits to the technology, SMP-FT will support up to 4 vCPU and 64GB of RAM. Users will be limited to 4 VM running SMP-FT or 8 total vCPU running SMP-FT. Your FT logging network is required to be 10Gig to support SMP-FT. Julian Wood has some additional details in his blog post on the topic.
Network > vMotion
vMotion gets a number of enhancements, all of which should allow for easier administration. The critical one from an administrator’s point of view is the cross-vSwitch and cross-vCenter vMotion. Much like the shared nothing Storage vMotion that was added in vSphere 5.5, the cross-vCenter vMotion will allow a Virtual Machine to hop port groups between virtual switches, changing assignments. Previously, administrators were limited to either Standard vSwitches with the same port group name in order to cross clusters with vMotion or they needed to extend their Distributed vSwitch across clusters. But crossing a vCenter server is an entirely new capability and this is clearly targeted at multi-site scenarios allowing administrators to move workloads without the requirements of stretching a distributed switch and vCenter across sites. Chris Wahl has an excellent blog post about the new vMotion capabilities.
Storage > vVols
The big, well-discussed feature being added is Virtual Volumes (vVols) support. vVols allows vSphere to talk directly against the storage and provision virtual machines natively, without the need for LUNs. Each virtual machine, natively provisions several files on the storage – one for config, one or more for data and then at boot, the expected RAM files and log files required. This allows the storage administrator to have a native, VMware object level view of the data and using native storage tools, better identify problems and bottlenecks by identifying individual VMs or VM disks instead of a noisy LUN.
If you are familiar with NFS storage vendor Tintri, the whole concept will sound really familiar. With a Tintri, you present one large NFS datastore and then provision VMs inside of it. The storage is VM aware and has a lot of additional performance metrics and management. It allows for things like quality of service at a VM level.
In the vSphere side, the vSphere Administrator is presented with a storage system and they provision against it rather than being presented a LUN and having to format and manage capacity with VMFS datastores and datastore clusters. From the storage administrators view point, instead of having 10 LUNs, they may now have 5 times as many objects within their views. This is where the storage vendor’s implementation becomes a critical point. The views and management consoles will have to adapt and change.
vVols also allows the vSphere administrator to wrap tagging and policy controls around storage. The concept that VMware introduced with the VSAN in vSphere 5.5, policy based storage allows for an abstraction from the array and LUN constructs to a needs-based construct for deploying VMs. What does that mean? Well, to deploy a virtual machine, the user had to make a choice of which datastore to deploy onto. With vSphere 5.5, policies and tagging could allow administrators to define a service profile or level of service abstraction from the physical storage devices and let the user choose options like a Platinum storage location for mission critical applications or a Bronze storage location for dev/test. Those tags and policies allow for the decisions where to place a VM in storage without having to know that Array X is the one the user should use.
In the meantime, all vSphere users will be waiting for the new release and finalization of capabilities. With SMP-FT and vVols, users have been waiting for VMware to deliver these features for a long time and their discussion during the keynote on Tuesday drew lots of applause.