boche.net - VMware vEvangelist http://www.boche.net/blog Tue, 18 Jun 2013 03:18:05 +0000 en-US hourly 1 http://wordpress.org/?v=3.4.1 Bochenet-VmwareVirtualizationEvangelisthttp://feedburner.google.com vEXPERT 2013 Thoughts and Thanks http://www.boche.net/blog/index.php/2013/06/17/vexpert-2013-thoughts-and-thanks/ http://www.boche.net/blog/index.php/2013/06/17/vexpert-2013-thoughts-and-thanks/#comments Tue, 18 Jun 2013 03:18:05 +0000 jason http://www.boche.net/blog/?p=4714 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vEXPERT 2013 Thoughts and Thanks

]]> Snagit CaptureThe ballots have been counted and the 2013 vEXPERTS were announced in a VMTN blog post by John Troyer.  I was fortunate enough to be awarded this honorable designation for a fifth consecutive year (I’m going to link that Five Timers club skit from SNL because I still get a laugh out of it).  What’s interesting about this journey for me is that for quite a while I had worked in and contributed towards Microsoft Windows, Active Directory, Networking, Design, and related communities striving for Microsoft MVP recognition.  That never happened.  Quite honestly I probably didn’t give it enough time and there are metric ton of brilliant Microsoft people already with their MVP status to compete against.  Once VMware came into my life, I quickly gained interest in the technology and its potential for businesses as well as end users world wide.  As a result, I shifted my career to focus solely on VMware and datacenter virtualization which did not stop short of leaving a great company I had been at for 11 years to make that change stick.  Although John Troyer at one time denied it and may still, I think the vEXPERT program is very much like Microsoft’s MVP program and the individuals who are awarded vEXPERT are very much like MVPs in terms of giving back and community involvement.  Although I appreciated the recognition and gifts going back to the first vEXPERT awards in February 2009, I think I took for granted what the award really meant for me as an individual.  With my virtualization blog already successful and my name pretty well known from spending a few years on the VMTN forums, an accolade here or there was quickly put in the trophy case and with the motor perpetually running, I moved on to the next thing.  In the back of my mind I knew what awards meant but I didn’t really take the time to stop and recognize that what I had tried to accomplish in the Microsoft programs and failed, I’ve now achieved many times over in the VMware community.  In the long run I think it has been a lot more beneficial for me and hopefully for the relatively new and growing virtualization community as well.  I’ve learned a lot, met a lot of people, made many good friends, have a great job, and I sincerely hope that I can continue making a positive community impact into the future.  My thanks to John Troyer, VMware, and the incredible community that I am a part of.  I’d also like to thank TrainSignal, Tintri, and Veeam for their generous gifts to vEXPERTs current and past.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vEXPERT 2013 Thoughts and Thanks

Related Posts

]]> http://www.boche.net/blog/index.php/2013/06/17/vexpert-2013-thoughts-and-thanks/feed/ 1 Available Lab Gear http://www.boche.net/blog/index.php/2013/05/29/available-lab-gear/ http://www.boche.net/blog/index.php/2013/05/29/available-lab-gear/#comments Thu, 30 May 2013 00:00:44 +0000 jason http://www.boche.net/blog/?p=4705 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Available Lab Gear

]]> Heads up to any locals looking for server grade vSphere hardware infrastructure.  I’ve been doing some lab spring cleaning the past few weeks and after some consolidation efforts, I’ve got some hardware available that’s not being put to good use any longer.  All of these are 64-bit and will run vSphere.  All have Ethernet and/or Fibre Channel options.

  • 2x HP DL385 (1x AMD DC Opteron, 4GB RAM, rails, RPS)
  • 2x HP DL385 G2 (2x AMD QC Opteron (Barcelona), 34GB RAM, rails, RPS)
  • 2x HP DL585 G2 (4x AMD DC Opteron, 64GB RAM, RPS, power cables)

If you have any questions not pertaining to power or heat, please ask.

You pick up – Lakeville, MN.

The price is right - email me if interested.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Available Lab Gear

Related Posts

]]> http://www.boche.net/blog/index.php/2013/05/29/available-lab-gear/feed/ 0 Publisher Error In Your Favor http://www.boche.net/blog/index.php/2013/05/20/publisher-error-in-your-favor-2/ http://www.boche.net/blog/index.php/2013/05/20/publisher-error-in-your-favor-2/#comments Mon, 20 May 2013 15:58:30 +0000 jason http://www.boche.net/blog/?p=4697 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Publisher Error In Your Favor

]]> Snagit Capture

I’m not promoting this on Twitter – Let’s see who actually reads my blog on a Monday morning or at least still employs RSS technology.

A short while ago, I received on my doorstep a copy of Scott Lowe’s Mastering VMware vSphere 5.  I’ve already got my own copy and I’d like to make sure this book ends up in the hands of someoneone who:

A) needs a copy

B) will read it and put the tremendous knowledge it contains to good use

C) won’t ask me for an electronioc handheld version

Respond in the comments section below on 1) your role and 2) your thoughts and/or opinions (good or bad) of VMware’s endeavors into both Software Defined Storage and Software Defined Networking.  The 5th response snags the copy which I will mail to you.  Good luck and thank you for your feedback.

Update 5/20/12:  Thank you for the responses.  It’s good to see so many people attentive on a Monday.

I expect anyone could argue that the first response from Andy wasn’t an actual opt-in response for the contest, nor did it conform to the contest rules.  This creates a problem because whether or not I include Andy’s comment means either Miguel or Kris are winners.  The easiest way to settle this is to declare you both winners.  Send me an email detailing your full mailing address and each of you will receive a copy of Mastering vSphere 5 by Scott Lowe.

Thank you,

Jas

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Publisher Error In Your Favor

Related Posts

]]> http://www.boche.net/blog/index.php/2013/05/20/publisher-error-in-your-favor-2/feed/ 11 vSphere 5.1 Update 1 Update Sequence http://www.boche.net/blog/index.php/2013/05/06/vsphere-5-1-update-1-update-sequence/ http://www.boche.net/blog/index.php/2013/05/06/vsphere-5-1-update-1-update-sequence/#comments Mon, 06 May 2013 15:09:31 +0000 jason http://www.boche.net/blog/?p=4687 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vSphere 5.1 Update 1 Update Sequence

]]> Not so long ago, VMware product releases were staggered.  Major versions of vSphere would launch at or shortly after VMworld in the fall, and all other products such as SRM, View, vCloud Director, etc. would rev on some other random schedule.  This was extremely frustrating for a vEvangelist because we wanted to be on the latest and greatest platform but lack of compatibility with the remaining bolt-on products held us back.

