Answering the question that always seems to get asked, “what is the best practice for the VM SWAP file?”
I have put this method through bench testing and found it to have the best performance, step by step for VM SWAP file configuration is:
Set up a data store in each ESX cluster for guest SWAP files, see diagram to the right. (Do not use local ESX disks! This will save more expensive SAN storage but causes latency for DRS and vMotioning of VMs.)
For each ESX host in the cluster, configure the SWAP to point to the SWAP data store.
Go through all the setting on each VM in the cluster and make sure VM SWAP file are controlled by the host, not in VM folder.
Here’s a step that some will disagree on but my testing has found it to produce the best VM performance, log into the Windows VM and set the SWAP file to be maintained by Windows. Some admins like to do 2.5 – 3.5 ratio for the memory but this is not a physical so let Windows adjust the SWAP file size. From what I have found it’s a 1:1 ratio.
Configure 1 – 3 the same for Linux but on 4 just let Let Linux do it’s own thing. Linux uses a SWAP volume which is stored in the VM’s folder.
My test results produced: Faster VM Booting, Better VM Performace, Faster vMotioning and DRS, Faster VM evacuation when ESX host is entering maintenance mode
Originally posted 2009-02-08 07:49:24. Republished by Blog Post Promoter
Are you trying to squeeze every CPU cycle out of your dual or quad core processors? Unfortunately for those who like to over-clock CPUs for gaming, over utilizing CPU doesn’t quite work the same on virtual hosts (ESX or Hyper-V).
From my experience, I know you can get anywhere from 8 – 10 vCPUs per core, but I have found a sweet spot of 4 VMs per core will provide decent performance for the user. Remember, you don’t want users waiting 30 seconds for a logon or screen refresh… Over utilizing memory will cause user frustration too.
Eric Siebert has written an excellent article on SearchNetworking.com called “Sizing server hardware” which goes into “nuts and bolts” details for sizing virtual host server hardware.
My opinion is to “Always! Always!” think of the users experience when considering your best practices. Sure 100 VMs on a host sounds good but what kind of performance will users have? I’ve had my share of complaints over slow virtual servers and believe me you don’t want users to start complaining that your (that’s right, your!) virtual servers are slow.
Rule of thumb: Keep it simple, 4 VMs per CPU core. Don’t use more than one vCPU per VM unless the application running on the virtual server requires two or unless the developer demands two and calls your boss. VMs with one vCPU run more efficient and from my experience nobody seems to notice, except for – maybe, over-clockers!
Here’s something I wrote a while back:
“The measurement of a successful virtual infrastructure deployment is not how many VMs can be hosted per host, it’s how many users can be satisfactorily serviced without them knowing they are using virtual technology. Virtualization should be invisible. Once users start noticing foot prints in the snow, it’s over…”
Originally posted 2009-02-12 16:30:14. Republished by Blog Post Promoter
This video shows a demo of VI 3 which is an older version of VI but the video demonstrates most of the features of VI such as: VirtualCenter, HA, DRS, vMotion which are included in VI 3.5.
Originally posted 2008-12-20 08:31:27. Republished by Blog Post Promoter
Finding servers which are the “Best Fit” canadates for virtualization can be tricky. I have put together the following criteria checklist to help determine whether a new server provision or a P2V should use virtualization.
The Best Fit checklist uses my own criteria and weight recommendations but it can be modified with more liberal values. However, remeber the “Best Fit” for virtualizing a server should always consider the user’s experience, too liberal will produce poor performance and complaining users.
The purpose of this checklist is to evaluate new server provisions for server virtualization. The checklist criteria are designed to only allow “Best Fit” usage for virtualization. A weight of 3 or more will waive the server’s provision for virtualization.
Instructions:
Each item has a weight assigned. While going down the checklist place the weight value on the line to the left of the items that apply. Once you are complete, total the weights.
Checklist:
____
1. Is the primary application supported when hosted on a VMware VM? Yes/No (If no add 3 Pt.) Self explanatory.
____
2. If this is a database server will clustering be required? Yes/No (If yes add 3 Pt.) Caveat: If clustering is required, high availability is hindered on the host server.
____
3. Is this server considered a fail-over for a physical server? Yes/No (If yes add 3 Pt.) Caveat: Fail-over servers should be provisioned on an equivalent platform.
____
4. Can recommended system requirements be scaled back (CPU/Memory)? Yes/No (If no then use items 5 and 6 to calculate weight.
____
5. Will memory requirement be greater than 2 GB? Yes/No (If yes add 1 and .5 for each additional 512 MB)
____
6. Will disk requirements grow beyond a 20 GB (C: or Root disk) and 50 GB of combined additional disk space. Yes/No (If yes add 1 and .5 for each additional 50 GB) How much? _____GB
____
7. Will this be a temporary installation/deployment? Yes/No How many months? _____ (If yes can Lab Manager be used?) (0 Pt.)
____
8. Will a database be hosted on the server (SQL/MySQL/Oracle)? Yes/No Other ___________ (If yes add 1 Pt.)
Does your vCenter flicker when browsing clusters? There could be a problem…
Over the last 3 years I’ve seen this happen twice and both times it was not good. Both cases were caused from an HA event that was interrupted, which left multiple VMs registered on more than one host. Fortunately, the VM stays running and the fix does not cause an outage but it is intimidating having to “KILL” VM processes.
HA being HA might have casued it and the KB below gives more causes and the solution.
HA is a good thing to have enabled, but if your NOC is monitoring your VMs and they see an alert that VMs are powering off they will log into the VIC and start powering them back on, no down time right? That’s one of the main causes of this problem and VMware admins need to educate their NOC admins on letting HA do its job power VMs back on.
Now, the devil’s advocate in me says that sounds good but how does a NOC know it’s a VM, or bunch of VMs? And, don’t we tell then to just treat them like any other server? The devil’s advocate has a good question and I will ask for help answering it. Can I get feedback on how to avoid this issue when and event happens that might cause “VM jumpers”?
Here’s a must know process for every VMware Admin on how to fix this problem…
After one of the following, a Virtual Machine appears as being registered on two ESX Servers:
A VMotion fails to complete correctly or times out in VirtualCenter
A DRS issue where virtual machines are VMotioned automatically in quick succession
When a machine is powered on during VMware HA failover.
The Service Console on an ESX host is low on memory starving the vpxa process
In VirtualCenter, you see the virtual machine as appearing on one ESX Server for a few seconds, then it seems to be on the other.
The virtual machine may appear to jump back and forth among different ESX hosts.
To correct this misconfiguration:
Click Inventory in the navigation bar. Expand the inventory as needed and click the appropriate managed host.
Click the Virtual Machines tab.
Note the virtual machine that disappears every few seconds.
Log in as root with SSH to both affected ESX hosts.
Run the vmware-cmd -lcommand to display the names of the virtual machines registered on this host. Run the vm-support -x command to show which virtual machines are currently running on the ESX host.
Compare results from these commands to determine which ESX host has the virtual machine registered, but is not running it. When you have determined this, you need to unregister the virtual machine from the ESX host on which it is registered but not running.
Run the following command to unregister the virtual machine from the ESX host: vmware-cmd -s unregister </vmfs/volumes/datastore/folder/machine>.vmx
If the virtual machine has a process (PID) associated with it, ESX may not allow you to unregister it and the command fails with the error:
If you see this error and are unable to unregister the virtual machine:
Kill the process for the virtual machine in the Service Console with the following two commands:
ps -auwwwxx | grep -i <Virtual Machine Name>
kill -9 <PID of the process returned from the above command>
Unregister the virtual machine from the ESX host again with the command: vmware-cmd -s unregister </vmfs/volumes/datastore/folder/machine>.vmx
Run the following command to stop the hostd process:
service mgmt-vmware stop
Use a text editor to open the /etc/vmware/hostd/vmInventory.xml file.
Locate the machine you want to remove.
Remove all of the information between the <ConfigEntry> tags for the affected virtual machine.
Run the following command to start the hostd process:
service mgmt-vmware start
VMControl error -999: Unknown error: SoapError: ServerFaultCode(0): (The attempted operation cannot be performed in the current state (Powered On).)
Log in to all of your ESX Servers directly using VI Client.
You see the virtual machine on both ESX hosts with a Powered-on status. One host however does not display any details of VMware Tools, IP address, etc in the Summary tab.
Click the virtual machine on the host that does not display any details in the Summary tab.
Right-click the virtual machine, and click Power Off.
Note: VMware recommends restarting the mgmt-vmware and vmware-vpxa processes on any hosts on which you have changed registered machines from the command line. For more information, seeRestarting the Management agents on an ESX Server (1003490).
Originally posted 2009-08-10 18:56:49. Republished by Blog Post Promoter
Good free tools for VMware VI are not easy to come by so I thought I would write a post about one I think may have some usefulness. It’s from VKernel and it’s called SearchMyVM. According to VKernel here are the benefits:
FREE “Google–like” SearchMyVM tool
Quickly find info in your VMware data center
Gain more insight into your environment
Save significant time
The tool, like other VKernel downloads, comes already packaged as a VM that just needs to be imported into your VirtualCenter (vCenter or ESX). Once imported and booted, do a quick configuration and just open your browser to the IP address you have given the tool. Then create a custom query for your search, a good example listed: “Return a list of all VMs that fail to vMotion”.
The tool release is version 3.0 and there is pretty good step-by-step instructions for the installation guide.
If you’d like to try SearchMyVM for yourself here is the link to VKernel <Download>
Do you know of a free tool that you’d like to recommend for VMware, Hyper-V or Xen? Please let us know with a quick post.
Originally posted 2009-03-22 08:05:13. Republished by Blog Post Promoter
This will cover Windows templates but the same steps are used with Linux, except the Sysprep.
After you get your VM the way you want it, patches, secured and have your applications installed, you right click on it in the inventory windows of your virtual center and select “convert to template”.
Converting to a template will allow you to deploy new systems from the template that will have a unique SID. A clone is an identical copy of the original, which means it will have the same SID. So, don’t clone unless you plan to convert the clone to a template.
Also, to properly deploy a template you will need to copy the Microsoft Sysprep tools to the correct directory on your virtual center system – C:\Documents and Settings\All Users\Application Data\Vmware\VMware VirtualCenter\ . This will activate the custom deployment feature. Make sure you download the proper Sysprep file from Microsoft or get them off the Windows Server 2003 SP1 disk in the \Support\Tools\Deploy.cab file.
Once the Sysprep files are in place, when you deploy new system, you can customize the system just like you would if you were running the sysprep tool from the system. Then when you boot the new system it will start up like with what ever name, IP, time zone, etc you gave the system during the deployment.
Other things to consider are VM setting for your new system: CPU, memory, NIC, etc. Don’t over use resources!
Do you have a tip to share? Please post it in the VM install forum.
Originally posted 2008-05-23 17:30:16. Republished by Blog Post Promoter
I’m not sure if anyone else feels the way I do about jumping on the vSphere bandwagon, however, I’ve decided to wait until 4.0 Update 1 is released before I consider the move.
I’ve seen the sales pitches and demos but no evidence is enough to convince me to join the rush to upgrade, especially when I (and the guys I work with) have nearly 1000 VMs online running happy on ESX 3.5U4.
We’ve gone through major pains to establish a single standard for hardware, software and storage which is guaranteed to provide a high level of performance and stability that will meet our business needs and SLA. Actually, I recommend establishing your own standard before upgrading, too. What’s the hurry?
VMware for me is not a fad but a technology that needs to be taken serious, or as history has shown - outages will occur that will take down mission critical VM servers that are running business critical applications. No thanks, I’ll let the fadsters (production beta testers) jump the gun and wait until VMware releases update 1 to fix the new release problems.
What has been your experience with vSphere, good or bad – please share it with us?
Originally posted 2009-08-09 12:47:28. Republished by Blog Post Promoter
Recent Comments