Welcome to Snooda's Blog
    最近搞了个机器。想搞成同时支持openvz和kvm虚拟化技术的host。从原理上讲认为问题不大,因为两者分别是不同层面的虚拟化技术,一个是硬件级别虚拟化,一个是cgroup水平的进程级虚拟化(对这块了解不深,说错勿怪)。所以还是可能同时安装的。

    搜了下方案,果然有个proxmox的发行版是解决这个需求的。看了下文档,集成了一堆面板啥的,东西越多bug就越多。还是自己diy一个。

    由于openvz是需要打过patch的内核运行,而kvm则需要kvm和kvm_intel内核模块的加载(amd的就是kvm_amd)。所以难点就是这个的兼容。其他用户态的进程如果有冲突啥的都好解决。

    首先选用debian7(我喜欢debian),发现需要用openvz的源,源里使用的openvz内核是2.6.32。而debian7的内核目前是3.2。风险比较大。从源里拖了openvz内核deb包下来看,发现居然32位的内核不带kvm模块,而64位的才有。哭了。不知道他们咋搞的。于是64位系统搞起。结果发现kvm_intel加载不进去。报input/output err。用-f强制加载后报签名被拒绝。估计编译的时候哪里错了,虽然有内核源码和.config,不过还是不自己编译了,太折腾。

    还是用debian6。debian6的官方源里已经包含openvz了。内核版本也是2.6,32系列。跟debian6默认内核版本相同。这个感觉靠谱。装上重启进入openvz内核。modprobe加载kvm内核模块。ok,成功了。



     下一步就是进程和网络上的调整了。都不是大问题。



     结论是:openvz目前还是建议用debian6官方源里的包。兼容性好。
Tags: , ,
    搞了一个python脚本,用来查看OpenVZ VPS内存情况的,原始数据取自/proc/user_beancounters文件,脚本内做了一个数据简单的分析提取和可视化提高的工作,已经很晚了,先搞几个基本功能出来,增强功能以后再补。

    用法: python vz_checker.py /proc/user_beancounters (需要root权限)
    输出内容:

filename is:[user_beancounters]
Kernel Mem Info:                                   used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info:                        used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used:                                 used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used:                             used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]



Kernel Mem Info:占用的内核内存大小,不可被swap,主要用来存放进程数据等。
Mem already allocated Info:已分配的内存大小,limit即为burst内存大小。
Ram actually used: 实际占用的物理内存大小。
Mem (Ram + swap) used:  占用的物理内存和swap大小。


如果  实际占用的物理内存 == 占用的物理内存和swap大小  那么恭喜你,你的vps里运行的程序都在内存中,主机超售不严重。
如果  实际占用的物理内存 <   占用的物理内存和swap大小   情况不妙,主机已经开始占用swap了,超售比较严重了。


另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大,现象很奇怪,查了一些资料没有关于这方面的说明,待后续调查。


脚本功能还比较粗糙,一些数据需要继续打磨,欢迎大家提意见~~
本文地址:http://www.snooda.com/read/263
下载地址:https://github.com/snooda/openvz_checker










Tags: , ,
分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]