While this was a wet blanket for eager lab rats, it was a major complexity for production environments.  VMware understood this issue and at or around the vSphere 5.0 launch (someone correct me if I’m wrong here), all the development teams in Palo Alto synchronized their watches & revd product in essence at the same time.  This was great and it added the much needed flexibility for production environment migrations.  However, in a way it masked an issue which didn’t really exist before by virtue of product release staggering – a clear and understandable order of product upgrades.  That is why in March of 2012, I looked at all the product compatibility matrices and sort of came up with my own “cheat sheet” of product compatibility which would lend itself to an easy to follow upgrade path, at least for the components I had in my lab environment.

vSphere 5.1 Update 1 launched on 4/25/13 and along with it a number of other products were revd for compatibility.  To guide us on the strategic planning and tactical deployment of the new software bundles, VMware issued KB Article 2037630 Update sequence for vSphere 5.1 Update 1 and its compatible VMware products.

Snagit Capture

Not only does VMware provide the update sequencing information, but there are also exists a complete set of links to specific product upgrade procedures and release notes which can be extremely useful for planning and troubleshooting.

The vCloud Suite continues to evolve providing agile and elastic infrastructure services for businesses around the globe in a way which makes IT easier and more practical for consumers but quite a bit more complex on the back end for those who must design, implement, and support it.  Visit the KB Article and give it 5 stars.  Let VMware know this is an extremely helpful type of collateral for those in the trenches.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vSphere 5.1 Update 1 Update Sequence

Related Posts

]]> http://www.boche.net/blog/index.php/2013/05/06/vsphere-5-1-update-1-update-sequence/feed/ 1 QuickPrep and Sysprep http://www.boche.net/blog/index.php/2013/05/02/quickprep-and-sysprep/ http://www.boche.net/blog/index.php/2013/05/02/quickprep-and-sysprep/#comments Thu, 02 May 2013 21:04:17 +0000 jason http://www.boche.net/blog/?p=4678 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

QuickPrep and Sysprep

]]> Those who manage VMware View currently or have used it in the past may be familiar with desktop customization which is required to provide a unique identity on the network for each View Composer VDI session in a pool.  If you’ve got a pretty good Microsoft background, you’re probably already familiar with Sysprep – Microsoft’s tool for customizing Windows server and desktop OS deployments.  VMware View Administrators have an alternative tool which can be used for desktop customization called QuickPrep.  For all intents and purposes, QuickPrep was designed to accomplish many of the same tasks Sysprep did, but the obvious advantage QuickPrep has is that the code and development belongs to VMware and as a result can be tightly integrated with products in VMware’s portfolio.

I was on a call this morning with VMware Senior Technical Trainer Linus Bourque (Twitter: @LinusBourque Blog: http://communities.vmware.com/blogs/lbourque Cigars: yes) when he pulled up a table slide which was the result of VMware KB Article 2003797 Differences between QuickPrep and Sysprep.  For those who are curious about the similarities and differences between the two (like me), look no further.

From the KB Article:

QuickPrep is a VMware system tool executed by View Composer during a linked-clone desktop deployment. QuickPrep personalizes each desktop created from the Master Image. Microsoft Sysprep is a tool to deploy the configured operating system installation from a base image. The desktop can then be customized based on an answer script. Sysprep can modify a larger number of configurable parameters than QuickPrep.
During the initial startup of each new desktop, QuickPrep:
  • Creates a new computer account in Active Directory for each desktop.
  • Gives the linked-clone desktop a new name.
  • Joins the desktop to the appropriate domain.
  • Optionally, mounts a new volume that contains the user profile information.
This table lists the main differences between QuickPrep and Sysprep:
Function QuickPrep Sysprep
Removing local accounts No Yes
Changing Security Identifiers (SID) No Yes
Removing parent from domain No Yes
Changing computer name Yes Yes
Joining the new instance to the domain Yes Yes
Generating new SID No Yes
Language, regional settings, date, and time customization No Yes
Number of reboots 0 1 (seal & mini-setup)
Requires configuration file and Sysprep No Yes
Note: A Guest Customization script is required in vCenter Server to use Sysprep. Sysprep is bundled in with Windows 7. For Windows XP, an appropriate Sysprep program needs to be installed on the vCenter Server.
For information on installing Sysprep tools, see Sysprep file locations and versions (1005593).
For more information on the use of Sysprep and the Guest Customisation wizard, see the Customizing Guest Operating Systems and Installing the Microsoft Sysprep Tools sections of the vSphere Virtual Machine Administration Guide.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

QuickPrep and Sysprep

Related Posts

]]> http://www.boche.net/blog/index.php/2013/05/02/quickprep-and-sysprep/feed/ 1 vMA 5.1 Patch 1 Released http://www.boche.net/blog/index.php/2013/04/05/vma-5-1-patch-1-released/ http://www.boche.net/blog/index.php/2013/04/05/vma-5-1-patch-1-released/#comments Fri, 05 Apr 2013 19:41:27 +0000 jason http://www.boche.net/blog/?p=4671 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vMA 5.1 Patch 1 Released

]]> Expendable news item here only worthy of a Friday post.  For those who may have missed it, VMware has released an update to the vSphere Management Assistant (vMA) 5.1 appliance formally referred to as Patch 1.  This release is documented in VMware KB 2044135 and the updated appliance bits can be downloaded here.  Log in, choose the VMware vSphere link, then the Drivers & Tools tab.

Patch 1 bundles with it the following enhancements:

  • The base operating system is updated to SUSE Linux Enterprise Server 11 SP2 (12-Jan-2013).
  • JRE is updated to JRE 1.6.0_41, which includes several critical fixes.
  • VMware Tools is updated to 8.3.17 (build 870839).
  • A resxtop connection failure issue has been fixed.
    In vMA 5.1, resxtop SSL verification checks has been enabled. This might cause resxtop to fail when connecting to hosts and displays an exception message similar the following:
    HTTPS_CA_FILE or HTTPS_CA_DIR not set.
    This issue is fixed through this patch.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vMA 5.1 Patch 1 Released

Related Posts

]]> http://www.boche.net/blog/index.php/2013/04/05/vma-5-1-patch-1-released/feed/ 2 Redefining Disk.MaxLUN http://www.boche.net/blog/index.php/2013/03/27/redefining-disk-maxlun/ http://www.boche.net/blog/index.php/2013/03/27/redefining-disk-maxlun/#comments Wed, 27 Mar 2013 15:00:15 +0000 jason http://www.boche.net/blog/?p=4662 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Redefining Disk.MaxLUN

]]> Regardless of what the vSphere host Advanced Setting Disk.MaxLUN has stated as its definition for years, “Maximum number of LUNs per target scanned for” is technically not correct.  In fact, it’s quite misleading.

Snagit Capture

The true definition looks similar stated in English but carries quite a different meaning and it can be found in my SnagIt hack above or within VMware KB 1998 Definition of Disk.MaxLUN on ESX Server Systems and Clarification of 128 Limit.

The Disk.MaxLUN attribute specifies the maximum LUN number up to which the ESX Server system scans on each SCSI target as it is discovering LUNs. If you have a LUN 131 on a disk that you want to access, for example, then Disk.MaxLUN must be at least 132. Don’t make this value higher than you need to, though, because higher values can significantly slow VMkernel bootup.

