最近想借用kvm虚拟化中的balloon机制来实现linux云主机的在线资源伸缩，由于cloudstack也采用balloon技术来在线调整云主机的资源，因此在可行性上应该没有问题，不过在实际测试中碰到了奇怪的现象，与大家分享。

（1）环境

宿主机：ubuntu 12.04  32G内存

guest： centos6.4 512M内存

（2）具体内容

libvirt配置片段

<memory unit='KiB'>32934912</memory>   #云主机最大可使用的内存（32G）

<currentMemory unit='KiB'>524288</currentMemory> ＃实际使用的内存（512M）

根据以上配置，云主机boot时的可用的内存为32G，一旦机器被boot起来之后，balloon模块被加载，云主机便会调整它的可用内存到512M。（这里需要注意的是，kvm的内存分配使用了类似thin provision的技术，也即使用多少分配多少的原则。本例，云主机的可用内存虽然为32G，但云主机在启动阶段基本不怎么使用内存，所有在宿主机里看，guest占用的内存远远到不了32G）。

采用这样的设置之后，就可以调用libvirt的setmem功能在线调整云主机的内存大小，最大可到32G，即占满整个物理主机。一切似乎顺理成章，不过意外的现象发生了。

“云主机在启动的过程中报错，kernel panic  OOM”

这里就纳闷了，512M内存启动一个centos guest完全没有问题，为了确认该问题，将libvirt的配置改为：

<memory unit='KiB'>524288</memory> 

<currentMemory unit='KiB'>524288</currentMemory>

云主机正常启动。到这里，我们就可以得出结论了，云主机实际的可用内存不是简单的由currentMemory控制的，与memory也有关系，为此做了如下测试：

（a） memory = 3000M, currentMemory=512M情况下，云主机可用内存 320M

（b）memory = 4000M,currentMemory=512M情况下， 云主机可用内存为248M

也就是说，随着memory tag中数值的增加，云主机的可用内存其实是减少的！

了解原因之后，解决方法就很多了，这里就不提了。

（3）附一些相关的网页

http://blog.braastad.org/?p=211