Welcome to Snooda's Blog
openvz和kvm同机部署安装（debian）
[
| 
2014/02/23 18:28]
| 2014/02/23 18:28]
最近搞了个机器。想搞成同时支持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官方源里的包。兼容性好。
搜了下方案，果然有个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官方源里的包。兼容性好。
OpenVZ VPS内存查看分析工具/超售检查脚本
[| 2012/04/12 02:52]
| 2012/04/12 02:52]
搞了一个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
用法： 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
