| Unique Visitors |
Powered By 
| Unique Visitors |
While a lot of people (me included) are excited about the technical speeds and feeds of the vSphere 6 launch, there is something much more fundamentally important about this release. Some technical highlights include 64 node clusters, 8000vm’s per cluster, 480 pCPU’s & 12TB RAM & 2048 VM’s per Host, 128 vCPU & 4TB RAM per VM support, SMP FT (up to 4 vCPU FT), enhancements to NIOC, VVOLs, SIOC enhancements etc, and much more. The reason this release is more fundamentally important though is related to the same reason that Amazon with AWS went from nothing to cloud leader. It’s not just about the technology, but what the technology enables, changing the business model, reducing friction, enabling flexibility. What might seem like a relatively small feature on the surface has the potential to change the landscape in hybrid cloud SDDC. If you’d like to know more about this, and all of the goodness coming as part of the launch of vSphere 6, keep reading.
VMware is about to release the latest version of the flagship vSphere product in what I predict will be a defining moment for the Mobile / Cloud Era. For the first time you will be able to live migrate, without any disruption, between private cloud datacenters, to public cloud, and over long distance, a true hybrid cloud and software defined datacenter. You will be able to implement improved quality of service for all applications with additional SLA guarantees, and scale to unprecedented levels. All while reducing management overheads and complexity across the entire ecosystem. With the policies following the virtual machines and virtual applications regardless of where they are physically located.
This release has been baking for a while and for good reason. There is a big commitment to product quality, which was evidenced by the first ever public beta for VMware vSphere. This is a major release, and is well deserving of the 6.0 version number. A lot of hard work has gone into this release by thousands of people. I was able to test a lot of the functionality during the beta and it was great to be able to contribute to the product.
So why do I think this is such a defining moment? The world is changing with the massive explosion of mobile smart phones and the applications that support them. Billions of users are now demanding their applications wherever and whenever they want. So not only are the users mobile, their applications need to be. The applications need to be able to scale massively and on demand, and move to wherever it makes sense.
Previously migrating workloads from a private cloud or private SDDC to a cloud provider and to support a hybrid cloud required the systems being migrated to be shut down. You could migrate templates and power them on and update load balancer records, but that’s not quite the same as being able to dynamically live migrate any workload from your datacenter to a cloud without any downtime or disruption, and across long distances. If you really wanted to deliver cloud workloads and mobile workloads at scale, they had to be written for a particular cloud environment. Then you are stuck in a hotel California, where you can check out, but can never leave. This is the fundamental difference, and the fundamental technical change that is potentially enabled by vSphere 6, which in turn will deliver business and commercial disruption to current models.
The enhancements to VMware vMotion have the potential to change the way organisations run their datacenters, applications and interact with cloud service providers. It is conceivably possible to migrate workloads between different clouds on demand, based on various business rules and policies, provided they are based on vSphere 6.
So where does the comparison to Amazon and AWS come from? The reason I believe AWS became successful it not because of technology, it’s because it changed the economic and business model of consuming infrastructure. It reduced the friction, made everything on demand, and delivered to development and applications teams, in a way that was transparent. With the VMware vMotion enhancements allowing Cross vCenter vMotion and Long Distance vMotion, Cloud Service Providers can provide even less friction, on demand, run anywhere appropriate type of service. Some of the tyrannies of the network and live migration are being demolished. This again can change the way infrastructure is consumed and make it easier for app teams to deliver. But this needs to be blended with a commercial construct that also supports it.
At VMworld in 2014 Bill Fathers, Father of vCloud Air, reported that some 6% of workloads were running in Cloud environments. I believe part of the reason is because of the difficulty in migrating workloads to a Cloud, and between different Clouds, without disruption, and without having to change the underlying apps. With the changes that VMware is starting to deliver from vSphere 6, conceivably this could rapidly change the adoption of VMware compatible Clouds. There is still much to do in terms of the Network, which is still one of the barriers to Cloud, but this will go a long way. Soon you will be scaling workloads on demand to support the billions of mobile users and migrating those workloads to the cloud of choice that makes sense, almost anywhere in the world.
I was recently at the Singapore VMUG User Conference and listening to one of my colleagues, Scott Drummonds, talk about Cloud and locality. Locality is important because there are orders of magnitude computational difference the further the users are from their applications and data. How this relates back to the VMware vSphere 6.0 launch and vMotion Across vCenter and Long Distance is that it will now be possible to migrate workloads on demand closer to where the users are, especially as we start to see Cloud services become more local, and more miniaturised over time.
Final Word
At first glance vMotion Across vCenters and Long Distance vMotion may not seem that revolutionary. When you put this all in the context of the Hybrid Cloud and Software-Defined Datacenter that VMware has been building towards for over 5 years it is easier to see that this actually delivers a fundamental change in the way infrastructure resources can be used. It won’t be long before the live migration of VM’s is happening as depicted in the image above. What new possibilities will this open up for businesses? What impacts will this have on data sovereignty? Your thoughts and comments are appreciated.
—
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2015 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
VMware has announced that it will turn off TPS in upcoming version of it’s hypervisor ESXi and vCloud Air hybrid cloud service. This is due to a security bug, considered a very rare possibility and only exploitable in very controlled and largely misconfigured environments. TPS also known as Transparent Page Sharing is a memory management technique that allows multiple VM’s to share a read only copy of the same memory page. When a VM needs to update or write to a page a new copy is created. The idea is that if there are many VM’s with similar memory pages on the same physical host server it will de-duplicate the pages and only store one copy. The result is that you can run more VM’s per physical server while still achieving very good performance.
TPS has for a long time been used as a competitive advantage by VMware over all of the other hypervisors. But realistically it hasn’t been in wide use by most customers for some time (since ESX 3.5) as the amount of RAM per host has increased, because of the use of large memory pages (2MB instead of 4KB) in Nehalem and above processors, and because most customers don’t want to run their systems at 100% utilization so that they can handle bursts of activity. When using large pages TPS only kicked in when systems were over 96% memory utilization, at which point large pages would be broken down into small pages that could be shared. However this has been a popular technique with service providers and with virtual desktop environments, and in some test and development environments, where over commitment of memory may have been acceptable.
The security problem was found by recent research that leverages Transparent Page Sharing (TPS) to gain unauthorized access to data under certain highly controlled conditions. The research demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try and determine an AES encryption key in use on another virtual machine running on the same physical processor of the host server, if Transparent Page Sharing is enabled. This is effectively a VM escape, where code executed within one VM can break the hypervisor isolation and read data from another VM’s memory. Certainly not a good situation if said VM contains credit card data, as we’ve already had enough breaches recently. The conditions under which this could be exploited would be rare in the real world, especially as most environments don’t use TPS actively, even if it is enabled. Even so, I believe in being secure by default, and even though the number of conditions that have to simultaneous by true for this to be exploited would be very rare, if this were exploited the impact could be high. So I believe that VMware is taking the right approach to this research by disabling TPS.
I have been a proponent for leaving TPS enabled in the past, even though a few others have previously recommended it be disabled for performance reasons. My argument was that TPS is a good safety net if all else fails, even if during normal operations it is not used. Also performance was never proven to be a factor. I put this argument in my article Blueprint for Successful Large Scale Oracle Virtualization on vSphere when an EMC paper recommended disabling TPS. To quote that article “Disabling TPS can have disastrous consequences, including causing additional host swapping, which can result in extremely poor performance, much worse than disabling it could ever possibly gain.” So this begs the question, now that it’s being disable by VMware what impact will it have?
Without TPS you will have to have much more conservative memory usage per host. If you business requirements dictate, you will have to be able to sustain maintenance and failure without causing memory overcommitment. If there is a failure or maintenance that causes temporary or prolonged overcommitment of memory you will have a lot more guest OS swapping, due to ballooning, and also host swapping may occur, which would greatly impact performance. Memory swapping is the enemy of performance, and this also adds significantly to poor performance on shared storage if it occurs. But this is possibly better than the alternative security bug.
If you have an existing VMware vSphere environment this will mean you need to evaluate the level of resource usage you have today, your standard operating procedures for maintenance, and the settings of VMware HA Admission Control for failure. If you don’t have sufficient available memory to operate your environment in the case of failure or maintenance, then you may need to upgrade the amount of RAM per host or purchase additional hosts. With any additional hosts you’d need additional licenses. Frank Denneman has a good take on the capacity planning implications in his article here.
TPS will be disabled by default from the following VMware vSphere Releases:
VMware’s official statement on this problem is contained within KB 2080735 Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing. This KB also contains the steps to disable TPS on older versions of VMware vSphere that will not be covered by patches.
If you want to check whether you have TPS enabled or not on your existing versions, and if you want to disable it you can use the following PowerCLI examples (explicitly provided without any warranty, use at your own risk):
Check if TPS is Enabled on all hosts connected to a vCenter Server, Mem.ShareScanGHz returns > 0 if enabled.
Connect-VIServer <YourvCenter>
Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
Disconnect-VIServer
Disable TPS on all hosts connected to a vCenter Server by setting Mem.ShareScanGHz = 0, check the setting has been applied correctly
Connect-VIServer <YourvCenter>
Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Set-AdvancedSetting –Value 0
Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
Disconnect-VIServer
So if TPS is vulnerable to data leakage and VM escape attacks what about the recently announced Project Fargo, AKA VMFork? VMFork allows a running VM to be quiesced and rapidly cloned by using a similar copy on write technique to share a read only copy of the parent VM memory, and sharing the parent VM’s read only disk, with updates being written to a delta disk. This allows a VM to be cloned and get up and running on the network with it’s own personality in a matter of a few seconds, with the VM memory and disk effectively being deduped at the same time. This doesn’t just have applicability to VDI environments, but web server environments, Dev and Test environments and many other use cases. I’m sure VMware won’t let VMFork out in the wild until issues such as the VM escape bug with TPS are addressed. Kit Colbert, VMware CTO for End User Computing, has said to me that VMFork is much more secure than TPS, so it may not suffer from the same problems.
VMware is not alone with a VM escape vulnerability being discovered. There was also a security bug made public regarding the Xen hypervisor that allowed a VMescape, where code executed within one VM could escape the encapsulation of the hypervisor to a neighbour VM or dom0. This is covered at the VUPEN Vulnerability Research Team’s blog site.
Final Word
Nothing is fully secure. You can never guarantee that your system isn’t vulnerable to attack. All you can do is take appropriate measures to reduce the risk of attack, implement technical controls and monitoring and auditing processes. Implement separation of duties, least privilege access, and role based access controls. Implement the guidelines that make sense based on your business requirements from the VMware and other vendors hardening guides. Comply with the security standards for your industry / company that make sense. Stay on top of critical security patches and implement them as soon as practicable, especially for any environments containing public facing or highly secure systems.
—
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.