Huge Page，巨页是一个很热门的话题，很多大型服务器软件都逐步开始支持使用巨页以减轻内存的开销。在Fedora 12之际，KVM也引入了Huge Page，以增强KVM的性能。

援引自KVM Huage Page Backed Memory的简介，x86 CPU通常使用用4KB页面放置内存，但实际上它们有能力使用巨页完成这个任务（x86_32可以使用4MB页面，x86_64和x86_32 PAE可以使用2MB的页面）。通过把巨页应用在KVM Guest的内存上，页表会使用更少的内存和TLB损耗也会被减少，从而提升了KVM的性能。在KVM Guest的内存上使用巨页确实会有缺点，然而你不再需要交换和Balloon Guest的内存。

应用Huge Page十分简单，首先挂在hugetlbfs文件系统：

mount -t hugetlbfs hugetlbfs /dev/hugepages

通过sysctl保留内存给巨页使用，需要搞清楚的这里设定的数字并不是真正的内存容量，而是巨页数量。对应的关系是1 hugepage=2MB RAM，比如：

sysctl vm.nr_hugepages=768

此时系统会划分1536MB内存给巨页使用。然后启动qemu-kvm的时候添加-mem-path/dev/hugepages参数。比如：

qemu-kvm -m 1024 -drive file=test.img -mem-path /dev/hugepages

使用libvirt和virt-manager管理的KVM虚拟机同样可以巨页，把以下内容加入到/etc/libvirt/qemu虚拟机对应的xml配置文件即可：

<memoryBacking>
<hugepages/>
</memoryBacking>

本人简单地测试了使用巨页和不使用巨页的性能差别，在Windows XP Guest跑了Super Pi和wPrime，性能上没有任何区别。但是测试内存的性能时每一次的数据都会跟上一次出入很大。所以没有再测试下去。

如果是打算把电脑作为KVM虚拟化服务器使用的话，甚至可以把hugetlbfs放在/etc/fstab挂载表上，让电脑启动的时候就直接挂载。而sysctl参数也可以直接添加到/etc/sysctl.conf上。

cat “sysctl vm.nr_hugepages=768″ >>/etc/sysctl.conf

当不再需要巨页的时候，卸载了hugetlbfs和把保留给巨页使用的内存量设置为0即可。

sysctl vm.nr_hugepages=0
umount hugetlbfs

在介绍KVM-ON-KVM前，本人得先说清楚nested paging和nested virtualization 的区别。因为本人在Google搜索KVM的nested virtualization发现很多是关于nested paging，但是实际上两者完全是两码事。还有很多老外都搞不清楚nested virtualization和nested paging，常常以为前者就是后者。

Nested Virtualization：实际就是在一个正在运行的虚拟机内安装多一个虚拟机，并且使之运行，有时也称之为 Nested VMs。

Nested Paging： 其作用就是为了把Guest的内存地址直接映射至Host的系统内存地址上，让CPU能够像读取实体系统的内存地址一样可以直接读取虚拟系统的内存地址。这种方案可以减轻了VMM因为内存地址转换的负担，提升内存读写性能。 从原理上说Nested Paging和Nested Virtualization是毫不相干的，所以本篇文章不会探讨前者。

Nested Virtualization并非KVM一家独有的技术，VMware的虚拟化软件同样支持Nested Virtualization，但是其技术无法无限地Nested下去。其第一层虚拟机必须使用VT-x/AMD-V硬件辅助虚拟化技术，而第二层虚拟机则必须使用传统的二进制软件转换的虚拟化技术。因此无法再运行第三层甚至更多层虚拟机。 相反KVM必须使用硬件辅助虚拟化技术，理论上可以无限地Nested下去，只要机器有足够的速度。KVM的Nested Virtualization暂时只能应用于AMD的处理器上，只要支持AMD-V虚拟化技术，就可以运行Nested Virtualization，包括老旧的K8架构，这与Nested Paging必须运行在K10架构上不同。从qemu-kvm的帮助选项上看出此特性紧限于AMD处理器。至于Intel的处理器什么时候支持Nested Virtualization，KVM说正在做，但是做了很久都还没有突破性消息。

