我的主机的物理内存可以分配给我的客户机多less钱？
例：
主机物理内存：10 GB
例如分配2GB的虚拟内存到7台机器总共14GB是否可以接受？ 多less可以overcommit内存确保balooning和其他主机内存释放技术工作正常？
这基本上取决于虚拟机和它们的内存使用情况。 ESXi采用了许多技术，可以为客户机过度使用内存：
一段时间内处于非活动状态的内存页面正在被压缩，并被解压缩并根据请求提供服务，而不是被交换到磁盘或膨胀。 页面压缩具有一个可configuration的上限，默认情况下该值设置为访客分配的内存的10％，根据此VMWare白皮书，在实际场景中使用压缩caching时，可以大致估计性能下降6％。
已经发现携带相同信息的不同客人的虚拟内存页面被引用到相同的物理内存页面。 这是一个asynchronous操作，定期释放重复的内存页面。
VMWare工具提供的guest虚拟机中的内核级驱动程序将在guest虚拟机的非分页内存池中声明内存，并将其标记为pipe理程序的“Free”。 通过这种方式，内存实际上是暂时从客户那里“偷走”的，如果客户真正需要内存，就会引起客户级别的交换。
如果一切都失败并需要更多内存，ESXi会将来宾内存页面交换到磁盘。 交换文件的位置是可configuration的，默认情况下放置在与guest虚拟机configuration文件相同的目录中。
我发现，对于典型的加载页面压缩和页面共享，在ESXi所带来的内存开销比内存节省10％左右的情况下，不会出现明显的性能下降。 只要将它configuration为（您可以通过将整个内存量保留给客户端来有效地closures它），热气球将始终有效，但是基本上它只比交换更好（这是客人在其他情况下会dynamic声明的地方）大量的内存用于caching，但是如果客户已经缺乏内存，那么它就无法实现魔法，并且由于抖动而导致磁盘I / O，就像基于虚拟机pipe理程序的交换所做的那样）。
所有的总结：如果你可以configuration你的客人超过约10％，他们将继续运行没有客户交换和随之而来的性能下降，你可能会罚款40％的过度使用。 如果没有，你肯定不会。
esxtop的内存页面的输出（从SSH控制台启动esxtop之后只需按m键）会比通过vSphere客户端获得的图表更详细地通知您实时内存统计信息，因此可能值得查看那里：
1:54:52pm up 34 days 8:39, 214 worlds; MEM overcommit avg: 0.00, 0.00, 0.00 PMEM /MB: 32766 total: 1031 vmk, 29568 other, 2166 free VMKMEM/MB: 32103 managed: 1926 minfree, 13525 rsvd, 18577 ursvd, high state NUMA /MB: 8123 ( 767), 8157 ( 2425), 8157 ( 186), 7835 ( 128) PSHARE/MB: 2162 shared, 139 common: 2023 saving SWAP /MB: 0 curr, 0 rclmtgt: 0.00 r/s, 0.00 w/s ZIP /MB: 17 zipped, 10 saved MEMCTL/MB: 295 curr, 292 target, 14289 max