Download here: http://vsential.com/wp-content/uploads/2011/05/Report-Datastores.ps1_.txt
Today I was approached by one of my coworkers and was asked,
Why do you only cluster servers with the same amount of RAM together? Does it really matter?
This provoked me to write a little bit about this. I would target this more for management who like to buy servers one at a time and don’t have a firm grip on VMware HA Clusters.
Why does it matter to me? An easy answer to this would be the ease of management and it is best practice. When you have servers clustered together that are the same you don’t have to think as hard when it comes to the design regarding the cluster and failover. Before I dive into this, let’s discuss what a cluster is in VMware and what you gain from them.
A cluster can be defined as a pooled set of resources. More simply put, you have all your resources “clustered” in one set that can be shared accordingly. Now this statement is both true and false. Yes, you pool your resources together and no, they aren’t technically shared in the sense that they aren’t available to VMs that are on different hosts. Meaning, a VM on Host A can’t use a CPU on Host A and a CPU on Host B. Make sense? A better way to think of it is resource aggregation. VMware defines clustering as,
Now that we have an idea behind the definition of a cluster let’s look at what clusters are used for. The most common uses for a cluster in VMware are to take advantage of HA and DRS. To tie back to the original question, there are caveats that must be taken into consideration when adding hosts to a cluster. As a best practice we must try our best not to have hardware with different specifications in the same cluster. If you add hosts with different specs into the same cluster you end up with an unbalanced cluster. What exactly is an unbalanced cluster? Duncan Epping and Frank Denneman’s book, VMware vSphere 4.1: HA and DRS Technical Deepdive, defines this as,
When you have an unbalanced cluster the Admission Control Policy calculations will not be what you might expect. When Admission Control is enabled the worse case scenario is taken into account. Which means, that when the calculation is made for available slots, the largest host is essentially left out of the equation. This is in the case of setting your host failures to a single host. Due to this, the best way to make sure you have setup a good cluster is to deploy machines with the same amount of resources for both memory and CPU.
This is not a full blown write-up regarding HA Clusters because I don’t think I need to reinvent the wheel when it was written about so well by Duncan Epping in his and Frank Denneman’s recent technical deepdive book. This was definitely enough though to explain my answer to the question I was asked by my coworker. If you would like to learn more about VMware HA then jump over to Duncan’s blog, Yellow-Bricks, and read up on all of the HA wonderfulness!
I ran into an issue today when patching a couple of standalone ESXi hosts. There were no VMs built out on these hosts yet so I took the quick second to update the hosts with the latest patches before the 4.1 Update 1 patches.
Poof!
Went to deploy a virtual machine and install VMware Tools, no go! Was presented with the wonderful:
This has actually been an issue that, from searching, seems to be something that likes to poke its head out from time to time. The cause is typically from a botched bundle installation. Some of the goofy things I saw were the /productLocker directory was not accessible and neither were any of the directories in which it was symlinked to. After a few minutes of poking around I decided to run the bundle installation one more time. Installed the bundle and rebooted and VIOLA…the symlinks were accessible and mounting of the VMware Tools installer ISO was working again.
If you run into this problem I would try the following:
This may not resolve the issue for everyone but it seem to work on the two ESXi hosts that I had this happen on. If it doesn’t sound off in the comments and we can see if we can get you moving along!
This past weekend I was faced with a challenge of moving from an old unsupported SAN on a 3.5 deployment to a new supported SAN and a new 4.1 deployment. I was in dire need for a quick solution for migrating data from one SAN to another. Some would say, “Just use Storage vMotion to move the VMs from the old storage to the new.” I get that, but, I was unable to utilize that feature because the old deployment was not licensed for it.
[blocknote class="red" title="Solution"]In comes Veeam Backup & Replication to save the day.[/blocknote]
The deployment was a small deployment, around 20 VMs. The solution I ended up with was using the VM Copy functionality to copy the VMs from the old SAN to the new SAN. Once the data was copied over, I added the VMs to inventory, upgraded VMware Tools, and then upgraded Virtual Hardware. Powered everything up and viola…migrated VMs now running in 4.1 on the new SAN.
Using the VM Copy function was extremely easy to get setup and started. The steps that I took to get it moving were:
I won’t go into detail on how to install Veeam as this is covered in many places online. I will, however, go through the steps on creating the VM Copy Job.
The first step was to configure the VM Copy Job, as seen here:
After clicking Next you will be asked what Processing Mode you will be using. In my particular case, I had Veeam installed on a VM and so I picked Virtual Appliance Mode with Network Failover.
The next step in this simple process is to add the VMs that you want to copy. This is a pretty self explanatory step, here is what you should see:
After adding the VMs you will be asked for a destination. This, of course, will be your new SAN and new hosts. Just select the host and datastore you want to copy the VMs into.
After adding the VMs that you want to copy with this job, you will continue on and be presented with a screen that will ask you if you want to use VSS in the VM to get a transactional consistant copy. In my particular case, I had a maintenance window for the downtime of the VMs so I powered them down to do the copy, therefore, I didn’t select anything.
The final configuration step is to determine if you want to schedule it to run automatically or not. This can come in handy if you want to have the job start after hours when you won’t be in front of a machine. In my case, I was sitting right in front of my machine at home.
And the finale, you are now one click away from having Veeam do some work for you. Just click Finish or select the checkbox to run the job as soon as you click Finish.
Pretty simple process and it definitely made it easy for me to get around the typical tools you would use to do a migration such as Storage vMotion and VMware Converter. Once you have the VMs over you can then browse your datastores and add the VMs to inventory. In this instance, I had to upgrade VMware Tools and upgrade the virtual hardware to complete the process. Confirmed everything was working as normal and called it a day! Thanks Veeam for saving the day yet again!
[note class="download"]You can download a trial of Veeam Backup & Replication direct from Veeam’s Website![/note]
If you have any questions or comments then please feel free to post up in the comments!