The 128 LUN limit refers only to the total number of LUNs that the ESX Server system is able to discover. The system intentionally stops discovering LUNs after it finds 128 because of various service console and management interface limits. Depending on your setup, you can easily have a situation in which Disk.MaxLUN is high (255) but you see few LUNs, or a situation in which Disk.MaxLUN is low (16) but you reach the 128 LUN limit because you have many targets.

For more information about limiting the number of LUNs visible to the server, see http://kb.vmware.com/kb/1467.

Note the last sentence in the first paragraph above in the KB article.  Keep the value as small as possible for your environment when using block storage.  vSphere ships with this value configured for maximum compatibility out of the box which is the max value of 256.  Assuming you don’t assign LUN numbers up to 256 in your environment, this value can be immediately ratcheted down in your build documentation or automated deployment scripts.  Doing so will decrease the elapsed time spent rescanning the fabric for block devices/VMFS datastores.  This tweak may be of particular interest at DR sites when using Site Recovery Manager to carry out a Recovery Plan test, a Planned Migration, or an actual DR execution.  It will allow for a more efficient use of RTO (Recovery Time Objective) time especially where multiple recovery plans are run consecutively.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Redefining Disk.MaxLUN

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/27/redefining-disk-maxlun/feed/ 0 vExpert 2013 Applications Available http://www.boche.net/blog/index.php/2013/03/22/vexpert-2013-applications-available/ http://www.boche.net/blog/index.php/2013/03/22/vexpert-2013-applications-available/#comments Fri, 22 Mar 2013 12:00:39 +0000 jason http://www.boche.net/blog/?p=4655 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vExpert 2013 Applications Available

]]> John Troyer (you know him as @jtroyer on Twitter or the guy with the disco ball jacket at social events) has made the announcement that vExpert 2013 applications are now available. Simply put, a vExpert is the formal recognition, by VMware, of being a virtualization rock star.  I haven’t read the latest charter but technically speaking I don’t think one even needs to specifically be a VMware virtualization rock star (hey, we’re all in this virtualization space together for the greater good right?) but it certainly helps.

There are three separate but interrelated tracks to being recognized as a vExpert

  • Evangelist – You’re a blogger, regular speaker, VMTN contributor, etc. who shares the passion with the rest of the community.  You might be employed, but not by VMware or a partner. Nobody really knows.
  • Customer – You’re a customer internal facing proxy evangelist if that makes any sense whatsoever.  You get it.  You make sure your internal organization gets it.
  • VPN (VMware Partner Network) – You work for VMware or a partner and you’re either a rock star by choice or by force.  Either way, you know your stuff and you’re good at sharing with your customers.

The paths are separate but they all converge on fundamental traits within the virtualization community:  Passion. Enthusiasm. Leadership. Knowledge. Outreach.

If you’ve made contributions in any of the areas listed above, consider filling out an application for yourself.  Now is not the time to be modest or bashful.  It is the time to be showered with gifts of VMware licensing and the type of real world respect that is recognized in every corner of the globe.

My application is submitted and I’ve got my fingers crossed.  If I make vExpert 2013, I’ll be in the exclusive Five Timers club (vExpert 2009-2013 inclusive).  Why I remember so long ago receiving the news of my first vExpert award… I was at VMworld Europe in Cannes…

 

Seriously, here are the important links you need from VMware:

Recommend that someone apply for vExpert 2013: http://bit.ly/vExpert2013recommend

Apply for vExpert 2013: http://bit.ly/vExpert2013application The deadline for applications is April 15, 2013 at midnight PDT.

The existing VMware vExpert 2012 directory is at http://communities.vmware.com/vexpert.jspa.

For questions about the application process or the vExpert Program, use the comments below or email vexpert@vmware.com.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vExpert 2013 Applications Available

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/22/vexpert-2013-applications-available/feed/ 4 VMware vSphere Design 2nd Edition Now Available http://www.boche.net/blog/index.php/2013/03/20/vmware-vsphere-design-2nd-edition-now-available/ http://www.boche.net/blog/index.php/2013/03/20/vmware-vsphere-design-2nd-edition-now-available/#comments Wed, 20 Mar 2013 16:53:12 +0000 jason http://www.boche.net/blog/?p=4647 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

VMware vSphere Design 2nd Edition Now Available

]]> Snagit Capture

Publication Date: March 25, 2013 | ISBN-10: 1118407911 | ISBN-13: 978-1118407912 | Edition: 2

The big splash was officially made yesterday but I’m following up with my announcement a day later to help spread the message to anyone who may have been heads down and missed it.  Forbes Guthrie (Snagit Capture Snagit Capture), Scott Lowe (Snagit Capture Snagit Capture), and Kendrick Coleman (Snagit Capture Snagit Capture) have teamed up to produce VMware vSphere Design 2nd Edition (a followup refresh of the popular 1st Edition).

As Technical Editor, I’m one of the few fortunate individuals who have already had the pleasure to have read the book.  I can tell you that it is jam-packed with the deep technical detail, design perspective, and methodology you’d expect from these seasoned and well-respected industry experts.

The book is 528 pages in length (compare to 384 pages in the 1st edition).  New in this version is coverage of vSphere 5.1, emerging infrastructure technologies and trends, as well as a section on vCloud Director design – a worthy topic which should be weighing heavily on the minds of many by now and in the future will likely spawn dedicated coverage in texts by Sybex and/or other publishers.

The publisher has made the introduction section of the book freely available.  You can take a look at that by clicking this link which is hosted at Forbes vReference blog.  As with the previous edition, this book is made available in both paperback and Kindle editions.  Support these authors and pick up your copy today.  Tell them Jason sent you and nothing special will likely take place.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

VMware vSphere Design 2nd Edition Now Available

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/20/vmware-vsphere-design-2nd-edition-now-available/feed/ 0 Large Memory Pages and Shrinking Consolidation Ratios http://www.boche.net/blog/index.php/2013/03/19/large-memory-pages-and-shrinking-consolidation-ratios/ http://www.boche.net/blog/index.php/2013/03/19/large-memory-pages-and-shrinking-consolidation-ratios/#comments Tue, 19 Mar 2013 12:00:19 +0000 jason http://www.boche.net/blog/?p=4634 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Large Memory Pages and Shrinking Consolidation Ratios

]]> Here’s a discussion that has somewhat come full circle for me and could prove to be a handy for those with lab or production environments alike.

A little over a week ago I was having lunch with a former colleague and naturally a TPS discussion broke out.  We talked about how it worked and how effective it was with small memory pages (4KB in size) as well as large memory pages (2MB in size).  The topic was brought up with a purpose in mind.

