Nimble Virtual Array

[saintdle136]

Just a heads up, if your a Nimble partner, then the Nimble Virtual Array is available, reach out to your SE for more details, but it can be downloaded from the InfoSight downloads page.

I'll hopefully have a blog post soon on setting it up.

[bgrieve65]

Yes, and don't forget, you will need to generate a license key, which is good for 90 days. You will not be able to use the VM without it.

[#3]

+1 for this! Thanks to the SEs at Nimble who kept bugging corporate to make this possible! I'm in post-sales for a new Nimble partner and this has been extremely useful to me for getting up to speed quickly before my first install.  I've taken the Install and Administer class and the online training, but you can't replace the experience of getting your hands on the tech.

[wprather125]

Just getting it downloaded myself - I'll have something to tinker with now!  Long time to download, so gonna sleep on this for now... 

[rlovett51]

Is there a reason why this is Partner access only? This would be very helpful to us customers as well.

[rugby0134]

Currently it's only a demo device for partners to help with learning, demo, script testing, and such. can't say anything about the future.

[herzyk93]

Great news, waited soooo long for that to happen. Thanks to all involved.

Unfortunately activating doesn't seem to work.

The site the VA tries to contact returns this: {"message":"HTTP 404 Not Found"}

[rugby0134]

the server your installing it on MUST have internet access to NImble on initial boot. we then ask for you activation code. if the server doesn't have internet access, please call support and then might have a work around.

[herzyk93]

The interfaces of the Nimble VM are in a network that has full internet access and gets a dhcp address for each interface it tries but can't reach infosight:

Not sure if that is normal, but it can't be pinged on the IPs it receives.

[les_dunn]

Thanks Dean,

Could this be the forerunner to Nimble launching an SDS solution?

Cheers,

Les.

[Nick_Dyer]

Hi Les - Like your thinking, but there are other fish to fry at this point...

[rlovett51]

Thanks for your reply Kevin, but all those reasons that you list and more are exactly why this would be very useful to customers as well.

[zumasyslewis105]

Sweet!!  Been waiting for this for a while.  Got it up and running in no time, plus I loved the fact that I can run multiple instances to test replication and cluster, just amazing.

[Jacob_Wilde]

+1 for customer access.

[kevin_hsieh]

SDS would be interesting, but not being a storage system designer, I would think that it would require a significant change in the whole data model because you can't have two mirrored controllers backed by very fast NVRAM without custom hardware. Two loosely coupled controllers might require twice as much storage and write latency would be much slower as you would need to gets writes physically down to a persistent layer on both controllers before acknowledging a write. You can also have a single controller system that would be fast, but who wants their data on that?

[kevin_hsieh]

+2 for customer access both pre and post sales...after the partners beat on it a while and the installation and registration process gets all worked out.

[p-wu57]

Hi,

Readme　said it is DHCP server needed. Usually, there is no DHCP server in a verification environment. umm.....I have to take more time to setup a virtual array. physical array is EASY than virtual.

[les_dunn]

Hi Kevin,

I'm no technical guru either, but there are a number of SDS solutions that can be deployed on standard hardware.  Sure, they do require specific specifications to actually work, but they are standard servers nonetheless.  I believe that this is reason for DELL etc taking on the likes of Nutanix, Nexenta, DataCore etc.  It's to be noted, however, there are some "gotchas" with these solutions.   The standard server equation gives them the dubious right to call their solutions hyper-converged which seems to be gaining a level of mind share in our marketplace.  All of them make lots of claims re short term ROI and lower TCO than a converged solution ......... few of which stand up when you get down to the nitty gritty.

[kevin_hsieh]

I have a hyperconverged solution, which is SDS (no special hardware like what SimpliVity has). From an architectural standpoint, to provide guaranteed data resiliency for recent writes you need to get them to two controllers and then into a persistent layer. Nimble and most dual controller systems use a form of NVRAM, which is very fast. A SDS system would need to send the write to two controllers (added latency), and then make sure that the data gets written to SSD or HDD. SSD or HDD has significantly greater latency than NVRAM. Even more importantly than the latency hit is that the current architecture has two controllers talking to the same physical set of disks. I know of no way to do that with commodity hardware. You could emulate that with two VMs talking to the same VMDK/VHDX, but both controller VMs would need to be on the same host, which eliminates any real redundancy of the controller. It would make the system available during updates, but there would be nowhere the kind of uptime currently available, and I don't see how you could put it into production.

[wprather125]

I put the first NIC into Bridged Mode on Workstation, and the others in a "VMnet10" which is host-only, to serve the LUNs over... so far so good!