-enable-nesting   enable support for running a VM inside the VM (AMD only)

硬件平台如旧：

CPU：AMD Athlon 64 X2 4200+ RAM：4GB DDR2-800 Host OS：Fedora 13 (2.6.33.6-147.fc13.x86_64) Guest OS 1：Fedora 13 (2.6.33.3-85.fc13.x86_64)1st Layer KVM Guest OS 2：Fedora 13 (2.6.33.3-85.fc13.x86_64) 2st Layer KVM QEMU-KVM：0.12.3

安装好Host系统以后，就可以安装KVM，Fedora下可以尝试安装整个虚拟化组：

yum groupinstall Virtualization

实际上虚拟化组里面的软件包用不上的，比如virt-manager和libvirt。virt-manager里面没有Nested VMs的选项，所以实际上只能通过命令行工具操作KVM。其他发行版可以尝试qemu-kvm、qemu-img等几个常见的命令即可。 然后加载AMD的KVM模块：

modprobe kvm-amd nested=1

注意，因为需要运行Nested Virtualization，所以后面需要添加nested=1参数。查看是否启动了Nested Virtualization：

dmesg | grep kvm

若是支持Nested Virtualization，终端回返回如下信息：

kvm: Nested Virtualization enabled

创建磁盘镜像并且启动KVM：

qemu-img create -f qcow2 kvm-test.img qemu-kvm -m 2048 -drive file=kvm-test.img,cache=writeback -enable-nesting -enable-kvm -cdrom Fedora-13-x86_64-Live.iso

为了启动Nested Virtualization，qemu-kvm后面需要添加-enable-nesting参数。至于其他参数，则跟平常的KVM一样。为了测试方便，此次测试并没有为KVM搭建桥接网络，而是使用了默认的NAT。KVM启动后，就需要为虚拟机安装操作系统。紧接就是安装KVM和加载KVM模块，方法与步骤和前文一样，这里就不再详述了。 在确保所有组件都已经安装妥当并且确保KVM模块已经加载的情况下启动KVM，并且加载第一层KVM内的光盘： qemu-kvm -m 512-cdrom /dev/cdrom 纯粹是试验，本人只在第二层虚拟机启动了Live CD，以验证第二层KVM能够运行Linux即可。因为是光盘，所以启动的速度相当慢，I/O性能已经被压榨尽了，但最后还是能够启动并且能够登入GDM，效果图如下：

实际上，第一层KVM虚拟机内的同样也能够加载kvm-amd模块，才能够再运行多一个KVM实例：

第一层虚拟机内的虚拟CPU，能够支持AMD的svm指令：

当然家用机并不适合跑Nested Virtualization，姑且不论CPU和内存的压力如何大，就以磁盘的读写性能也得够呛了。CPU再快，内存的容量再大。硬盘的读写速度上不去，第二层虚拟机甚至在第一层虚拟机就已经明显感觉到卡机的迹象。如果有专门的存储设备，虚拟机的速度将会有不错的提升。

Nested Virtualization虽然在家用机上用处近乎没有，但是在数据中心内，则可以更加优化系统资源，细化各种计算资源的用途和调配，目的就是要运算能力使用得更加恰当，令服务器能够承担更多用途和任务。

KVM理论上能够支持无限次数Nested Virtualization，但需要的是每一层Guest都要运行支持KVM的Linux系统，如果运行的Windows或者其他不支持KVM的系统，那么则只能安装其他虚拟化软件运行多一层虚拟机，无法再向下扩展。

最后，还是要感谢Fai Wong（lazyfai）的热情帮助。

Firefox 4最大的卖点是重新设计界面和引入JaegerMonkey引擎，在界面上，更多地跟上Chrome和Opera引领的潮流，甚至乎是完全拷贝自Opera，区别就在于FireFox的界面和各个系统上的界面有更好的整合度，窗口的标题栏完全融入成Firefox的一部分。延续了数年参考自IE6的Firefox界面终于要退休了。新的界面带来新的开始，Firefox要为自己的市场份额而重新启航。

