Array Setup and Networking
Showing results for 
Search instead for 
Did you mean: 

Nimble Storage, Hyper-V R3, SMB 3 and CSV

Go to solution

Nimble Storage, Hyper-V R3, SMB 3 and CSV


We are going to update our Hyper-V stack from Windows 2012 Hyper-V R2 to Windows 2012 R2 Hyper-V R3.

We have been presented with a setup from an MS partner where storage is managed using MS servers with SMB 3, these servers connect to the Nimble Storage.

CSV volumes will be presented to the Hyper-V stack from the MS SMB servers. The MS partner prefers this setup and says this is the way to go in the future with Hyper-V, where we abstract the Nimble storage using the SMB servers.

From what I've been able to read up on Nimble does not have support for VSS on Hyper-V enabling me to snapshot the VM's and/or (host) with application awareness. Is this correct?

Also from reading I am now unsure if I should only use the Nimble compression and no dedup etc on the SMB servers at all. This feels smart to be, except the using dedup on the OS volume of the Hyper-V servers I can greatly reduce storage space, like 10:1. Storage is not an issue, we have just received a pair of ES1-H65 boxes (one for each DC). This setup abstracts the storage from Nimble to MS but in the same time also adds a new layer where issues can arise.

What I am looking for is if anyone has done this type of setup, just to go back to the usual where the Hyper-V host servers connect with iSCSI to the Nimble Storage.

Thanks for all input.


Esteemed Contributor

Re: Nimble Storage, Hyper-V R3, SMB 3 and CSV

i have smb3 setup for shares, but not hyper-v usage. adding a second layer of mgmt for storage is never a good practice unless required. there is a fix request open to add vss to hyper-v.


Re: Nimble Storage, Hyper-V R3, SMB 3 and CSV

You're correct, there's no VSS provider for Hyper-V at this time, though I believe it's on the roadmap.

I've never built out the configuration you describe, but if the deduplication function is an offline function that operates on existing data, then you could eat up a lot of unnecessary snapshot space on the Nimble system as the data gets deduped.  This should theoretically wash out over time as old snapshots expire, but a lot of Nimble users have long snapshot retention periods so it may be a bad idea in that respect.  But there's no inherent conflict between dedupe and compression like there is with encryption.

I also have agree with Kevin Hobbs' opinion that the additional layer of storage management is something I'd avoid.  It sounds like this kind of setup is intended more for making direct-attached storage emulate shared storage, with a protocol switch (iSCSI to SMB3) thrown in for extra complexity.  Troubleshooting storage problems could be really tricky.

But if it works well for you, please keep us updated.  Always glad to learn new ways to do things.


Re: Nimble Storage, Hyper-V R3, SMB 3 and CSV


Hmm I have a bit of the same feeling regarding levels of complexity, and would prefer to not ad another level.

On the other hand the issues with storage will either be from the SMB servers to Nimble Storage or from MS Hyper-V to MS SMB and not from Hyper-V (CSV) to Nimble... That's the support type can-of-worms I rather not fall into.

We are having our startup meeting this friday so I'll try and update this page.




Re: Nimble Storage, Hyper-V R3, SMB 3 and CSV

I'm starting deployment of our first Hyper-V cluster and face the same decisions. Using SMB shares for vhdx storage makes the hv hosts simpler (no multipath etc). And you can mix and match different hosts without worrying about storage.  For the partner, this is a good solution because everything from the SMB server up is the same for all customers. Only the SMB cluster has the storage complexity. But, and it is a big one, that adds a very complex link in the chain. That thing better be resilient.

I'm opting for direct iSCSI connections from the hv hosts to Nimble. It means dedicating nics but that's life.