The 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.
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.
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.
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.
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.
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:
- 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.
|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|
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.
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.
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.