Professional Documents
Culture Documents
Motivation
Define host and guest memory usage and ask some questions
Memory management concepts
Answer our questions
Best practices
Summary
Q&A
Motivation
Host and Guest Memory Usage
Using Host and Guest Memory Usage
VM
“virtual” memory “virtual”
Application App
guest
memory
guest
hypervisor
Hypervisor “machine”
“machine” memory Hypervisor
memory
Application Memory Management
Hyper
visor
Operating System Memory Management
OS
Idea
– Hypervisor could identify memory used by guest for it’s free list
– Watch that memory area for changes and free physical memory that
backs guest memory added to free list
Problem
– Free list may be hard to identify
• Depends on guest type and may change from release to release
– “Free” is not always free
• “Free memory” may be used in buffer cache or elsewhere by guest
– Guest may not free memory when hypervisor wants it to
What can the hypervisor do to reclaim
VM memory?
Nothing
– Route taken by pretty much everyone except VMware
– No memory overcommitment! (Inefficient use of memory)
– May try to convince you memory overcommitment isn’t important
Something
– VMware-innovated techniques
– Supports memory overcommitment
• Efficient use of memory
• Strict resource control guarantees
Memory Overcommitment
VM 1 VM 2 VM 3
Hyper
visor
2. OS doesn’t OS
Because the memory
allocated to an app List of
memory
3. Nothing in the VM relies Hyper
on the memory’s value for visor
correctness
Hypervisor can safely reclaim ballooned memory because the
VM does not rely on a particular value for that memory.
Inflating Balloon Cont’d
Guest OS swapping, a possible side effect of ballooning
Two possibilities for guest free memory:
Guest Guest Guest Balloon
free list free list App Driver
2. Needs to
swap!
OS
1. No swapping
necessary!
Hyper
visor
Memory overcommitment
– Aggregate guest memory is greater than host memory
Not memory overcommitted
– Never reclaim memory from guest through ballooning or swapping
• No need to!
• (Transparent page sharing is always running)
Memory overcommitted
– Only reclaim once free physical memory drops below threshold
• Start ballooning when memory starts to fall toward threshold
• Start swapping as memory nears/passes threshold
VM’s memory size should be slightly larger than the average guest
memory usage
– Accommodates workload spikes without guest swapping
– Hypervisor will handle excess host memory usage
– Larger VM memory size means more overhead memory
Summary
Summary
Ballooning
– Provide adequate swap space in guest OS
• Ballooning can lead to high guest memory swapping
• Ballooning not effective if a guest can’t swap
– Limit maximum balloon size if lots of guest memory pinned
• Pinned memory cannot be swapped
• Use sched.mem.memctl.max to set maximum balloon size
Swapping
– Ensure adequate swap space on VMFS datastore
• Swap size = VM memory size – VM memory reservation