Knowledge Base
Virtual Machines
Overview
6 min
understanding memory management our hypervisor takes a different approach to virtual machine memory management compared to platforms like vmware and nutanix understanding how we handle memory allocation and reporting is essential for effective capacity planning, performance optimization, and troubleshooting this article explains why memory usage reporting differs from guest operating system reports and the advantages of this design choice key concepts memory allocation vs memory usage memory allocation the amount of physical ram reserved by the hypervisor for a virtual machine, regardless of how much the guest os and applications are actively using memory usage the amount of memory actually consumed by applications and the operating system within the virtual machine with korgrid, when you assign 8gb of ram to a vm, the hypervisor immediately reserves 8gb of physical memory on the host, even if the guest os shows only 2gb in use why korgrid shows allocated memory when memory is allocated to a vm, the hypervisor must reserve that full amount in physical ram regardless of what applications inside the vm are actually using it this is because the guest operating system could request access to any portion of its allocated memory at any time, and the hypervisor must guarantee that memory is available korgrid displays this reserved/allocated memory because it represents the actual physical resources consumed on the host, providing a true picture of resource utilization for capacity planning and performance management how korgrid differs from other platforms korgrid approach no memory ballooning korgrid intentionally avoids memory ballooning techniques used by other virtualization platforms key characteristics include allocated vs used korgrid shows what's allocated to each vm, which typically isn't the same as guest level usage performance first this eliminates ballooning overhead and complexity predictable resource allocation what you see is exactly what's reserved on the physical host traditional ballooning approach many virtualization platforms use memory ballooning drivers that dynamically report memory usage to the hypervisor allow memory "overcommitment" by sharing unused memory between vms require special drivers (balloon drivers) within each guest os create complexity in memory management and potential performance impacts benefits of korgrid's memory design 1\ predictable performance by eliminating balloon driver overhead, korgrid provides more predictable vm performance there's no dynamic memory management that could impact application response times or cause unexpected memory pressure 2\ simplified capacity planning with clear allocation visibility, administrators can easily calculate total memory committed across all vms available memory capacity for new workloads resource utilization without complex ballooning calculations 3\ enhanced reliability korgrid avoids dynamic memory management issues that can occur with ballooning, such as memory reclamation delays guest os memory pressure during balloon inflation potential application instability during memory operations 4\ guaranteed migration success critical for high availability korgrid's approach ensures predictable workload migration during node failures since the full allocated memory is always reserved, the system can guarantee that all vms can be migrated to available nodes without memory overcommitment surprises if korgrid used memory ballooning, it could not ensure reliable migration of all workloads to another node during a failure scenario, as the actual memory requirements might exceed the target node's capacity when balloons are deflated