Many moons ago, VMware virtualized datacenters consisted mainly of Windows 2000 Server and Windows Server 2003 virtual machines which natively leverage small memory pages – an attribute built into the guest operating system itself.  Later, Windows Vista as well as 2008 and its successors came onto the scene allocating large memory pages by default (again – at the guest OS layer) to boost performance for certain workload types.  To maintain flexibility and feature support, VMware ESX and ESXi hosts have supported large pages by default providing the guest operating system requested them.  For those operating systems that still used the smaller memory pages, those were supported by the hypervisor as well.  This support and configuration remains the default today in vSphere 5.1 in an advanced host-wide setting called Mem.AllocGuestLargePage (1 to enable and support both large and small pages – the default, 0 to disable and force small pages).  VMware released a small whitepaper covering this subject several years ago titled Large Page Performance which summarizes lab test results and provides the steps required to toggle large pages in the hypervisor as well as within Windows Server 2003

As legacy Windows platforms were slowly but surely replaced by their Windows Server 2008, R2, and now 2012 predecessors, something began to happen.  Consolidation ratios gated by memory (very typical mainstream constraint in most environments I’ve managed and shared stories about) started to slip.  Part of this can be attributed to the larger memory footprints assigned to the newer operating systems.  That makes sense, but this only explains a portion of the story.  The balance of memory has evaporated as a result of modern guest operating systems using large 2MB memory pages which will not be consolidated by the TPS mechanism (until a severe memory pressure threshold is crossed but that’s another story discussed here and here).

For some environments, many I imagine, this is becoming a problem which manifests itself as an infrastructure capacity growth requirement as guest operating systems are upgraded.  Those with chargeback models where the customer or business unit paid up front at the door for their VM or vApp shells are now getting pinched because compute infrastructure doesn’t spread as thin as it once did.  This will be most pronounced in the largest of environments.  A pod or block architecture that once supplied infrastructure for 500 or 1,000 VMs now fills up with significantly less.

So when I said this discussion has come full circle, I meant it.  A few years ago Duncan Epping wrote an article called KB Article 1020524 (TPS and Nehalem) and a portion of this blog post more or less took place in the comments section.  Buried in there was a comment I had made while being involved in the discussion (although I don’t remember it).  So I was a bit surprised when a Google search dug that up.  It wasn’t the first time that has happened and I’m sure it won’t be the last.

Back to reality.  After my lunch time discussion with Jim, I decided to head to my lab which, from a guest OS perspective, was all Windows Server 2008 R2 or better, plus a bit of Linux for the appliances.  Knowing that the majority of my guests were consuming large memory pages, how much more TPS savings would result if I forced small memory pages on the host?  So I evacuated a vSphere host using maintenance mode, configured Mem.AllocGuestLargePage to a value of 0, then placed all the VMs back onto the host.  Shown below are the before and after results.

 

A decrease in physical memory utilization of nearly 20% per host – TPS is alive again:

Snagit Capture Snagit Capture

 

124% increase in Shared memory in Tier1 virtual Machines:

Snagit Capture Snagit Capture

 

90% increase in Shared memory in Tier3 virtual Machines:

Snagit Capture Snagit Capture

 

Perhaps what was most interesting was the manner in which TPS consolidated pages once small pages were enabled.  The impact was not realized right away nor was it a gradual gain in memory efficiency as vSphere scanned for duplicate pages.  Rather it seemed to happen in batch almost all at once 12 hours after large pages had been disabled and VMs had been moved back onto the host:

Snagit Capture

 

So for those of you who may be scratching your heads wondering what is happening to your consolidation ratios lately, perhaps this has some or everything to do with it.  Is there an action item to be carried out here? That depends on what your top priority when comparing infrastructure performance in one hand and maximized consolidation in the other.

Those who are on a lean infrastructure budget (home lab would be an ideal fit here), consider forcing small pages to greatly enhance TPS opportunities to stretch your lab dollar which has been getting consumed by modern operating systems and and increasing number of VMware and 3rd party appliances.

Can you safely disable large pages in production clusters? It’s a performance question I can’t answer that globally.  You may or may not see performance hit to your virtual machines based on their workloads.  Remember that the use of small memory pages and AMD Rapid Virtualization Indexing (RVI) and Intel Extended Page Tables (EPT) is mutually exclusive.  Due diligence testing is required for each environment.  As it is a per host setting, testing with the use of vMotion really couldn’t be easier.  Simply disable large pages on one host in a cluster and migrate the virtual machines in question to that host and let them simmer.  Compare performance metrics before and after.  Query your users for performance feedback (phrase the question in a way that implies you added horsepower instead of asking the opposite “did the application seem slower?”)

That said, I’d be curious to hear if anyone in the community disables large pages in their environments as a regular habit or documented build procedure and what the impact has been if any on both the memory utilization as well as performance.

Last but not least, Duncan has another good blog post titled How many pages can be shared if Large Pages are broken up?  Take a look at that for some tips on using ESXTOP to monitor TPS activity.

Update 3/21/13:  I didn’t realize Gabrie had written about this topic back in January 2011.  Be sure to check out his post Large Pages, Transparent Page Sharing and how they influence the consolidation ratio.  Sorry Gabrie, hopeuflly understand I wasn’t trying to steal your hard work and originality :)

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Large Memory Pages and Shrinking Consolidation Ratios

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/19/large-memory-pages-and-shrinking-consolidation-ratios/feed/ 11 Baremetalcloud Special Promo Through MikeLaverick.com http://www.boche.net/blog/index.php/2013/03/14/baremetalcloud-special-promo-through-mikelaverick-com/ http://www.boche.net/blog/index.php/2013/03/14/baremetalcloud-special-promo-through-mikelaverick-com/#comments Thu, 14 Mar 2013 16:50:58 +0000 jason http://www.boche.net/blog/?p=4627 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Baremetalcloud Special Promo Through MikeLaverick.com

]]> Snagit CaptureHe’s Laverick by name, Maverick by nature (and if I might add, a very cool chap and my friend) – Mike Laverick, formerly of RTFM Education of which I was a LONG time reader going back to my Windows and Citrix days, now has a blog cleverly and conveniently situated at mikelaverick.com.  Since Mike joined forces with VMware, he’s been focused on vCloud evangelism and recently visited the Sydney/Melbourne VMUG where he was inspired with a new interest in home labs by AutoLab ala Alastair Cooke of Demitasse fame.  AutoLab has garnered some much deserved attention and adoption.  One organization that has taken an interest is baremetalcloud who provide IaaS via AutoLab on top of physical hardware for its customers.

Long story short, baremetalcloud is offering a special promotion to the first 100 subscribers through Mike’s blog.  Visit the Maverick’s blog via the link in the previous sentence where you can grab the promo code and reserve your baremetalcloud IaaS while supplies last.  Mike also walks through an end to end deployment so you can get an idea of what that looks like beforehand or use it as a reference in case you get stuck.