Firefox 4.0 Beta 1的发布遴选版本已经泄漏出来了，从这个版本可以看出，Linux版本的默认界面基本没有大改变，默认倒是启用了Tabs On Top这个设计。现在还不可以把菜单栏隐藏到一个按钮上。此外导航栏的图标还没有更新，俨然就是一个rebrand自Firefox 3.7的一个版本。

对比一下原计划的设计图，还是有一段很大的距离。不过现在时间尚早，还有很多时间更改设计。

第一幅是Clearlook的：

第二张设计图是Ambiance，应该是给Ubuntu的吧

至于Windows版本，界面完成度要高出不少。虽然默认还是会保留着菜单栏，但是已经允许隐藏菜单栏了，出现了Firefox按钮。但是标题栏和Firefox按钮好像配搭有点问题。

计划的Windows XP的设计图：

Windows 7似乎和Firefox有更好的界面整合度，看上去界面完成了一大半了。

要是附上Aero特效就更加完美，Firefox按钮还是老问题。来一张设计图：

Mozilla对Firefox的界面下了很大的功夫，现在看起来这些功夫还是没有白费的。但是不得不说Firefox还有很多细节没有完成。比如说标题栏和Firefox按钮的整合，在小窗口页面就会出现下图这种很诡异的囧况。除了Windows平台以外，Linux的界面却比Windows慢了一个拍子，据说Mac平台的情况和Linux的差不多，紧紧多了个Tabs On Top。这方面就Firefox要抓紧时间了。

App Tabs可以说是Firefox 4的一大功能。这个特性有点类似Chrome的App Mode，但是又有一些不同。有点感觉是让用户自己把菜单栏和导航栏移走的感觉。当然Mozilla不会这么无聊的，那是担当云计算大任的特性，据说还可以把Firefox演变为本地的文件管理器呢。到最后这个App Tabs会是什么样子，我们拭目以待吧。

以下是一段Mozilla工程师的访谈，介绍Firefox的界面设计，WebM格式VP8编码的720P视频，只能支持在Firefox的nightly-build版本，Chrome的dev分支版本和Opera 10.60之后的版本观看。

Firefox 4另外一个最重要的特性就是引入JaegerMoneky引擎改善JavaScript性能，现在这是最热门的性能体现。Firefox的确比Chrome和Opera慢了一截，不过我个人觉得现有大部分的网络应用还不至于需要这么高的JavaScript性能，Firefox只要不落后太多就体验就不会差太多了。当然还是越快越好。

此前，黑日白月兄提及到现有的JavaScript性能测试对Firefox不太公平。因为Firefox的JavaScript引擎是支持乱序执行的，而大多数的测试是顺序执行的程序，其他浏览器也是专门为顺序执行而优化，所以Firefox跑这些测试的性能偏慢的原因，而其他测试反而差距不大。Mozilla Wiki的JaegerMonkey条目似乎也给出了他们的诚意，设计目标还真是不一般的高。

这里有一个国外的测试结果，在Ubuntu 10.04 LTS i386平台上测试的，Firefox 4.0 Beta 1的性能比Firefox 3.6.6快约30%，但是和Chrome、Opera仍然有差距。看到它的测试结果似乎都比较慢，应该是用上网本测试的了。

新引擎新界面的Firefox真是令人期待。不知道Fedora 14会不会引入呢？或者Firefox应该像Fedora 14一样加入一个新特性：准时发布。

我测试的大文件读取和复制的性能，测试的办法很简单，就是把Fedora 13的i686和x86_64两个镜像文件从/home复制到/usr目录里面，然后对比总耗时。每个镜像文件大约是650MB，总共1.3GB。

实体机配置：
处理器：AMD Athlon 64 X2 4200+ @2.2GHz
内存：4GB DDR2-800
主板：JETWAY HA01-GT3 MCP55SLI
硬盘：Seagate 7200.12 1TB
操作系统：Fedora 12 (2.6.32.12-115.fc12.x86_64)
文件系统：2GB SWAP分区，其余皆为EXT4分区

