Listen up, VMware admins: If the array won't support it, VVOL won't help you... VMware's VVOL allows VMware admins to manage storage arrays through the API – but it doesn't necessarily mean they get to use all the VVOL data services. PernixData's Tech Evangelist Frank Denneman told us: "The interesting bits in the VVOL announcement are the supported 'Data Service' capabilities. As VVOL is an API, you can …
Atlantis has been working with VMware to solve the problem of supporting all storage with VVOL, not just the arrays that support it. You will be able to use VVOL with Atlantis USX to manage all storage - past, present and future.
Read the blog "Atlantis Partners with VMware To Extend Virtual Volumes to $300 Billion In Existing Datacenter Storage" here: http://blog.atlantiscomputing.com/2015/02/vvol/
The most important synergy of Atlantis USX and Virtual Volumes is the ability to accelerate the adoption of SDS by pooling every existing SAN, NAS, VSAN, DAS in the datacenter – whether it is Virtual Volumes enabled or not –instantly manage it through Virtual Volumes and deliver storage as containers that allow customers to realize the cost, performance and agility of Software-Defined Datacenters. Without Atlantis USX, Virtual Volumes will only be able to address new storage arrays that choose to write to the Virtual Volumes APIs, limiting the rate of adoption....
Watch a video of me discussing this very topic here:
http://vimeo.com/118508665
Yep and watch as cost and complexity increase while reliability and vendor accountability (Honest, it's the other guys at fault) decline. Then we need to get out and jump up and down on the stack to reverse the trend for just a little while.
Yes, this is (and has been) the promise of storage virtualization since its inception. Transparent pooling of back-end storage resources. There are certainly benefits to storage virtualization and this is something quite a few customers have adopted. However, there are caveats, which is also why storage virtualization isn't used in every situation.
However, this is a great angle to play while many vendors are playing VVol catch-up... Best of luck Seth.
VMware, there are limits!
The more I add up theTCO of VMware vs. every other solution, the more I realize that as long as VMware keeps on perpetuating their ancient design, there will just be limits which everyone else is blowing past.
A simple 100% fact... everyone else considers storage and networking to be a base component of the based package. VMware believes they're add-ons. While NSX is nifty, it just doesn't hold a candle to Microsoft SDN.
Want to talk storage? VMware is bragging about an uber-fast 7 million IOPs storage system with a wopping 90000 IOPs per node. Storage spaces scales WAY past that using SOFS.
I was SOOOO looking forward to vSphere 6 and when it hit, all I could think is "Where's the upgrade?"
Back to the original story.
Chris, your title is accurate, but not entirely correct. Here is why. One design point of VVols is to abstract features and capabilities, and allow them to be instantiated in a common manner.
Without sounding too much like a former programmer, what this really means is that the fact that you create a snapshot from the VMware vCenter menu is on purpose. If you are using VVols, and if your storage system supports snapshots, then that command happens on the array. If you are using VVols and your system doesn't support snapshots, VMware will create one.
Again, this is by design and is transparent. So, I would argue that using VVols does help the hypervisor admin, even when their storage system is lacking. This is because it enables them to do things the same way, without having to go find vendor X's Java vCenter plugin and figure out how to create a snapshot there, or try and remember exactly where the storage GUI is installed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
