2011年11月17日
#
想创建
VimClient client = new VimClient();
client.Login("https://124.127.116.175/sdk/","Administrator", "ctbri@smb");
System.Collections.Specialized.NameValueCollection filter = new System.Collections.Specialized.NameValueCollection();
filter.Add("Name", "^vpc");
IList<EntityViewBase> vmlist = client.FindEntityViews(typeof(VirtualMachine), null,
filter, null);
foreach (VirtualMachine vm in vmlist)
{
vm.UpdateViewData();
if (vm.Runtime.PowerState == VirtualMachinePowerState.poweredOn)
{
Console.WriteLine(String.Format("{0} is running!", vm.Name));
Console.ReadKey();
}
}
2011年5月27日
#
从当前的市场格局上看，中国移动的OMS确实是不怎么成功：用户不喜欢用，手机厂家也不喜欢安装，好多用户拿到装载了OMS的手机之后，第一件事情往往是重新刷回原版的Android系统。好多人就因此认定，中国移动针对播思通讯投入的几年时间和数亿真金白银打了水漂。
是真的打了水漂吗？未必。
从技术的出发点来说，OMS是很不错的，借助于Google提供的拥有完整、精致、优美而且自带软件库的Android这一操作系统，加上自己的深度定制，力图在操作系统的层面统一用户感知，统一用户入口，进而实现统一用户平台的目标，所有应用运行于中国移动的定制平台中，很美好的前景，也将带来巨大的收益。只是，收益往往和风险伴随，项目管理可以控制风险、，但是不能完全消除风险，而且这种收益往往需要长期坚持不懈的投入。
中国移动确实忽视了一点：自身当前能力，希望在一两年之内，就达到iOS的水平。事实证明，开发一个适用于移动终端的操作系统是一项庞大的工程，在小小百兆左右的空间中，要有传统的操作系统的所有功能不提，通信管理、图形接口、授权管理、应用开发API等等，都是具有高度复杂性的组件，即使站在Google这个巨人的肩膀上，也很难在短短的几年时间之内达到很好的效果，更何况Android 1.0本身是一款半成品，播思通信也是一个才创建几年的公司，技术和开发流程等方面的积累都还不够。
事实上，OMS在Android的基础之上做了很多有意义的工作，如替换更优秀的图形引擎、加入全中文支持、增加中国移动自己的平台调用等等，这些成果除了在OMS中可以使用之外，也可以用于日后的中国移动定制机中，相较更换个Home程序、修改点界面和加几个应用这种刷机爱好者都能做的事情，能够更加深度定制自己的移动平台。
和中国移动相比，有很多公司也尝试走了同样的道路：创新工厂的点心OS、联想乐phone的lephone os，这些操作系统的出现，也说明了中国移动的道路并没有选错。开发一款优秀的平台，需要经验的积累。
中国移动通过自己开发OMS操作系统，首先锻炼出来了一批真正研发过手机OS平台的团队，明白开发这种平台中的关键点，要注意的地方，困难的地方，而不会被厂商瞎忽悠；其次是锻炼出来了一批尝试过对OS平台进行推广的人，他们会更清楚自己的产品哪些地方不好，需要改进。如果有后续投入的机会，应该会做得更好，更有准备。
在我们呼唤创新的同时，也应该呼唤对失败的包容，一次两次失败或者并不能说明什么。OMS的失利是多方面的，有本身的不成熟，有产业链的不支持，甚至还有相对不成熟网络制式的拖累。但是，我们不能否认运营商切入通信领域基础技术研究的战略意义。
2011年5月16日
#
因为KVM的源代码已经包含在了Linux的内核树中，因此我们只需直接从www.kernel.org下载代码即可，内核源码包打开较大，解开后目录结构大概是这个样子：
涉及KVM的主要有两个目录，virt和arch/x86/kvm。virt目录虽然看起来层级很高，主要有kernel中非硬件体系架构相关的部分如IOMMU、中断控制等，真正货色较多的，是后者。因为kvm除了支持x86架构以外，还支持PowerPC、MIPS、ARM等架构。
按照分析Linux Kernel代码的惯例，Makefile和Kconfig是理清楚源代码结构最好的地图，二话不说先打开Kconfig看看，里面主要提供了3个主要的菜单选项：KVM、KVM-INTEL、KVM-AMD，看到这三个就应该很熟悉了，KVM是KVM的开关，而KVM-xxxx则是对应目前两大家CPU厂商的牌子了。
Kconfig看过了，没什么嚼头，还是Makefile有点意思吧：
EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
CFLAGS_x86.o := -I.
CFLAGS_svm.o := -I.
CFLAGS_vmx.o := -I.
kvm-y += $(addprefix http://www.cnblogs.com/../virt/kvm/, kvm_main.o ioapic.o \
coalesced_mmio.o irq_comm.o eventfd.o \
assigned-dev.o)
kvm-$(CONFIG_IOMMU_API) += $(addprefix http://www.cnblogs.com/../virt/kvm/, iommu.o)
kvm-y += x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
i8254.o timer.o
kvm-intel-y += vmx.o
kvm-amd-y += svm.o
obj-$(CONFIG_KVM) += kvm.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
obj-$(CONFIG_KVM_AMD) += kvm-amd.o
在这里看到了kvm的主要“零件”，从kvm的官方文档中可以查阅到，kvm内核模块是由必选的kvm.ko和kvm-intel.ko于kvm-amd.ko两个二选一模块组成的，这个体系结构在Makefile中得到了良好的“证实”。
这里给不明白内核代码预编译的同学讲解一下，内核代码中$(CONFIG_KVM)等部分是预编译条件，如果在linux内核的配置中配置了该选项，则$CONFIG_KVM会通过预编译替换成y，实际上obj-$(CONFIG_KVM) += kvm.o就成为了obj-y+= kvm.o
从这里可以看出，kvm.ko的将要包含IO操作、MMU内存操作、IRQ终端操作、APIC高级电源管理和Timer定时器操作，其实这也是KVM所要干的事儿。单独一个KVM并不能实现虚拟机，要通过QEMU来模拟一台完整计算机系统的大量外设才行。
2011年5月13日
#
虚拟化
虚拟化的的主要目的，是希望将软件从硬件资源中解藕，让这些软件能够被运行于各个单独的系统中而不相互干扰。虚拟化技术的核心组件包括CPU、内存、磁盘空间和网络连接资源。通过虚拟化技术，运行定制化和特定任务的虚拟机能够精确地分配到符合其需求的资源。虽然在前能够同时在在一台物理主机上运行提供Web服务、邮件服务和FTP服务的软件，并且提供相应服务，但是，考虑到信息和资料安全的情况下，这种做法是不提倡的。而且，只要这三个服务软件中有一个软件发生了故障，整个系统都会受到影响。然而，如果将这三个软件都分别部署到单独的系统中，通过虚拟化技术的辅助，实现隔离，因此即使有一个软件系统出了问题，只需要重新配置其对应的虚拟机即可。另外一个好处，是可以精确地位每一台虚拟机分配适合其任务能力的资源，并且根据业务能力的变更，能够对资源通过软件进行直接配置，而不需要更改硬件。
硬件仿真
硬件仿真即是针对整台计算机都进行仿真，因此能够运行宿主机不同指令集的程序，甚至操作系统。在这种实现方式中，是将目标机的目标指令集通过翻译成宿主机的指令集来实现。然而，这种实现方式的代价比较高昂，每一条指令都需要通过翻译系统翻译成对应的代码之后再进行执行，效率很低。
原生虚拟化(Native Virtualization)
原生虚拟化也叫做硬件虚拟化，Guest OS所运行的硬件是通过虚拟机软件来提供虚拟硬件。为了能够让Guest OS和Host OS能够共存，一些来自Guest OS的特权指令将被VMM拦截，并且得到妥善处理。Guest OS对虚拟硬件的访问(显卡、网卡等等)则往往是通过VMM提供一些标准硬件的模拟来实现。基于这种原理的产品，主要有VirtualBox，Vmware Player，Vmware Server，VMware Workstation和Parallels Desktop/Workstation。这种方式和原理运行的Guest OS往往速度都很理想。QEMU 在0.11版本以前时候提供的可选组件KQEMU也是这种形式的。
部分虚拟化/全虚拟化
同硬件仿真和原生虚拟化只是提供同计算机硬件相类似的接口不同，在这种虚拟化技术中，Guest OS一些访问物理硬件的读写指令需要进行转化、翻译后才能执行。虚拟机管理器(Virtual Machine Monitor)将会为各个虚拟机调度资源。这样的虚拟化方式的缺点是，Guest OS需要进行一定的修改以匹配Hypervisor，或者说当服务器的CPU必须支持硬件辅助虚拟化技术时，可以不用修改Guest OS。
部分虚拟化和全虚拟化对以上两个技术来说，最大的优势就是跑得更快，另外一个显著优势则是可以实现动态迁移，在VM迁移到不同物理机的过程中，VM是能够不间断提供服务的。
主要有两种类型的Hypervisor:
第一种直接运行在服务器硬件上，提供资源供虚拟环境使用。典型的产品有开源的Xen和VMware ESX。
第二种时在操作系统内部加入Hypervisor的模块。典型的产品是KVM(Kernel-based Virtual Machine)。KVM只能在提供硬件辅助虚拟化的服务器中运行。
操作系统级别虚拟化
操作系统级别的虚拟化则不同，从服务器中分隔出来的Guest OS和Host OS都共享同一个操作系统内核，在提供在用户态将用户的执行环境分隔开。典型的应用有OpenVZ、Linux-VServer。QEMU不支持这种类型的仿真。
QEMU
QEMU是一个开源的模拟器项目，能够模拟整个系统的硬件，而且兵不像VMWare哪样仅仅针对x86体系架构。QEM运行于多种操作系统中(Linux、BSD、Mac OS X、Windows、eComStation、Dos)和不同的CPU体系架构中。
QEMU允许在虚拟机运行时保存虚拟机的状态，进行实时迁移，进行操作系统级别的调试，从旧格式的磁盘中启动等等。QEMU也能模拟硬件失效的案例。
QEMU的安装包中提供了qemu-img这个强大的工具来创建、转换或者加密虚拟机映像，也支持从其他如阿健的虚拟机格式中启动(如微软的VHD格式)。另外一个工具是qemu-nbd，能够将QEMU的映像文件通过NDB(Network Block Device)协议共享给其他机器。
在Linux、BSD和Mac OS X系统中，QEMU支持用户态模拟，即允许某一个应用程序的API调用其他版本的动态链接库。
KVM
KVM是Linux开源社区大力支持的虚拟化技术，基于Intel和AMD的硬件虚拟化技术，但是对于部分虚拟化技术则不予支持。KVM也有一个支持部分虚拟化的版本，该版本并没有被主干版本所接受。使用部分虚拟化的优势在于，能够有更低的负载和更好的性能，但是需要修改相关操作系统以及驱动程序。
KVM支持页表虚拟化和IOMMU虚拟化技术。页表虚拟化技术用于将Guest OS的页表转换到Host OS运行环境中。在这种机制下，KVM的Host OS将要接管所有的内存分配(其实也是使用Linux内核的内存管理能力)
KSM在2.6.32版本的Linux内核中被引入。通过KSM技术，能够辨别在内存中相同的区域，并且标记出来作为共享区域，这样就能够为虚拟机提供超过实际物理机装机容量(overcommit)。KVM技术还支持Nest虚拟化，即在KVM虚拟出来的虚拟机中，还能通过KVM来创建虚拟机。
KVM的模块分为公共模块kvm.ko，和硬件相关的模块kvm-intel.ko和kvm-amd.ko。KVM提供一个字符型设备文件接口/dev/kvm。当linux的内核加载kvm模块之后，整个linux kernel就成为了一个Hypervisor。但是要注意，当KVM运行时，是排他性的，如SUN xVM、VirtualBox、VMWare Server等解决方案均无法共存。
xen的解决方案中需要两个系统来共同协调以完成工作：hypervisor和特制的Guest OS，即基于Linux的domain 0，因此KVM比xen更容易安装和实施，同时一个系统的安全性也比两个系统要高。KVM并不是一个完全的模拟器，而是借鉴了QEMU来完成相关外设模拟。很多发行版中，QEMU和KVM都被打包到了一个package中(但是这个版本的QEMU将不再支持其他多个不同的体系架构).
自从Linux内核的2.6.20版本开始，KVM被引入到内核中，其最先开发的公司Qumarnet也已经被Redhat收购。
libvirt
虽然，当前有很多免费的虚拟化解决方案，但是其配套的管理工具却非常昂贵。而且，一个数据中心中往往运行有多种不同的虚拟化解决方案，这些不同的虚拟化技术又都需要不同的虚拟化管理工具，着这种情况下，libvirt就应运而生了。libvirt是一个基于虚拟机层和管理工具层之上的中间件，并且提供了virsh虚拟机管理方案来进行统一管理。目前，libvirt已经支持了QEMU、KVM、Xen、VirtualBox、VMware ESX、LXC Linux Container System、OpenVZ Linux Container system。
libvirt是一个开源的库，除了在linux环境下能编译以外，还能在cygwin和MinGW环境下编译。
最近一阵子的工作都是集中与kvm、xen等虚拟化技术，主要是为电信提供云计算的一些IaaS解决方案，查阅了一下Internet的资料之后，发现kvm和qemu等虚拟化相关的中文资料甚少，英文资料也不多，所以萌发了编写一系列有关kvm、qemu等开源项目的相关介绍，包括使用方法、源码解析、结构介绍等等，希望能同大家相互交流，共同提高。
本系列开篇部分打算参考Robert Warnke和homas Ritzau这两位大牛所编写的《qemu-kvm & libvirt》一书，可惜原书是德文所写，本人也不懂德文，只好通过Google翻译到英文后凑合理解消化，因此准确的翻译就说不上了，主要主要希望在本系列中提供一些精要的部分，供大家参考参考。
原书链接在此：http://qemu-buch.de/english/order.php
在后期，就打算讲解讲解关于qemu的代码分析、结合kvm的内核代码实现原理，虚拟化操作，基于libkvm和libvirt管理工具等等比较“硬”的东西，水平所限，希望大家多多提出意见
2008年9月22日
#
查阅了一下网络和博客园，发现还没有一个明确地指导源码管理提交准则的相关文章，因此斗胆整理了一部分自己平时开发管理的心得，加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。
负责而谨慎地提交自己的代码
SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。
如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。
保持原子性的提交
每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。
不要提交自动生成的文件
Visual Studio在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用Delete命令从仓库中删除。
不要提交不能通过编译的代码
代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
不要提交自己不明白的代码
代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
提前宣布自己的工作计划
在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。
对提交的信息采用明晰的标注
+) 表示增加了功能
*) 表示对某些功能进行了更改
-) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。
b) 表示修正了具体的某个bug
2008年6月3日
#
摘要: 基础编程方面：首先是要看数据结构和操作系统的书，可以找高教出版社的，另外自己去找一些课件来看，网上有很多下载的。http://xidong.net/List000/Catalog_67_T1.html有很多课件可以下载。操作系统主要看的是数据结构在操作系统内存管理，进程管理等方面的应用，对提高编程很有好处。《代码大全》，非常好的一本书，每个阶段看都会有收获《深入解析计算机系统》 给软件人员编写的，但是讲解了很多硬件底层的东西，对理解整个程序的运行非常有好处。《C++ Primer》讲解C++的STL非常透彻，主要是领悟STL对软件开发的思想，容器和算法分离方面，感谢gillspent兄弟的推荐
阅读全文
2007年2月6日
#
摘要: 到了.Net 2.0的开发时段的时候，越来越多的类库、开发方案倾向于使用配置文件的办法进行构架的设计，完成软件的内容。于是乎，我们的软件里头也就有了越来越多的配置文件，数据库的Nhiberate，Castle的一大堆Service，以及Enterprise Library的那么多配置文件，而且也越来越有这样的趋势：多多使用配置文件，少写代码。于是，让我想起了*nix下头的情况：etc下头全部都是配置文件吧，每个程序的设置都是通过配置文件来进行，Configure File也越来越专业，普通用户也就越来越看不懂了，只有根据专业开发人员的建议才能进行修改。看过了《设计模式》之后，我越来越提醒自己，
阅读全文