The VMguy

Second on the release list is an update to the standalone Converter (the better one IMO).  You can download the updated release here.  Some nice new features listed in the what’s new section of the release notes:

The VMware vCenter Converter Standalone 4.3 includes the following new functionality:

• Support for VMware vSphere 4.1 as source and destination targets
• Support for importing powered-off Microsoft Hyper-V R1 and Hyper-V R2 virtual machines
• Public API and sample code for submitting and monitoring Converter jobs
• Support for importing Windows 7 and Windows 2008 R2 sources
• Ability to throttle the data transfer from source to destination based on network bandwidth or CPU
• IPv6 support

Discontinued Support

• Support of the following operating systems is discontinued:
  • Windows 2000
  • Windows NT
• Support for OVF format is discontinued
• Support for VCB image sources is discontinued
• Linux installation support is discontinued

The way I see it, there are two dilemmas that VMware has in the way their licensing is designed today.  One of them works against VMware and one works against VMware customers (or at least makes it harder for them).  The former is definitely the bigger of the two so lets discuss that one first.  This topic comes up frequently when new versions of ESX are coming out.  We’ve already heard that an update is coming this year so I figured that since today is the half-way point in the year, this was a good time to bring up the topic again.

You probably noticed by now that there is a limitation in Standard and Enterprise editions of vSphere to a maximum of 6-cores per CPU.  The Advanced and Enterprise-Plus editions of vSphere have a licensed limit of 12-cores per CPU.  Now that Intel’s 8-core CPUs and AMD’s 12-cores are out, what’s next?  Intel and AMD are sure to develop a proc with more than 12 cores (and probably sooner than we all think).  What will happen to VMware’s licensing then?  You have to remember that from a revenue standpoint, when a 24 core proc comes out, customers will be able to run twice as many workloads on that proc (or at least 50% more).  Moore’s Law states that processing performance of CPUs will double every two years.  With the processors doubling in power so quickly, customers are typically not doubling their number of VMs in the same time period.  The result is that customers tend to have a diminishing need to increase their ESX per-CPU licensing.  I know that there are exceptions to this rule, but in the SMB space the majority are not growing that fast (at least not in this economy).  The increase in processor performance actually works against VMware’s current licensing model. It not good to have a direct connection between your main revenue stream and someone else’s CPU release schedule.  What will happen?  What’s the right answer?  Your guess is as good as mine.  Will they go to a per-vm model?  Increase their current limits?  Find some middle-ground between the two?  Will they “grandfather” their customers like AT&T did with the iPad data plans?  Only VMware knows.  My opinion is that this is an issue that has to be dealt with eventually.  Maybe this will be the year, maybe next.

The second licensing dilemma that I run into is in Site Recovery Manager.  It’s no secret that SRM is my favorite non-ESX product from VMware.  As you probably know, SRM is licensed by the physical CPU where the protected virtual machines reside or could reside.  Here’s where that model breaks down:  let’s say I have a smaller customer who’s policy is only to have a DR plan for 5 of their most critical Virtual Machines.  Those five VMs run in a cluster comprise of 5 dual CPU hosts with HA and DRS enabled.  According to the SRM licensing model, I need 10 CPUs of SRM for those 5 VMs.  That does not fly well.  The solution I’ve heard some engineers mention is to create a separate smaller cluster for just the protected VMs.  I’m not fond of that idea because it goes against the consolidation principal.  I’ve never felt that lowering your consolidation ratio was justified because it did not fit a licensing model.

I know there are people much smarter than me at work trying to find a solution to both of these scenarios.  I’m hopeful that they will get resolved in a way that’s fair to both sides.  Maybe this is the year, maybe it is not.  Either way, we’ve made it thru half of 2010, perhaps the answers lie in the last 6 months of the year.

