2 Replies Latest reply: Feb 24, 2016 12:58 AM by Heine Lysemose RSS

    Best Practice - Hyper-V/SCVMM and CSV

    Heine Lysemose Newbie
    Visibility: Open to anyone



      We are looking into buying a new SAN and Nimble is on top of the at list.

      We are getting a quote for a SC300 and a SC235. I only need one...


      Today we have a SCVMM cluster of 40-50 VM on three Dell 620 (2xXeon, 128GB RAM) spread over two iSCSI (1Gb) EqualLogic from Dell.


      1. What is the recommended number of VMs/VHD/VHDx per CSV

      1.2 One VM per CSV?


      I know it will depend on what kind of protection you would need on the particular VMs because it will snapshot the whole CSV/LUN/Volume


      2. Would you use Thin Provisioning on both SAN and VHD/VHDx or only one of the places?


      3. I read, here, that pass through disk or VM Guest with direct iSCSI connection to a LUN/Volume is best practice for SQL/Exchange logs and database files but other places they say that VHDx performance is as good as direct connection. What is the correct way of doing this?


      Thanks in advance for any answers of comments. Please let me know if you want me to share more info or details.



      Heine Lysemose

        • Re: Best Practice - Hyper-V/SCVMM and CSV

          1) The correct answer is - it's depends. 

          For VM's per CSV - it's dependant on what is your DR strategy?  Because putting a single VM per volume makes your recovery of that VM simple, just recover the volume, done.  But if you have 1000's of VM's, then that seems a little low.  Most people (depending on application) run 10-20 standard servers per vm.  If your doing VDI's though, you could put 100's per lun..   The best answer i can give you is - whatever you think would be the fastest to recover an environment, or group of servers if you destroyed something.  If your have a huge SRM DB server - I would do one lun in its own Volume Collection. For a large VDI deployment you could do multiple LIUNs with hundred of VM's each and in the same volume collection.


          2) We thin provision everything by default on the Nimble side.  You should follow the best practice defined for your application.  For VDI - thin everything, for some databases zero filled, and so forth.


          3) The reason you pass the SQL luns directly to the guest is to simplify clones and DR.  You can snap, clone, and present the LUNs to any server (Vurtual or phyical) ito perform a DR, UAT, or QA environment test.  If you create the DB on the VM storage, you can only use the LUNs in a cloned VM.  Both work, but the passthru devices give you a lot more options for testing and DR.