Thank you Mike, Alastair, and baremetalcloud for lending your hand to the community.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Baremetalcloud Special Promo Through MikeLaverick.com

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/14/baremetalcloud-special-promo-through-mikelaverick-com/feed/ 0 vCLIDROID Available for Android http://www.boche.net/blog/index.php/2013/03/07/vclidroid-available-for-android/ http://www.boche.net/blog/index.php/2013/03/07/vclidroid-available-for-android/#comments Thu, 07 Mar 2013 20:41:53 +0000 jason http://www.boche.net/blog/?p=4618 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vCLIDROID Available for Android

]]> Snagit CaptureThis free vSphere management handheld app crossed my desk by way of its author Timothé Poznanski back on February 23rd.  I don’t have an Android based device myself to test but those who do should feel free to check this out and let Timothé and/or myself what you think.

 

 

 

From Google Play:

Description

vCLIDROID is all about Command Line Interface for VMware ESXi.

vSphere CLI Interface Reference :

  • - esxcli
  • - vicfg
  • - vmkfstools
  • - vmware-cmd

App Screenshots

Snagit Capture

Snagit Capture

Snagit Capture

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

vCLIDROID Available for Android

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/07/vclidroid-available-for-android/feed/ 0 Book Review: VMware vSphere 5 Building a Virtual Datacenter http://www.boche.net/blog/index.php/2013/03/04/book-review-vmware-vsphere-5-building-a-virtual-datacenter/ http://www.boche.net/blog/index.php/2013/03/04/book-review-vmware-vsphere-5-building-a-virtual-datacenter/#comments Mon, 04 Mar 2013 13:30:43 +0000 jason http://www.boche.net/blog/?p=4601 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Book Review: VMware vSphere 5 Building a Virtual Datacenter

]]> Snagit Capture

Publication Date: August 30, 2012 | ISBN-10: 0321832213 | ISBN-13: 978-0321832214 | Edition: 1

I’m long overdue on book reviews and I need to start off with an apology to the authors for getting this one out so late.  The title is VMware vSphere 5 Building a Virtual Datacenter by Eric Maillé and René-François Mennecier (Foreword by Chad Sakac and Technical Editor Tom Keegan).  This is a book which caught me off guard a little because I was unaware of the authors (both in virtualization and cloud gigs at EMC Corporation) but nonetheless meeting new friends in virtualization is always pleasant surprise.  It was written prior to and released at the beginning of September 2012 with vSphere coverage up to version 5.0 which launched early in September 2011.

The book starts off with the first two chapters more or less providing a history of VMware virtualization plus coverage of most of the products and where they fit.  I’ve been working with VMware products since just about the beginning and as such I’ve been fortunate to be able to absorb all of the new technology in iterations as it came over a period of many years.  Summarizing it all in 55 pages felt somewhat overwhelming (this is not by any means a negative critique of the authors’ writing).  Whereas advanced datacenter virtualization was once just a concatenation of vCenter and ESX, the portfolio has literally exploded to a point where design, implementation, and management has gotten fairly complex for IT when juggling all of the parts together.  I sympathize a bit for late adopters – it really must feel like a fire hose of details to sort through to flesh out a final bill of materials which fits their environment.

From there, the authors move on to cover key areas of the virtualized and consolidated datacenter including storage and networking as well as cluster features, backup and disaster recovery (including SRM), and installation methods.  In the eighth and final chapter, a case study is looked at in which the second phase of a datacenter consolidation project must be delivered.  Last but not least is a final section titled Common Acronyms which I’ll unofficially call Chapter 9.  It summarizes and translates acronyms used throughout the book.  I’m not sure if it’s unique but it’s certainly not a bad idea.

To summarize, the book is 286 pages in length, not including the index.  It’s not a technical deepdive which covers everything in the greatest of detail but I do view it as a good starting point which is going to answer a lot of questions for beginners and beyond as well as provide some early guidance along the path of virtualization with vSphere.  The links above will take you directly to the book on Amazon where you can purchase a paperback copy or Kindle version of the book.  Enjoy and thank you Eric and René-François.

Chapter List

  1. From Server Virtualization to Cloud Computing
  2. The Evolution of vSphere 5 and its Architectural Components
  3. Storage in vSphere 5
  4. Servers and Network
  5. High Availability and Disaster Recovery Plan
  6. Backups in vSphere 5
  7. Implementing vSphere 5
  8. Managing a Virtualization Project
  9. Common Acronyms

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Book Review: VMware vSphere 5 Building a Virtual Datacenter

Related Posts

]]> http://www.boche.net/blog/index.php/2013/03/04/book-review-vmware-vsphere-5-building-a-virtual-datacenter/feed/ 1 VAAI and the Unlimited VMs per Datastore Urban Myth http://www.boche.net/blog/index.php/2013/02/28/vaai-and-the-unlimited-vms-per-datastore-urban-myth/ http://www.boche.net/blog/index.php/2013/02/28/vaai-and-the-unlimited-vms-per-datastore-urban-myth/#comments Thu, 28 Feb 2013 17:50:11 +0000 jason http://www.boche.net/blog/?p=4578 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

VAAI and the Unlimited VMs per Datastore Urban Myth

]]> Speaking for myself, it’s hard to believe that just a little over 2 years ago in October 2010, many were rejoicing the GA release of vSphere 4.1 and its awesome new features and added scalability.  It seems so long ago.  The following February 2011, Update 1 for vSphere 4.1 was launched and I celebrated my one year anniversary as a VCDX certificate holder.  Now two years later, 5.0 and 5.1 have both seen the light of day along with a flurry of other products and acquisitions rounding out and shaping what is now the vCloud Suite.  Today I’m as much involved with vSphere as I think I ever have been.  Not so much in the operational role I had in the past, but rather a stronger focus on storage integration and meeting with Dell Compellent/VMware customers on a regular basis.

I began this article with vSphere 4.1 for a purpose.  vSphere 4.1 shipped with a new Enterprise Plus feature named vStorage APIs for Array Integration or VAAI for short (pronounced ‘vee double-ehh eye’ to best avoid twist of the tongue).  These APIs offered three different hardware offload mechanisms for block storage enabling the vSphere hypervisor to push some of the storage related heavy lifting to a SAN which supported the APIs.  One of the primitives in particular lies at the root of this topic and a technical marketing urban myth that I have seen perpetuated off and on since the initial launch of VAAI.  I still see it pop up from time to time through present day.

One of the oldest debates in VMware lore is “How many virtual machines should I place on each datastore?”  For this discussion, the context is block storage (as opposed to NFS).  There were all sorts of opinions as well as technical constraints to be considered.  There was the tried and true rule of thumb answer of 10-15-20 which has more than stood the test of time.  The best qualified answer was usually: “Whatever fits best for your consolidated environment” which translates to “it depends” and an invoice in consulting language.

