Virtually Jason

Memory overcommitment remains a contentious topic, despite some really great studies on the topic.  Regarding VDI, I’ve heard opinions ranging from “0 memory overcommitment!” to “200%, 300%, it’s fine!”  I figured that I’d share my thoughts on the topic and see if anyone else wants to weigh in on the discussion.  First though, some points about the decision. The main argument that I’ve heard against memory overcommitment boils down to protecting the user experience.  Since virtual desktops have users actively logged into and using them, even slight performance degradation is immediately noticed.  We all know that hypervisor swapping is Very Bad for performance.  If you don’t overcommit your hosts’ memory, you won’t have swapping, so why overcommit? The simple answer is that, while 2 GB of RAM for a single desktop is no big deal, 2 GB of dedicated RAM for 1000 desktops is a lot harder to accept.  Memory overcommitment can be an important technique for bringing down the cost of a VDI s

One of my customers asked me to help them migrate their VMs from an ESX 4 environment into a brand new ESX 5 environment.  This new environment had brand new servers and storage (as well as fibre switches); they needed a forklift.  We discussed migration strategies (presenting some shared storage to both environments, etc.) but, due to a long list of very environment specific considerations, we determined that cold migrations during outage windows would be the best solution. As such, there was a fair amount of hands on work that would be required.  Given that a large amount of the work would need to be done after hours, automation became a high priority.  To that end, I put together a PowerCLI script that the migration team could use to perform these migrations.  This script is designed to be used by an administrator who can babysit the process, for it spits out its status updates and end results so that the administrator can validate the important settings. Using the script drama