虚拟机配置
虚拟处理器个数：2
虚拟内存：1024MB
虚拟磁盘大小：20GB
VirtualBox：3.2.0
qemu-kvm：0.12.3
分区结构：1GB SWAP，剩余空间为单一根分区，使用EXT4
虚拟机操作系统：Fedora 13 (2.6.33.3-85.fc13.x86_64)

测试结果：

首先奉上的是qemu-kvm-0.12.3使用raw格式文件的结果，使用了virtio-blk、SCSI和IDE接口：

紧接就是qemu-kvm-0.12.3使用qcow2格式文件的结果，同样使用以上三种接口，性能比raw格式差距不大：

随后是VirtualBox-3.2.0使用vdi格式文件的结果，并且启用了实体机I/O缓存，接口是SATA、SCSI、SAS和IDE，表现十分优异：

qemu-kvm-0.12.3加上vdi格式文件也测试了一次，接口是virtio-blk、SCSI和IDE接口，成绩不甚理想：

最后就是实体机测试和VirtualBox-3.2.0关闭实体机I/O缓存的SATA接口对比测试：

总结：

看上去qemu-kvm的性能完全失望，比VirtualBox要慢很多，但是这仅仅是大文件复制，并不能代表整体性能。况且这一次测试的重点是要验证virtio-blk能否带来性能提升和能够提升多少。对比起IDE，Virtio大约有25%的提升，提升幅度已经很大了。即使是最快的virtio，和VirtiualBox的差距依然很大，即使和最慢的IDE接口相比也有近10%的差距。十分奇怪的是qemu-kvm的SCSI接口性能十分差，和IDE接口相比竟然慢了一部还多。我向lazyfai请教究竟出了什么问题，他说设置是没有问题的，看来是qemu-kvm自己的原因了。VirtualBox的各个接口差距十分少，只是IDE的差距大了一点，性能最好的是SATA。没有想到的是关闭了实体机I/O缓存的SATA接口，性能竟然比开启缓存的还要好，只是和实体机的磁盘性能相比，依然落后了接近50%。

Technologov也进行了一次小文件测试，测试办法是编译Linux内核，结果表明VirtualBox在小文件测试还是要远远落后于qemu-kvm。看来qemu-kvm的优势在于小文件。出人意表的是virtio竟然大幅度落后于IDE。这可能是测试者忘记清空缓存导致的，导致IDE接口I/O读写量大幅度减少，从而耗时减少。这也证明了I/O缓存对于小文件读写的重要性，倒是在大文件读写中威力有限。结果正如资深玩家们所料，virtio性能出色的地方在于其小文件的读写能力，而且能够进一步降低资源占用。VirtualBox的测试结果也解释了为什么从共享文件夹中读取复制文件的速度会是这么慢，因为文件较多的情况下会导致性能大幅下跌。

其实测试也无法能够证明virtio-blk能够在VirtualBox中带来多少提升，最多也只是能够证明它在qemu-kvm里面很出色。它的同胞兄弟virtio-net已经在VirtualBox崭露头角。virtio-blk能否加入VirtualBox的大家庭，现在则取决于开发者们的取舍了。

要说起这个VirtualBox 2D视频加速用的是什么原理，和Mike在推特上讨论了好一阵子它的原理,。我一直以为VirtualBox可以调用实体显卡进行硬件解码，从而可以减轻虚拟CPU的运算负担。其实不然，VirtualBox只是把视频播放中的画面渲染这个步骤，通过特殊的通道把GLX指令转发到实体机系统上进行渲染。这种办法的好处在于不再需要担心虚拟机羸弱的虚拟显卡性能，即使性能不足，也可以流畅地在虚拟机内播放视频。然而视频音频的解码依然需要由虚拟CPU完成。如果虚拟CPU性能不足，在播放高清影片的时候依然会导致掉帧卡机的情况。实际上这也没有办法之中的好办法，起码不会因为虚拟显卡的性能不足而导致画面渲染不连续。