When VAAI was released, I began to notice a slight but alarming trend of credible sources citing claims that the Atomic Test and Set or Hardware Assisted Locking primitive once and for all solved the VMs per LUN conundrum to the point that the number of VMs per LUN no longer mattered because LUN based SCSI reservations were now a thing of the past.  To that point, I’ve got marketing collateral saved on my home network that literally states “unlimited number of VMs per LUN with ATS!”  Basically, VAAI is the promise land – if you can get there with compatible storage and can afford E+ licensing, you no longer need to worry about VM placement and LUN sprawl to satisfy performance needs and  generally reduce latency across the board.  I’ll get to why that doesn’t work in a moment but for the time being I think the general public, especially veterans, remained cautious and less optimistic – and this was good.

Then vSphere 5.0 was released.  By this time, VAAI was made more highly available and affordable to customers in the Enterprise tier and additional primitives had been added for both block and NFS based storage.  In addition, VMware added support for 64TB block datastores without using extents (a true cause for celebration in its own right).  This new feature aligned perfectly with the ATS urban myth because where capacity may have been a limiting constraint in the past, that issue has certainly been lifted now.  To complement that, consistently growing density drives and reduction of cost/GB in arrays and thin provisioning made larger datastores easily achievable.  Marketing decks were updating accordingly.  Everything else being equal, we should now have no problem nor hesitation with placing hundreds, if not thousands of virtual machines on a single block datastore as if it were NFS and free from the constraints associated with the SCSI protocol.

The ATS VAAI primitive was developed to address infrastructure latency as a result of LUN based SCSI reservations which were necessary for certain operations such as creating and deleting files on a LUN, growing a file in size, creating and extending datastores.  We encounter these types of operations by doing things like powering on virtual machines individually or in large groups such as in a VDI environment, creating vSphere snapshots (very popular integration point for backup technologies), provisioning virtual machines from a template.  All of these tasks have one thing in common: they result in the change of metadata on the LUN which in turn necessitates a LUN level lock by the vSphere host making the change.  This lock, albeit very brief in duration, drives noticeable storage I/O latency in large iterations for the hosts and virtual machines “locked out” of the LUN.  The ATS primitive offloads the locking mechanism to the array which only locks the data being updated instead of locking the entire LUN.  Any environment which has been historically encumbered by these types of tasks is going to benefit from the ATS primitive and a reduction of storage latency (both reads and writes, sequential and random) will be the result.

With that overview of ATS out of the way, let’s revisit the statement again and see if it makes sense: “unlimited number of VMs per LUN with ATS!”  If the VMs we’re talking about frequently exhibit the behavior patterns discussed above which cause SCSI reservations, then without a doubt, ATS is going to replace the LUN level locking mechanism as the previous bottleneck and reduce storage latency.  This in turn will allow more VMs to be placed on the LUN until the next bottleneck is introduced.  Unlimited?  Not even close to being correct.  And what about VMs which don’t fit the SCSI reservation use case?  Suppose I use array based snapshots for data protection?  Suppose I don’t use or there is a corporate policy against vSphere snapshots (trust me, they’re out there, they exist)?  Maybe I don’t have a large scale VDI environment or boot storms are not a concern.  This claim I see from time to time makes no mention of use cases and conceivably applies to me as well meaning in an environment not constrained by classic SCSI reservation problem.  I too can leverage VAAI ATS to double, triple, place an unlimited amount of VMs per block datastore.  I talk with customers on a fairly regular basis who are literally confused about VM to LUN placement because of mixed messages they receive, especially when it comes to VAAI.

Allow me to perfrom some Eric Sloof style VMware myth busting and put the uber VMs per ATS enabled LUN claim to the test.  Meet Mike – a DBA who has taken over his organization’s vSphere 5.1 environment.  Mike spends the majority of his time keeping up with four different types of database technologies deployed in his datacenter.  Unfortunately that doesn’t leave Mike much time to read vSphere Clustering Deepdives or Mastering VMware vSphere but he knows well enough to not use vSphere snapshotting because he has an array based data consistent solution which integrates with each of his databases.

Fortunately, Mike has a stable and well performing environment exhibited to the left which the previous vSphere architect left for him.  Demanding database VMs, 32 in all, are distributed across eight block datastores.  Performance characteristics for each VM in terms of IOPS and Throughput are displayed (these are real numbers generated by Iometer in my lab).  The previous vSphere architect was never able to get his organization to buy off on Enterprise licensing and thus the environment lacked VAAI even though their array supported it.

Unfortunately for Mike, he tends to trust random marketing advice without thorough validation or research on impact to his environment.  When Mike took over, he heard from someone that he could simplify infrastructure management by implementing VAAI ATS and consolidate his existing 32 VMs to just a single 64TB datastore on the same array, plus grow his environment by adding basically an unlimited amount of VMs to the datastore providing there is enough capacity.

This information was enough to convince Mike and his management that, risks aside, management and troubleshooting efficiency through a single datastore was definitely the way to go.  Mike installed his new licensing, ensured VAAI was enabled on each host of the cluster, and carved up his new 64TB datastore which is backed by the same pool of raw storage and spindles servicing the eight original datastores.  Over the weekend, Mike used Storage vMotion to migrate his 32 eager zero thick database VMs from their eight datastores to the new 64TB datastore.  He then destroyed his eight original LUNs and for the remainder of that Sunday afternoon, he put his feet up on the desk and basked in the presence of his vSphere Client exhibiting a cluster of hosts and 32 production database VMs running on a single 64TB datastore.

On Monday morning, his stores began to open up on the east coast and in the midwest.  At about 8:30AM central time, the helpdesk began receiving calls from various stores that the system seemed slow.  Par for the course for a Monday morning but with great pride and ethics, Mike began health checks on the database servers anyway.  While he was busy with that, stores on the west coast opened for business and then the calls to the helpdesk increased in frequency and urgency.  The system was crawling and in some rare cases the application was timing out producing transaction failure messages.

Finding no blocking or daytime re-indexing issues at the database layer, Mike turned to the statistical counters for storage and saw a significant decrease in IOPS and Throughput across the board – nearly 50% (again, real Iometer numbers to the right).  Conversely, latency (which is not shown) was through the roof which explained the application timeout failures.  Mike was bewildered.  He had made an additional investment in hardware assisted offload technology and was hoping for a noticeable increase in performance.  Least of all, he didn’t expect a net reduction in performance, especially this pronounced.  What happened?  How is it possible to change the VM:datastore ratio, backed by the same exact pool of storage Tier and RAID type, and come up with a dramatic shift in performance?  Especially when one resides in the kingdom of VAAI?

Queue Depth.  There’s only so much active I/O to go around, per LUN, per host, at any given moment in time.  When multiple VMs on the same host reside on the same LUN, they must share the queue depth of that LUN.  Queue depth is defined in many places along the path of an I/O and at each point, it specifies how many I/Os per LUN per host can be “active” in terms of being handled and processed (decreases latency) as opposed to being queued or buffered (increases latency).  Outside of an environment utilizing SIOC, the queue depth that each virtual machine on a given LUN per host must share is 32 as defined by the default vSphere DSNRO value.  What this effectively means is that all virtual machines on a host sharing the same datastore must share a pool of 32 active I/Os for that datastore.