In the past, I have reviewed all of the technical papers on the VMware site.  I’ve decided to change direction a little and I only plan on reviewing papers that would apply to the everyday VM Admin.  I’m also going to throw in my own ranking on each article (*****, 1 to 5 stars).  You will also notice a “vKeeper” reference in some of the papers.  This award is for the papers that I keep a local copy of on my computer for reference when I need them.  They are the docs that all admins should read thru and use as a reference as needed.  I have also added a section to my admin bookmark page just for the vKeeper docs.

PCoIP Display Protocol: Information and Scenario-Based Network Sizing Guide – (12 pages) A good paper with very good insight on the PCoIP protocol used in VMware View.  It gives some good suggestions and the required bandwidths needed to satisfy the end users on their desktop experience.  A must have for view deployments.  (****, 4 of 5 stars)

Application Presentation to VMware View Desktops with Citrix XenApp – (3 pages) This is a whitepaper to show how to deploy applications in VMware View desktops from XenApp.  While I can see this being useful for View admins who use XenApp, the description and instructions are very minimal.  Probably something better suited for a KB article. (**, 2 of 5 stars)

Timekeeping in VMware Virtual Machines – (26 pages) This is a very important topic for all VM Admins to know.  Time is relevant to everything in a VM, whether you are trying to authenticate to Active Directory or troubleshooting using event logs, accurate time is very important.  This paper goes into some really great detail on how VMware maintains accurate time in VMs.  If you are a VMware admin, this should be a standard read.   (*****, 5 of 5 stars, vKeeper)

SAN System Design and Deployment Guide – (244 pages of storage goodness)  I have a storage background so I specifically enjoy this one.  If you are running ESX on SAN shared storage (you should be on some type of shared storage) then this is a must read.  This whitepaper is also very helpful if you are studying for the VCP or one of the new VCAP exams.  This is another paper I keep local and definitely one all VM admins with SAN should review.  (*****, 5 of 5 stars, vKeeper)

Best Practices for Running vSphere on NFS Storage – (14 pages) On the heels of the SAN design and deployment guide, this paper describes the best practices for running NFS on vSphere.  I like the fact that this article references outdated best practices that have changed and why they have changed.  This is a HUGE help to admins who google a topic only to find conflicting information.  My only regret on this paper is that I would like to see more detail on the advanced options and how they affect the performance of NFS.  Still a important doc for VM Admins using NFS storage.  Should be reviewed by all of them to make sure they are current in their deployment of NFS best practices.  (****, 4 of 5 stars)

Location Awareness in VMware View 4 – (8 pages) Good information for View Admins to know where to find out where their clients are connecting from.  This is a common request from hospitals to have printers “follow the user” as they float from terminal to terminal.  There are some advanced topics in this article and some Active Directory knowledge is definitely required especially when using loopback mode in group policy processing.  Good info and hopefully View will include some GUI-based  native features in the future to assist with this.  (***, 3 of 5 stars)

VMware vSphere 4.0 Security Hardening Guide – (70 pages) This is a outstanding reference for any VM Admin.  Security affects everyone’s environment, from the 3-man shop to the largest infrastructure.  Setting the precedence of a solid, secure enviornment from the ground up will provide you with a infrastructure that is solid as a rock. I recommend reviewing this paper often and keeping this one handy   (*****, 5 of 5 stars, vKeeper)

VMware vStorage Virtual Machine File System – Technical Overview and Best Practices – (13 pages) This is a entry level paper on some of the very basics of VMFS and how they relate to RDMs.  This should be a good introduction to VMFS to new VM Admins.  I hoped with “Best Practices” in the title that there would be more technical references (advanced options for VMFS and how tweaking them affects the storage performance for instance).  I was also disappointed to see the LUN size question answered vaguely, suggesting to refer to the storage vendor to size your LUNs appropriately.  I prefer Duncan’s approach to LUN sizing and it’s what I recommend to all of my customers.  (***, 3 of 5 stars)

Look for the vPaper Report again next quarter (hopefully with some new releases in between). Until then, happy reading!

