I have been seeing a lot of activity in the VMTN forums regarding datastore sizing and free space.  That said I decided to write a post about this topic.  There are endless possibilities when it comes to datastore sizing and configurations but I’m going to focus on a few keep points that should be considered when structuring your ESX datastores.

All VM files kept together

In this configuration all VM files are kept together on one datastore.  This includes the vmdk file for each drive allocated to the VM, the vmx file, log files, the nvram file, and the vswap file.  When storing virtual machines this way there are some key considerations that need to be taken into account.  You should always allow for 20% overhead on your datastores to allow enough space for snapshots and vmdk growth if necessary.   When allocating for this overhead you have to realize that when a VM is powered on a vswap file is created for the virtual machine equal in size to the VM’s memory.  This has to be accounted for when allocating your 20% overhead.

Ream more of this post

Are you running Hyper-V?  Have you used up all the available drive letters deploying LUN’s for VM’s in your Failover Cluster?  It is fairly easy to get around the 26 drive letter limit in windows when deploying VM’s in a Hyper-V failover cluster configuration.  It is possible to deploy 2000 LUN’s to your Hyper-V cluster environment allowing you to grow your cluster and take advantage of your hardware.

In order to grow beyond the 26 drive letters you will need to install HotFix KB951308.  Once this hot fix is installed you can create shared storage using the drives GUID rather than drive letter or mount point.  Using the drives GUID you can create up to 2000 shared volumes without worrying about running out of identifyers.

Read more of this post

Nu er der kun få dage til nytår og vi får heldigvis flere og flere ting på plads. Idag rendte jeg byen rundt, for at finde en roastbeef til maden. Vi havde set at Føtex havde tilbud på så’n nogle krapyl til 60,- ½-kiloet og dette var da i særdeleshed et fint tilbud, problemet var bare, at da jeg så stod i Føtex med mennesker til langt oppe over knæene, så ku’ jeg ik’ finde denne omtalte roastbeef! Jeg måtte derfor ringe til Jeanetts arbejdstelefon, for lissom at høre hva vi nu skal finde på. Da hun arbejder som supporter hos et online communitysite, var det intet problem for hende at smutte ind på Tilbud Online og søge efter roastbeef. Derefter blev jeg så sendt afsted til den anden ende af byen, hvor Kvickly havde roastbeef til 50,- ½-kiloet. Her var jeg knap nok komme inden for døren, før at jeg fik klasket en luns kød i hovedet og jeg var derfor ude igen i løbet af to minutter. Alt i alt så sparede vi penge på vores roastbeef, og vi blev endnu en gang bekræftiget i, hvorfor vi ik’ behøver en halv urskov i vores postkasse hver lørdag formiddag.

Note: I’m trying to tighten up the layout of content on the landing page, so, I’ll be using excerpts more and more.

Continuing from last week, this edition of Search Term Tuesday will tackle the most important searches (or at least highest ranked statistically) that landed you at this blog.

Search Term #1: cx3-10 create raid group

Rather than delve in too deep here, I thought I’d point you to this excellent video regarding LUN Expansion (and as a pre-requisite, RAID Group creation) done by Wendy Bertino.

Navisphere Manager LUN Expansion Demo

Enjoy and let me know your feedback.

Search Term #2: emc cx3-20 expand raid group (takes days)

This particular search obviously points to an issue with the array and production. Let me highlight a few reasons why a RAID group expansion might take days.

Depending on what type of RAID group you’re expanding (I’m going to assume RAID 5), there are couple of things that need to happen.

First, you’ve got to re-calculate the parity of the RAID set across additional member disk(s). Adding 2 disks to a 5 disk RAID 5 set means that the entire parity stripe has to be recalculated. This is true for Equallogic, NetApp, EMC, IBM, HDS, HP etc.

Secondly, the entire data stripes or LUN stripes have to be re-spread across the additional spindles. In systems like Equallogic, you literally will have to restripe across 16 disks at a time which is not an efficient use of the production system. In the EMC world, you would have to restripe data + parity across the member disks only while the rebuild is happening.

Finally, The other variable is how many blocks of data you have present. A 500Gb rebuild will take less than a 5Tb rebuild (for obvious reasons). If you’re continually in production while this expansion is occurring you’ll continually be extending your rebuild window based on the influx of new data to the array (which is why we typically recommend doing this off-peak or using another method of expansion like LUN migrations or MetaLUNs).

Hopefully that helps with a more technical explanation.

Search Term #3: renderboxes

So, this has absolutely nothing to do with EMC (or does it? LOL!) but does have more to do with what I LOVE doing as a hobby: building CG workstations or renderboxes. Nothing makes me happier that putting together high performance hardware that will get hammered by the end users software and work 24/7. So, yes, I build renderboxes in my basement, during my spare time. Feel free to email me if you have any questions about architecture, technologies, etc.