Disclaimer: I work for Hitachi Data Systems. However this post is not officially sanctioned by or speaks on behalf of my company. These thoughts are my own based on my experience. Use at your own discretion.
Pretty much the entire world knows that in the last week or so VMware announced vSphere 6.0.
I haven’t written a post on it yet but will do soon.
Suffice it to say VMware has really focused and invested huge engineering resources to achieve this. For my money vSphere 6 is the best ever release.
As someone said … The hypervisor is not a commodity, which when you see the features and improvements that have come with this release I think that rings true.
So kudos to VMware engineering and Product Management !!
I’ve had a few questions lately from colleagues asking me how this landmark feature works in detail.
I think the following demo by my countryman Paul Morrissey, HDS global Product Manager for VMware, should really help aid learning.
Paul does a great walkthrough of the setup on the storage side, configuration through the vCenter Web Client as well as provisioning to VM’s.
It’s a nice demo – not too long but covers the typical questions you might ask.
HDS support for VVOL
It is expected that HDS will be announcing support initially with Hitachi NAS (HNAS) product in March at GA time for vSphere 6.0, followed swiftly by support for all HDS block storage within 2-3 months.
With the initally supported HNAS, HDS supports:
- 100 MILLION VM snapshots
- 400,000 Vvols (with architectural support for up to 10 MILLION Vvols)
A Word of Caution
Don’t forget you heard it here first !!!!
There has been no commentary or proper consideration in my view regarding the potentially negative impact of VVols on the datacenter, both in terms of operational processes as well as matching business requirements to the correct SLA.
Of course VVols provide an amazing level of granularity of control regarding workload placement and aligment. This of course is to be welcomed.
However, the onus is really on IT SI’s and vendors to help customers understand the ACTUAL requirements for their applications. To get the best out of VVols, business and IT need to be working more closely together to ensure the correct capabilities are coupled with the right use cases.
My belief is that this new technology needs to be properly managed and given the “VCDX treatment”. What I mean is that the SLA matches the applications needs. Otherwise we will end up in a situation similar to the early days of virtualisation with 8-vCPU VMs all over the virtual datacenter.
This has been one of the downsides of virtualisation – consumers requesting double what they actually need because of the so-called virtualisation tax, which is now pretty much negligible and irrelevant when compared against the upsides. This kind of thinking can have a negative impact on performance (ironically) which can be notoriously difficult to identify. I think were it not for the robustness of the vSphere hypervisor we would not have gotten away with this.
The request for VVols could go like this:
- I need a VM
- What type of storage (VVOL) do you need?
- What have you got?
- I’ve got Platinum, Gold and Silver
- What does Platinum have?
- I’ll take 10 (John in Finance said to ask for more than you need – then if IT give you Silver that will be fine)
I admit that this is a slightly facetious scenario, but without internal showback/chargeback the danger is that the right SLA will not end up being matched to the right use case or application requirement, and we will end up with an overprovisioned datacenter, that once deployed cannot be un-picked.
Paul covered how cost can be included in his demo. We need to accept human nature and understand that data is precious gold, and if someone thinks they can have a second copy of their data in a separate data center then who wouldn’t want that ?
It is also our default human nature to say Yes, as humans really don’t like to say No?
This has long been a concern of mine with VVols so we need to perform proper due diligence to ensure this technology does not get misused.
More on this next week.