I was talking to another great customer today who was excited to upgrade from two single ESX hosts to a cluster of 3 with vCenter.  We were talking back and forth about the storage and it turns out his current datastores were a bit unique.  The customer had migrated from physical slowly, perhaps a few physicals a week.  Each time a new host was converted, the customer created a new LUN and datastore and p2v’d the physical drives to a single LUN/datastore on their EVA SAN.  That LUN was also unmasked to just one of the hosts (remember, 2 single hosts – no vMotion yet).  As I talked thru their current configuration with them you can imagine the look on my face.  I was perplexed, surely there must be something completely wrong with this design.  My years at EMC and NetApp were failing me, I knew this was not a good idea but no good reason came to mind.

Then it hit me, a single ESX host currently can see up to 256 LUNs.  Initially I thought, “but they’re never going to run more than 256 VMs on a host.”  No, but they did want to start using vMotion.  Now the LUNs will need to be presented to all hosts.  This 256 LUN limit no longer relates to the single host but to the cluster as a whole.  With all LUNs presented to all hosts, as long as they keep provisioning one-LUN-per-VM, they will be limited to 255 VM’s for the cluster (one of the LUNs is for booting ESX).  This was a limit they were most certainly going to hit (and at an accelerated pace, now that they have vMotion).

This made sense quickly to the customer.  The story has a happy ending: next week we’re upgrading them to vSphere and going to storage vMotion those VMs to a place with a better design.  There’s one thing I’ve learned about storage and virtualization is that there are no wrong designs.  However, there are ones that limit functionality.

The moral of the story is to know thy vmware maximums!  Make sure to check if a single host’s limitation could affect the design of an entire cloud.

Happy Earth Day!

Better late than never.  There were some really good (and not so good) technical reads this past month:

VMware vShield Zones – Reviewers Guide – If you haven’t figured this out yet, pay close attention to the Reviewers Guides.  If you have even slightly thought of trying out a product or technology, the reviewers guide is the next best thing to having an engineer over your shoulder walking you thru the product.  This is a really good one on Zones.  I learned quite a few things about the product that I was unaware of.  It’s a great read if you need to lock down and firewall off your VMs (or if you just want to learn how the VMs talk to each other).

Performance Brief for IBM WebSphere Application Server 7.0 with VMware ESX 4 on HP ProLiant DL380 G6 Servers – This is a very specific paper on running Websphere on HP servers.  I did find some interesting bits in it however.  Specifically, configuration tips to maximize performance running Websphere in a VM.  The performance metrics should also be evaluated if you want to run Websphere on any hardware platform (perhaps even IBM).

Best Practices for Running vSphere on NFS Storage – I’m currently in a documentation war with my EMC Channel SE who swears by running VMware on NFS (You still have to convince me Steve, I’m a block-IO bigot).  This is a must-have for all Admins running VMware on NFS.  It’s also a really good guideline if you want to compare performance between file-level or block-level IO in your VMware environment and make sure your making an accurate decision.  My favorite section of this paper: “Previously thought to be Best Practices.”  Every best practice white paper should have that to debunk outdated information.  Outstanding work VMware!

PVSCSI Storage Performance -This is a paper I was waiting to see.  It compares the performance of the PVSCSI adapter to the LSI Logic adapter.  I guessed pretty close on the outcomes.  The PVSCSI adapter does perform better under higher IO workloads (some have stated only use it >2000 IOPs.)  The only thing I didn’t like about the test was that RDMs were used.  VMware has argued for the last few years that high-performance should not be a requirement for using RDMs.  So why not use what the majority of customers use in their environments?

RIM BlackBerry Enterprise Server on VMware Virtual Infrastructure Deployment Guide – I really liked and hated this paper.  I liked it because it has some really good best practices and deployment tips depending on the size of the environment.  I hated it because it definitely contains errors: Table 2 shows a BES server with 23% utilization on ESX 3.5, Table 3 shows a BES server with 27% utilization under ESX 4, Figure 12 says the CPU load went down from 27 to 23 going to vSphere – not according to your tables kids.

That will do it for this month’s White Paper Review.  We’ll see you next month and look for more great technical information.