The server has 16 gig of memory. We want to run as many VMs as possible on this server. They are used as automated testing "slaves" to a Jenkins VM which distributes testing jobs.
The VMs right now total 10.6 Gig of memory used in vSphere.
But vSphere reports 12.1 Gig of 16 Gig is used. This implies that vSphere itself is using 1.5 Gig.
So there is only 4 Gig remaining on the server.
Note that vCenter reports that each vm below is using less that it's full memory.
- vCenter Server Appliance takes 4 Gig. 10% used.
- Jenkins Appliance takes 500 Meg. 14% used.
- Windows 7 x64 takes 2 gig. 15% used.
- Windows 7 x64 takes 2 gig. 15% used.
- Windows 7 x64 takes 2 gig. 9% used.
Questions: 1. Does 4 Gig remaining mean that we can only run 2 more of these 2 gig Windows vms?
Does the % used allow us to "over commit"? The machines rarely use more memory unless a memory leak in the software under test occurs.
What happens if we "over commit" and a machine does need more memory?
If we cannot over commit, does it make sense to power off the vCenter Server? It seems that since we only have one vSphere server, vCenter is overkill. We only really need it for "cloning" since vSphere client doesn't support cloning. So maybe power off most of the time is better.
Any other ideas or suggestions to allow running many more VMs?
1: Yes, you can over commit. See 2,3 for details
2: If the physical memory gets full, the ESX(i) starts its
Memory Ballooning,Transparent Page SharingandMemory Compressionfeatures. When the memory gets full while these features are used the Host will swap.Memory Ballooning
When an administrator installs VMware Tools, the memctl driver (a.k.a. ballooning driver) is installed in the guest OS. This driver creates a bubble or “balloon” of memory consumed inside the guest so the OS sees it as being used by an application. The hypervisor then takes the physical RAM freed up by inflating this balloon and allocates it to other VMs that require it. Memory ballooning introduces a small amount of processing overhead, and if it forces a guest OS to begin paging to disk, this can significantly slow down the application(s) on the VM. If the VM isn’t using the memory, then ballooning itself isn’t a serious performance issue, but it is an indication that physical memory on the host is becoming scarce. One of the biggest advantages of memory ballooning over other methods for handling memory over-commitment is that the memory ballooning driver allows the guest operating system to choose which pages are relinquished to the hypervisor for other VMs. This way, pages which aren’t in active use can be safely freed up, causing almost no performance impact from the guest’s perspective.
Transparent Page Sharing
Transparent page sharing is the “de-duplication” of memory that permits identical virtual memory pages to be collapsed into a single page within the host’s physical RAM, thereby freeing up memory for other uses. For example, if multiple virtual machines on a host are all running the same operating system and application, the hypervisor will compare pages of memory through hashing to locate identical pages that can be freed up through their consolidation. Ballooning and transparent page sharing work together to ensure that over-committed memory doesn't cause performance issues for the applications in the guest virtual machines.
Memory compression
Memory compression and disk swapping by the hypervisor are the last-ditch efforts by ESX/ESXi to keep the hypervisor from crashing when memory resources on the host are stretched to the breaking point. The compression of memory pages by the hypervisor also causes additional processing overhead; however, this overhead is small in comparison to the slow-down caused by swapping pages out to a storage device. Users of vSphere 4.1 and above will be able to take advantage of this feature to reduce the amount of swapping taking place when physical memory resources are close to being exhausted.
Stolen from VM Memory (vRAM) Sizing Considerations
3: If you power off, you cannot use it anymore, so no statistics are recorded, etc. I do not know what happens to HA and stuff. I would not switch it off. If the VM is idling, ESX will know and handle it. Please notice, the memory features listed are used when needed (see description), so the memory will increase less the more memory used. Try to dramatically waste the memory to see how your vCenter VM scales down. I dont think it will waste too much memory on idle
4: See the linked White Paper for information how to get the answer