Applied to Mike’s two-host cluster, whereas he used to have four VMs per datastore evenly distributed across two hosts, effectively each VM had a sole share of 16 IOPS to work with (1 datastore x queue depth of 32 x 2 hosts / 4 VMs or simplified further 1 datastore x queue depth of 32 x 1 host /2 VMs)

After Mike’s consolidation to a single datastore, 16 VMs per host had to share a single LUN with a default queue depth of 32 which reduced each virtual machine’s active IOPS from 16 to 2.

Although the array had the raw storage spindle count and IOPS capability to provide fault tolerance, performance, and capacity, at the end of the day, queue depth ultimately plays a role in performance per LUN per host per VM.  To circle back to the age old “How many virtual machines should I place on each datastore?” question, this is ultimately where the old 10-15-20 rule of thumb came in:

  • 10 high I/O VMs per datastore
  • 15 average I/O VMs per datastore
  • 20 low I/O VMs per datastore

Extrapolated across even the most modest sized cluster, each VM above is going to get a fairly sufficient share of the queue depth to work with.  Assuming even VM distribution across clustered hosts (you use DRS in automated mode right?), each host added to the cluster and attached to the shared storage brings with it, by default, an additional 32 IOPS per datastore for VMs to share in.  Note that this article is not intended to be an end to end queue depth discussion and safe assumptions are made that the DSNRO value of 32 represents the smallest queue depth in the entire path of the I/O which is generally true with most installations and default HBA card/driver values.

In summary, myth busted.  Each of the VAAI primitives was developed to address specific storage and fabric bottlenecks.  While the ATS primitive is ideal for drastically reducing SCSI reservation based latency and it can increase the VM: datastore ratio to a degree, it was never designed to imply large sums of or an unlimited number of VMs per datastore because this assumption simply does not factor in other block based storage performance inhibitors such as queue depth, RAID pools, controller/LUN ownership model, fabric balancing, risk, etc.  Every time I hear the claim, it sounds as foolish as ever.  Don’t be fooled.

Update 3/11/13: A few related links on queue depth:

QLogic Fibre Channel Adapter for VMware ESX User’s Guide

Execution Throttle and Queue Depth with VMware and Qlogic HBAs

Changing the queue depth for QLogic and Emulex HBAs (VMware KB 1267)

Setting the Maximum Outstanding Disk Requests for virtual machines (VMware KB 1268)

Controlling LUN queue depth throttling in VMware ESX/ESXi (VMware KB 1008113)

Disk.SchedNumReqOutstanding the story (covers Disk.SchedQuantum, Disk.SchedQControlSeqReqs, and Disk.SchedQControlVMSwitches)

Disk.SchedNumReqOutstanding and Queue Depth (an article I wrote back in June 2011)

Last but not least, a wonderful whitepaper from VMware I’ve held onto for years:  Scalable Storage Performance VMware ESX 3.5

 

 

 

 

 

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

VAAI and the Unlimited VMs per Datastore Urban Myth

Related Posts

]]> http://www.boche.net/blog/index.php/2013/02/28/vaai-and-the-unlimited-vms-per-datastore-urban-myth/feed/ 21 Thin Provisioning Storage Choices http://www.boche.net/blog/index.php/2013/02/08/thin-provisioning-storage-choices/ http://www.boche.net/blog/index.php/2013/02/08/thin-provisioning-storage-choices/#comments Fri, 08 Feb 2013 13:00:28 +0000 jason http://www.boche.net/blog/?p=4555 Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Thin Provisioning Storage Choices

]]> I talk with a lot of customers including those confined to vSphere, storage, and general datacenter management roles.  The IT footprint size varies quite a bit between discussions as does the level of experience across technologies. However, one particular topic seems to come up at regular intervals when talking vSphere and storage: Thin Provisioning – where exactly is the right place for it in the stack?  At the SAN layer? At the vSphere layer? Both?

Virtualization is penetrating datacenters from multiple angles: compute, storage, network, etc.  Layers of abstraction seem to be multiplying to provide efficiency, mobility, elasticity, high availability, etc.  The conundrum we’re faced with is that some of these virtualization efforts converge.  As with many decisions to be made, flexibility yields an array of choices.  Does the convergence introduce a conflict between technologies? Do the features “stack”?  Do they complement each other? Is one solution better than the other in terms of price or performance?

I have few opinions around thin provisioning (and to be clear, this discussion revolves around block storage.  Virtual machine disks are natively thin provisioned and written into thin on NFS datastores).

1.  Deploy and leverage with confidence.  Generally speaking, thin provisioning at either the vSphere or storage layer has proven itself as both cost effective and reliable for the widest variety of workloads including most tier 1 applications.  Corner cases around performance needs may present themselves and full provisioning may provide marginal performance benefit at the expense of raw capacity consumed up front in the tier(s) where the data lives.  However, full provisioning is just one of many ways to extract additional performance from existing storage.  Explore all available options.  For everything else, thinly provision.

2.  vSphere or storage vendor thin provisioning?  From a generic standpoint, it doesn’t matter so much, other than choose at least one to achieve the core benefits around thin provisioning.  Where to thin provision isn’t really a question of what’s right, or what’s wrong.  It’s about where the integration is the best fit with respect to other storage hosts that may be in the datacenter and what’s appropriate for the organizational roles.  Outside of RDMs, thin provisioning at the vSphere or storage layer yields about the same storage efficiency for vSphere environments.  For vSphere environments alone, the decision can be boiled down to reporting, visiblity, ease of use, and any special integration your storage vendor might have tied to thin provisioning at the storage layer.