先来测试效果，还是用着学校的老电脑：AMD 4200+，4GB RAM，8600GT显卡，1TB硬盘。实体机的操作系统是Fedora 12 x86_64。而虚拟机配置是双核心虚拟CPU，1GB RAM，128MB显卡。虚拟机系统为Windows XP。播放器是splayer，测试片源为北京奥运开幕式NBC的720P H.264版本。VirtualBox是3.1.6。

在虚拟机内，有着双核的带动，软解压720P的影片似乎不甚吃力，CPU使用率一般都在40%附近。进行其他操作很容易让CPU使用率突然飙升，这在虚拟机倒是十分平常的事情。即使全屏播放，也十分流畅。最大最小化和全屏之间的切换也十分平滑，没有拖泥带水。

不过当时因为时间仓促没有测试关闭2D视频加速的效果，回到家里的Debian Unstable，却是打开不了这个选项。回去再看看Fedora 13，则是可以启用2D视频加速。试试在Debian里编译mesa-7.9，更新以后，也可以了。或许是这项特性需要的是OpenGL 2.0或者以上的支持吧。因为HD3650在mesa-7.7.1还只有OpenGL 1.5，而OpenGL 2.0则是要到mesa-7.8以后的版本。

在家里电脑的测试中，虚拟机内存还是1GB，同样的片源在开启2D视频加速还算流畅，CPU使用率比学校的电脑高了不少，这应该和OpenGL的性能有关，毕竟mesa驱动的性能和NVIDIA专有驱动要慢不少。另外还有一个原因就是家里的E2160是没有VT的，只能在虚拟机内使用一个内核，这也是制约解码性能的一个重要因素。

至于关闭了2D视频加速的情况则有点惨不忍睹了，视频播放感觉不流畅，而且CPU长期处于90%的状态，看来软解压不怎么行了，况且虚拟CPU还需要负担图形界面加速和画面渲染的工作，有点负担不过来了。

VirtualBox的2D视频加速有点让人失望，正如前文所说到的，不能应用GPU的硬解码。而且本身虚拟显卡在安装了增强功能包以后也有一定的2D加速能力，只要虚拟CPU性能足够强劲，解码器也足够地省资源，在虚拟机内播放视频还是很流畅的。不过在播放高清视频的时候，虚拟CPU已经需要负担沉重的食品解码任务，若是再承担画面渲染和2D图形加速则会应付不来。早前听网友说如果没有这项特性的确会让虚拟机全屏和最大最小的切换中导致影片播放不流畅的情况出现。看起来，这个特性还不是一无是处的，至少能够确保视频播放不会因为画面渲染性能问题而导致的不流畅出现。从这个特性也可以说明，视频加速是通过OpenGL实现的，并非实体GPU硬解码特性实现的。在老一点的显卡上，只要有OpenGL 2.0的支持，要实现虚拟机内的视频加速，也是可以的。只是能够加速多少，则取决于实体显卡的OpenGL 2.0性能了。这在Linux里面，驱动很影响一切的。

要想在虚拟机内引入GPU硬件解码并不是一件容易的事情，因为各家GPU厂商实现GPU硬件解码的办法都不一样，要做起来会十分困难。或许Xen的一个做法可以值得考量。利用IOMMU直接访问实体显卡，从而让GPU的所有特性都能应用在虚拟机内，包括3D加速、GPU解码甚至是GPU通用运算等。当然Gallium3D也具备OpenCL通用运算特性，若是把这项特性应用到虚拟显卡中，则能够进一步让视频解码提速。

补充测试，今天回到学校，还是用回4200+的电脑，测试了一次关闭2D视频加速的情况。打开720P的视频，虽然不算卡，但是CPU使用率已经达到了60%附近了，提高了近一倍。如果把播放最大化或者全屏播放，出乎意料的是虽然CPU使用率还是60%附近，但是视频则变得异常不流畅，比一台四五年前的老电脑更卡。这样看来要有强劲的CPU进行解码还不行，或许这个视频加速还需要有显卡的OpenGL加速才足够呢。