The table below covers three scenarios of thin provisioning most commonly brought up.  It reflects reporting and storage savings component at the vSphere and SAN layers.  In each of the first three use cases, a VM with 100GB of attached .vmdk storage is provisioned of which a little over 3GB is consumed by an OS and the remainder is unused “white space”.

  • A)  A 100GB lazy zero thick VM is deployed on a 1TB thinly provisioned LUN.
    • The vSphere Client is unaware of thin provisioning at the SAN layer and reports 100GB of the datastore capacity provisioned into and consumed.
    • The SAN reports 3.37GB of raw storage consumed to SAN Administrators.  The other nearly 1TB of raw storage remains available on the SAN for any physical or virtual storage host on the fabric.  This is key for the heterogeneous datacenter where storage efficiency needs to be spread and shared across different storage hosts beyond just the vSphere clusters.
    • This is the default provisioning option for vSphere as well as some storage vendors such as Dell Compellent.  Being the default, it requires the least amount of administrative overhead and deployment time as well as providing infrastructure consistency.  As mentioned in the previous bullet, thin provisioning at the storage layer provides a benefit across the datacenter rather than exclusively for vSphere storage efficiency.  All of these benefits really make thin provisioning at the storage layer an overwhelmingly natural choice.
  • B)  A 100GB thin VM is deployed on a 1TB fully provisioned LUN.
    • The vSphere Client is aware of thin provisioning at the vSphere layer and reports 100GB of the datastore capacity provisioned into but only 3.08GB consumed.
    • Because this volume was fully provisioned instead of thin provisioned, SAN Administrators see a consumption of 1TB consumed up front from the pool of available raw storage.  Nearly 1TB of unconsumed datastore capacity remains available to the vSphere cluster only.  Thin provisioning at the vSphere layer does not leave the unconsumed raw storage available to other storage hosts on the fabric.
    • This is not the default provisioning option for vSphere nor is it the default volume provisioning default for shared storage.  Thin provisioning at the vSphere layer yields roughly the same storage savings as thin provisioning at the SAN layer.  However, only vSphere environments can expose and take advantage of the storage efficiency.  Because it is the default deployment option, it requires a slightly higher level of administrative overhead and can lead to environment inconsistency.  On the other hand, for SANs which do not support thin provisioning, vSphere thin provisioning is a fantastic option, and the only remaining option for block storage efficiency.
  • C)  A 100GB thin VM is deployed on a 1TB thinly provisioned LUN – aka thin on thin.
    • Storage efficiency is reported to both vSphere and SAN Administrator dashboards.
    • The vSphere Client is aware of thin provisioning at the vSphere layer and reports 100GB of the datastore capacity provisioned into but only 3.08GB consumed.
    • The SAN reports 3.08GB of raw storage consumed.  The other nearly 1TB of raw storage remains available on the SAN for any physical or virtual storage host on the fabric.  Once again, the efficiency benefit is spread across all hosts in the datacenter.
    • This is not the default provisioning option for vSphere and as a result the same inconsistencies mentioned above may result.  More importantly, thin provisioning at the vSphere layer on top of thin provisioning at the SAN layer doesn’t provide a significant amount additional storage efficiency.  The numbers below show slightly different but I’m going to attribute that difference to non-linear delta caused by VMFS formatting and call them a wash in the grand scheme of things.  While thin on thin doesn’t adversely impact the environment, the two approaches don’t stack.  Compared to just thin provisioning at the storage layer, the draw for this option is for reporting purposes only.

What I really want to call out is the raw storage consumed in the last column.  Each cell outlined in red reveals the net raw storage consumed before RAID overhead – and conversely paints a picture of storage savings and efficiency allowing a customer to double dip on storage or provision capacity today at next year’s cost – two popular drivers for thin provisioning.

      Vendor Integration
      vSphere Administrators SAN Administrators
      vSphere Client Virtualized Storage
      Virtual Disk Storage Datastore Capacity Page Pool Capacity
  100GB VM 1TB LUN Provisioned Consumed Provisioned Consumed Provisioned Consumed+
A Lazy Thick Thin Provision 100GB 100GB 1TB 100GB 1TB 3.37GB*
B Thin Full Provision 100GB 3.08GB 1TB 3.08GB 1TB 1TB
C Thin Thin Provision 100GB 3.08GB 1TB 3.08GB 1TB 3.08GB*
                 
  1TB RDM 1TB LUN            
D vRDM Thin Provision 1TB 1TB n/a n/a 1TB 0GB
E pRDM Thin Provision 1TB 1TB n/a n/a 1TB 0GB

+ Numbers exclude RAID overhead to provide accurate comparisons

* 200MB of pages consumed by the VMFS-5 file system was subtracted from the total to provide accurate comparisons

There are two additional but less mainstream considerations to think about: virtual and physical RDMs.  Neither can be thinly provisioned at the vSphere layer.  Storage efficiency can only come from and be reported on the SAN.

  • D and E)  Empty 1TB RDMs (both virtual and physical) are deployed on 1TB LUNs thinly provisioned at the storage layer.
    • Historically, the vSphere Client has always been poor at providing RDM visibility.  In this case, the vSphere Client is unaware of thin provisioning at the SAN layer and reports 1TB of storage provisioned (from somewhere unknown – the ultimate abstraction) and consumed.
    • The SAN reports zero raw storage consumed to SAN Administrators.  2TB of raw storage remains available on the SAN for any physical or virtual storage host on the fabric.
    • Again, thin provisioning from your storage vendor is the only way to write thinly into RDMs today.

So what is my summarized recommendation on thin provisioning in vSphere, at the SAN, or both?  I’ll go back to what I mentioned earlier, if the SAN is shared outside of the vSphere environment, then thin provisioning should be performed at the SAN level so that all datacenter hosts on the storage fabric can leverage provisioned but yet unallocated raw storage..  If the SAN is dedicated to your vSphere environment, then there really no right or wrong answer.  At that point it’s going to depend on your reporting needs, maybe the delegation of roles in your organization, and of course the type of storage features you may have that combine with thin provisioning to add additional value.  If you’re a Dell Compellent Storage Center customer, let the the vendor provided defaults guide you: Lazy zero thick virtual disks on datastores backed by thinly provisioned LUNs.  Thin provisioning at the storage layer is also going to save customers a bundle in unconsumed tier 1 storage costs.  Instead of islands of tier 1 pinned to a vSphere cluster, the storage remains freely available in the pool for any other storage host with tier 1 performance needs.  For virtual or physical RDMs, thin provisioning on the SAN is the only available option.  I don’t recommend thin on thin to compound or double space savings because it simply does not work the way some expect it to.  However, if there is a dashboard reporting need, go for it.

Depending on your storage vendor, you may have integration available to you that will provide management and reporting across platforms.  For instance, suppose we roll with option A above: thin provisioning at the storage layer.  Natively we don’t have storage efficiency visibility within the vSphere Client.  However, storage vendor integration through VASA or a vSphere Client plug-in can bring storage details into the vSphere Client (and vise versa).  One example is the vSphere Client plug-in from Dell Compellent shown below.  Aside from the various storage and virtual machine provisioning tasks it is able to perform, it brings a SAN Administrator’s dashboard into the vSphere Client.  Very handy in small to medium sized shops where roles spread across various technological boundaries.

Snagit Capture

Lastly, I thought I’d mention UNMAP – 1/2 of the 4th VAAI primitive for block storage.  I wrote an article last summer called Storage: Starting Thin and Staying Thin with VAAI UNMAP.  For those interested, the UNMAP primitive works only with thin provisioning at the SAN layer on certified storage platforms.  It was not intended to and does not integrate with thinly provisioned vSphere virtual disks alone.  Thin .vmdks in which data has been deleted from within will not dehydrate unless storage vMotioned. Raw storage pages will remain “pinned” to the datastore where the .vmdk resides until is is moved or deleted.  Only then can the pages be returned back to the pool if the datastore resides on a thin provisioned LUN.

Post from: boche.net - VMware Virtualization Evangelist

Copyright (c) 2010 Jason Boche. The contents of this post may not be reproduced or republished on another web page or web site without prior written permission.

Thin Provisioning Storage Choices

Related Posts

]]> http://www.boche.net/blog/index.php/2013/02/08/thin-provisioning-storage-choices/feed/ 5