Mac OS X 上基于 FreeBSD/bhyve 的虚拟技术 xhyve

FreeBSD 下的虚拟技术 bhyve (The BSD Hypervisor) 是去年1月份正式发布的,包含在了 FreeBSD 10.0 发行版中。今天要玩的这个 xhyve 是基于 bhyve 的 Mac OS X 移植版本,也就是说我们想在 Mac 上运行 Linux 的话除了 VirtualBox, VMware Fusion 外,现在有了第三种选择。

xhyve 超级小,只有 230 KB,不依赖其他软件或库。下面的步骤基本按照 xhyve 作者的文档 xhyve – Lightweight Virtualization on OS X Based on bhyve 实现,不过跟着别人的文档并不总会一帆风顺,虽然文档已经很详细,总有碰到自己的问题的时候,有人报告说在自己的 Macbook (OS X 10.10.3) 上运行不成功。我在测试的过程中遇到的一个问题是硬盘分区问题,稍后会提到。我的编译和测试环境是 OS X Yosemite 10.10.4 + Xcode 6.3.2.

xhyve

xhyve 发布的是源代码,需要编译后运行,所以 Mac 上没有安装 Xcode 的话需要先到 App Store 安装。

使用 git 下载源码后编译,运行 xhyverun.sh 后会启动一个简单的 Tiny Core Linux 虚拟机:

$ git clone https://github.com/mist64/xhyve.git

$ cd xhyve
$ make

$ ./xhyverun.sh

上面的 Tiny Core Linux 只是测试和确定 xhyve 能运行,下面我们将在 xhyve 上安装和运行完整的 Ubuntu 14.04 Server 虚拟机。

在上面的 xhyve 目录里新建一个 ubuntu 目录用来存放所有和 ubuntu 虚拟机相关的东东。下载 ubuntu-14.04.2-server-amd64.iso,并把 iso 里面的两个系统启动需要的文件 vmlinuz 和 initrd.gz 拷贝出来:

$ mkdir ubuntu
$ cd ubuntu

$ wget http://releases.ubuntu.com/14.04/ubuntu-14.04.2-server-amd64.iso
$ dd if=/dev/zero bs=2k count=1 of=/tmp/ubuntu.iso
$ dd if=ubuntu-14.04.2-server-amd64.iso bs=2k skip=1 >> /tmp/ubuntu.iso
$ hdiutil attach /tmp/ubuntu.iso

$ cp /Volumes/Ubuntu-Server\ 14/install/vmlinuz .
$ cp /Volumes/Ubuntu-Server\ 14/install/initrd.gz .

创建一个 10GB 大小的硬盘文件当作 ubuntu 虚拟机的硬盘:

$ dd if=/dev/zero of=ubuntu.img bs=1g count=10

转到上层目录(xhyve)后新建一个脚本文件 ubuntu_install.sh,然后修改脚本文件为可执行:

$ cd ..

$ vi ubuntu_install.sh
#!/bin/sh

KERNEL="ubuntu/vmlinuz"
INITRD="ubuntu/initrd.gz"
CMDLINE="earlyprintk=serial console=ttyS0 acpi=off"

MEM="-m 1G"
#SMP="-c 2"
NET="-s 2:0,virtio-net"
IMG_CD="-s 3,ahci-cd,ubuntu/ubuntu-14.04.2-server-amd64.iso"
IMG_HDD="-s 4,virtio-blk,ubuntu/ubuntu.img"
PCI_DEV="-s 0:0,hostbridge -s 31,lpc"
LPC_DEV="-l com1,stdio"

build/xhyve $MEM $SMP $PCI_DEV $LPC_DEV $NET $IMG_CD $IMG_HDD -f kexec,$KERNEL,$INITRD,"$CMDLINE"

$ chmod +x ubuntu_install.sh

启动这个文件需要 sudo 权限哦:

$ ./ubuntu_install.sh
virtio_net: Could not create vmnet interface, permission denied or no entitlement?

$ sudo ./ubuntu_install.sh

xhyve

这时候会看到 ubuntu 的标准文本格式的安装程序,安装过程中唯一要注意的是硬盘分区的时候不要选择自动分区,也不要选择 LVM 分区,选择手动分区,使用最简单的一个 root 区一个 swap 区。我碰到的一个问题就是选择自动分区后到后来安装完毕启动系统的时候挂在那里不动。

还有一个要注意的地方,安装完毕后,这时候选择 Go Back,因为我们要到 Execute a shell 命令行界面把里面的内核文件拷贝出来留作以后启动用:

  ┌─────────┤ [!!] Finish the installation ├──────────┐
  │                                                                        │
┌│                         Installation complete                          │
││ Installation is complete, so it is time to boot into your new system.  │
││ Make sure to remove the installation media (CD-ROM, floppies), so      │
││ that you boot into the new system rather than restarting the           │
││ installation.                                                          │
││                                                                        │
└│     <Go Back>                               <Continue>                 │
  │                                                                        │
  └────────────────────────────────────┘

选择 Execute a shell 后转到目标目录,知道虚拟机的 IP 地址后用 nc 把虚拟机和外面的世界(Mac)连起来传输文件:

BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # cd /target/
/target # sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr da:ae:82:16:cf:32
          inet addr:192.168.64.3  Bcast:192.168.64.255  Mask:255.255.255.0
          inet6 addr: fe80::d8ae:82ff:fe16:cf32/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24426 errors:0 dropped:0 overruns:0 frame:104
          TX packets:13283 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:32881668 (32.8 MB)  TX bytes:924462 (924.4 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

/target # tar c boot | nc -l -p 9000

在 Mac 上接受文件:

$ cd xhyve/ubuntu
$ nc 192.168.64.3 9000 | tar x

有了 vmlinuz-3.16.0-30-generic 和 initrd.img-3.16.0-30-generic 内核文件,我们就可以启动 ubuntu 虚拟机了,注意这时候 root=/dev/vda1 哦:

$ cd ..

$ vi ubuntu_boot.sh
#!/bin/sh

KERNEL="ubuntu/boot/vmlinuz-3.16.0-30-generic"
INITRD="ubuntu/boot/initrd.img-3.16.0-30-generic"
CMDLINE="earlyprintk=serial console=ttyS0 acpi=off root=/dev/vda1 ro"

MEM="-m 1G"
#SMP="-c 2"
NET="-s 2:0,virtio-net"
#IMG_CD="-s 3,ahci-cd,ubuntu/ubuntu-14.04.2-server-amd64.iso"
IMG_HDD="-s 4,virtio-blk,ubuntu/ubuntu.img"
PCI_DEV="-s 0:0,hostbridge -s 31,lpc"
LPC_DEV="-l com1,stdio"

build/xhyve $MEM $SMP $PCI_DEV $LPC_DEV $NET $IMG_CD $IMG_HDD -f kexec,$KERNEL,$INITRD,"$CMDLINE"

$ chmod +x ubuntu_boot.sh
$ sudo ./ubuntu_boot.sh

运行成功:

xhyve

Xen 调整 NTFS 虚拟硬盘大小

前几天 VPSee 升级了服务器的硬盘,现在有了更多的空间可以分给虚拟机用户,就算给每个人分 100GB 都不是问题,问题是每个人 100GB 会给服务器备份工作带来很大压力,所以决定在原来每个人 20GB Windows 虚拟机的基础上扩展到 40GB. 以前介绍了如何调整 Xen 虚拟硬盘大小,不过只针对 guest 操作系统是 Linux、文件系统使用 ext2/ext3 的情况,如果 guest 操作系统运行的是 Windows、文件系统是 NTFS 该怎么办呢?

关闭 Windows 虚拟机:

#/usr/sbin/xm shutdown vm01

给虚拟机镜像文件(.img)追加 20GB 空间:

# dd if=/dev/zero bs=1G count=20 >> /vm/vm01.img

现在新的虚拟机 image 多了 20GB 额外空间,不过分区表没有变,所以这个时候需要一个分区软件修改分区表,把新增加的空间加到分区表。不过在使用分区工具前需要把 image 挂到一个 loop 设备上:

# /sbin/losetup -f
/dev/loop2
# /sbin/losetup /dev/loop2 /vm/vm01.img

安装 gparted 分区软件,然后修改分区表:

# yum install gparted
# gparted /dev/loop2

这个时候会看到如下图所示的分区结构,注意这个时候直接修改 /dev/loop2p1 分区大小会报错,所以这个时候可以直接在 unallocated 上面新建一个 unformatted 分区。

gparted

分区完后卸载 loop 设备:

# losetup -d /dev/loop2

启动 Windows 虚拟机:

# /usr/sbin/xm create vm01

进入 Windows 后在磁盘管理里面可以看到未格式化的分区,接下来就可以格式化并使用这个分区了,也可以使用其他的分区工具把新建的分区和老分区合成一个区或者分成多个区。

几种开源虚拟产品的性能比较

周末看了一篇 Virtualization of Linux servers,这篇论文测试了当前几个主要开源虚拟产品的性能,刚好配合前段时间看的几种不同虚拟技术的隔离性能。虚拟机的性能和隔离性都是虚拟技术非常重要的性能指标,大面积测试和比较不同的产品需要消耗大量的时间和精力,这篇文章在前人的基础上较全面测试了 Linux 下不同虚拟产品的性能,涉及到的有 KQEMU、KVM、Linux-VServer、OpenVZ、VirtualBox、Xen.

测试方法

整个测试在一台 IBM/Lenovo Desktop PC 上进行,这台 PC 配有 Intel Core 2 Duo 6300 处理器,4GB 内存和 80GB SATA 硬盘。服务器(host)操作系统是 Ubuntu 7.10,内核是 2.6.22-14,虚拟机(guest)操作系统是 Ubuntu 6.10. 网络部分的测试则通过另外一台 PC 来进行。使用的测试软件和参数如下:

Kernel Build
$ make defconfig
$ date +%s.%N && make && date +%s.%N
$ make clean

Dbench
$ /usr/local/bin/dbench -t 300 -D /var/tmp 100

Netperf
$ netserver # server side
$ netperf -H # client side

Rsync
Experiment 1:
$ date +%s.%N && rsync -av ::kernel /var/tmp && date +%s.%N # client side
# where ’kernel’ is the linux-2.6.22.14 file tree (294M)
$ rm -fr /var/tmp/*
Experiment 2:
$ date +%s.%N && rsync -av ::iso /var/tmp && date +%s.%N # client side
# where ’iso’ is ubuntu-6.06.1-server-i386.iso (433M)
$ rm -fr /var/tmp/*

Dd
Experiment 1:
$ dd if=/opt/iso/ubuntu-6.06.1-server-i386.iso of=/var/tmp/out.iso
$ rm -fr /var/tmp/*
Experiment 2:
$ dd if=/dev/zero of=/dev/null count=117187560 # 117187560 = 60G

Bzip2
$ cp /opt/ubuntu-6.06.1-server-i386.iso .
$ date +%s.%N && bzip2 -9 ubuntu-6.06.1-server-i386.iso && date +%s.%N
$ rm ubuntu-6.06.1-server-i386.iso.bz2

SysBench
$ mysql> create database sbtest;
$ sysbench –test=oltp –mysql-user=root –mysql-host=localhost –debug=off prepare
$ sysbench –test=oltp –mysql-user=root –mysql-host=localhost –debug=off run

测试结果

  • kernel build:内核编译是个长时间重负荷的 CPU 处理过程,期间还会涉及到多线程处理和小文件的读写操作。使用 OS-level 和 para-virtualization 技术的虚拟产品性能较好,接近 Linux.
  • dbench:是个文件系统测试工具,用来测试文件服务器的负载,Linux-VServer 在这项测试中大比分胜出,VirtualBox 则在这项测试中不明原因的 crash,其余产品的测试结果均比 Linux 低约30%.
  • netperf:是用来测试网络性能的工具,使用 TCP 包流来测试网络数据交换的性能。这项测试中基于 QEMU 的虚拟产品性能较差,VirtualBox 在这项测试中表现较好,可能和 VirtualBox 使用一个特别的网络驱动有关。
  • rsync:也是用来测试网络。OpenVZ 最好,KVM 最差,其余几个差不多。
  • dd:用来测试磁盘 I/O 的性能,不用涉及太多的 CPU. Xen 和 KVM 性能较好,OpenVZ 明显很慢。
  • bzip2:压缩也是个重负荷 CPU 的工作,但是不用磁盘频繁 IO 操作。除了 KQEMU 和 OpenVZ 外,其余几个虚拟机性能接近 Linux.
  • sysbench:数据库服务器测试。在这个测试中,Linux-VServer 和 Xen 性能接近 Linux,而 KVM 和 OpenVZ 性能只有他们的一半。
  • scale:在最后一项也是最考验虚拟技术的 scale 测试中(sysbench at scale),Xen 表现优异,其他几个虚拟产品在虚拟机数目达到32个的时候,性能大大降低,只有 Xen 能在扩大虚拟机数目的同时保持较好的性能损失。KVM 在8个虚拟机的时候表现最好,VirtualBox 在16个的时候表现最好,其余产品在虚拟机数目达到4个的时候表现最好。

sysbench-at-scale

总的来说,Xen 除了在 dbench 文件系统测试中有点落后外,在其余所有的测试中都表现不俗,尤其是在最后的 scale 测试中表现惊艳。

几种不同虚拟技术的隔离性能

周末看了一篇 paper:Quantifying the Performance Isolation Properties of Virtualization Systems,这篇论文测试了几种不同虚拟技术的隔离性能,隔离性是虚拟机性能的重要指标,尤其是对商业 hosting,如 VPS、VDS 等来说,虚拟机能否把各个 VPS 合理的隔开并让物理机器上的每个 VPS 能按照事先约好的定义(如 CPU/RAM/DISK 等)公平而且充分的利用物理服务器资源很重要。这篇论文测试了目前市场上使用最普遍的几种虚拟技术以及相关代表产品,有代表 full virtualization 技术的 VMWare Workstation,代表 para virtualization 技术的 Xen,代表 operating system level virtualization 技术的 OpenVZ 和 Solaris Containers,提出的问题就是看看这些不同的虚拟技术和产品能不能、以及能在多大程度上隔离和保护每个物理机器上的虚拟机,比如能否保护好每个 VPS,能有效为不同 VPS 用户分割资源,不让 “不良” 用户超过计算额度、过分抢占其他用户的资源。

测试方法

这篇论文描述的实验方法是,首先确定一些 baseline 数据,然后做 stress 测试。

  1. 把1台物理机器分成4个虚拟机,每个虚拟机上运行1个 apache web server + SPECweb 2005 组合来得到 baseline 数据。
  2. 然后做 stress 测试,同样是上面的1台物理机器和4个虚拟机,也同样在运行1个 apache web server + SPECweb 2005 组合,只不过这个时候在其中1台虚拟机上增加了 stress test,来测试这个 stress 加上去以后是否对原有的虚拟机有影响、有多大影响。这样测试结果就可以和前面4台虚拟机没有 stress 测试的数据做比较。

主要测试了以下一些性能参数,以及测试每种参数用到的方法:

  • CPU Intensive:让虚拟机不停的做整数计算操作;
  • Fork Bomb:不停的 fork 进程;
  • Memory Intensive:不停的分配、使用内存,而不 free 掉内存空间;
  • Disk Intensive:用 IOzone 工具,开10个线程,每个线程不停的进行交替读写操作(iozone -i0 -i1 -r 4 -s 100M -t 10 -Rb);
  • Network Intensive (Transmit):开4个线程,每个线程不停的发送 60K 大小的 UDP 包;
  • Network Intensive (Receive):开4个线程,每个线程不停的接受 60K 大小的 UDP 包。

测试结果

测试结果如下图所示,0代表结果最好,DNR(Do Not Response) 代表最差。测试结果和理论上预料的一致,Full virtualization 技术能完全模拟一台计算机,不需要修改 guest 操作系统就可以直接在其上运行,由于其技术的优越性隔离性能最好;para virtualization 需要修改 guest 才能运行,隔离效果其次;最后是 operating system level virtualization,在操作系统层面虚拟,不能运行不同的操作系统,隔离不彻底,其隔离性能也最差。同一虚拟技术的不同产品,如 OpenVZ 和 Solaris Containers 也表现出了差异。

the performance isolation of virtualization systems

VPSee 只对 Xen 和 OpenVZ 有兴趣,这里省略了 Solaris Containers 的测试数据和图片,大家如有兴趣可参考原文。

Xen 和 KVM 的性能对比

最近出现提供 KVM/Qemu VPS 的服务商让 VPSee 有点惊讶,印象当中 KVM 还是一个很新的项目,还远没有达到成熟应用的工业标准,现在已经看到有人/公司开始提供基于 KVM 的 VPS 了,KVM 在众多重量级厂商的强力推动下果然发展很快。2008年9月 RedHat 宣布收购 KVM 老家 Qumranet,并在今年9月份刚刚过去的 Red Hat Summit 2009 上宣布 KVM 将是 RHEL 5.4 的下一代虚拟技术,RHEL 5.4 同时也会支持 Xen,对 Xen 的支持会持续到 RHEL 5 产品线的结束,Novell 已经在 SUSE Linux Enterprise Desktop 产品线上使用 KVM,Ubuntu 已经指定 KVM 为其默认虚拟技术了,KVM 在短时间内就已经赢得了三大 Linux 厂商的支持,想让人忽略都很难。

前天看了一篇关于 Xen 和 KVM 性能对比的 paper,Quantitative Comparison of Xen and KVM(图片来源),较详细的比较了 Xen 和 KVM 的性能和扩展性,不过这篇 paper 的发表时间是2008年6月,有点老了,现在 KVM 的性能和成熟度肯定有了很大的提高。这篇 paper 从三个角度来比较了 Xen 和 KVM 的性能:

总体性能

分别测试 CPU 速度,内核编译速度和 IO 的读写速度,结果如图,Xen 的 CPU 测试结果非常接近 Linux,性能非常好;KVM 在 CPU 测试中表现也不错,比 Xen 差一点,但是在 IO 测试中要比 Xen 好一些。

craigslist internals overview

隔离性能

隔离性能主要用来测试 Xen 和 KVM 能否有效隔离 guest,以便每个 guest 都能公平的得到计算资源,不会被某个“坏” guest 占用资源。在隔离方面 KVM 比 Xen 做得要好一些,Xen 在网络方面几乎没有隔离,虽然隔离性能不好,反而提高了服务器整体的网络利用率,按需分配肯定比平均分配效率高。图中 DNR 的意思是 “did not return”,是最坏的一种情况。

craigslist internals overview

扩展性能

扩展性能测试的是随着 guest 的增多,有没有、有多少额外的性能损失,因为 guest 之间的切换会造成性能损失。测试结果显示 Xen 有很棒的扩展性能,几乎是随着 guest 的个数线性增加的;而 KVM 扩展性能就很差,扩展到4个 guest 就崩溃了1个 guest,扩展到8个崩了4个,扩到16个崩了7个,扩到30个整个系统都崩溃了。

craigslist internals overview

解决 loop device 数目限制问题

今天早上在 Xen 服务器上增加一个 domU 虚拟机的时候遇到一个问题:

# /usr/sbin/xm create vm05
Using config file "/etc/xen/vm05".
Error: Device 2049 (vbd) could not be connected. Failed to find an unused loop device

上面错误显示没有找到可用的 loop device,可能是当前使用的内核版本或者内核配置对 loop devices 有最大数目的限制,查看一下当前正在使用的的 loop devices:

# /sbin/losetup -a
/dev/loop0: [fd00]:32014427 (/vm/vm01.swap)
/dev/loop1: [fd00]:44105729 (/vm/vm01.img)
/dev/loop2: [fd00]:32014432 (/vm/vm02.img)
/dev/loop3: [fd00]:32014433 (/vm/vm02.swap)
/dev/loop4: [fd00]:32014429 (/vm/vm03.swap)
/dev/loop5: [fd00]:43057161 (/vm/vm03.img)
/dev/loop6: [fd00]:1376674 (/vm/vm04.img)
/dev/loop7: [fd00]:32014428 (/vm/vm04.swap)

CentOS/RHEL 5

在 CentOS/RHEL 5 系统上默认的 active loop devices 数目是8,如上面看到的 loop0-loop7,只创建了4个 vm,用到了8个 loop devices,4个用来挂载 os image,4个用来挂载 swap image. 对于基于 file 的 Xen OS image 来说,需要修改这个默认值以便获得更多的 loop devices 挂载更多的 image. 编辑 /etc/modprobe.conf 来修改 active loop devices 最大限制数目:

# vi /etc/modprobe.conf
options loop max_loop=64

CentOS/RHEL 6

在 CentOS/RHEL 6 系统上更改 loop 最大数目更容易,最多支持256个,还不用重启:

# MAKEDEV -v /dev/loop

不过上面更改重启就会消失,所以把上面命令要加到 /etc/rc.local 里:

# vi /etc/rc.local
...
MAKEDEV -v /dev/loop

Ubuntu/Debian

在 Ubuntu/Debian 上修改默认 loop devices 最大限制数目:

# echo 'options loop max_loop=64' >/etc/modprobe.d/loopdev

应该给 Xen Dom0 和 DomU 配置多大内存?

Xen Dom0 需要多大内存来支持各个 DomU 的正常运行要看具体情况,没有一个 magic formula (神奇公式)可以参考;而 Xen DomU 需要多大内存能正常运行则主要取决于运行在 DomU 上的 Guest OS 及应用的需求。

DomU

给 DomU 安排内存较简单,主要看什么样的 Guest 操作系统以及上面跑什么样的应用,复杂的图形桌面系统、还是简单的 Web 服务器,这里有一些操作系统厂商提供的推荐配置:

  • 根据 Ubuntu 官方文档 推荐的最小内存配置,运行 Ubuntu 9.04 Desktop 版本和 GNOME/KDE 等完整桌面图形系统,最小建议 384MB,我试过 256MB,可以运行,速度也可以,但是可用内存剩下不多,已经开始频繁 swap 了;如果使用中量级窗口管理器,像 xfce,最小建议 192MB;使用类似 fvwm/fluxbox/twm/icewm 等轻量级窗口管理器或者完全使用命令行,最小建议 64MB. 运行 Ubuntu 9.04 Server 版本,不用 GUI,最小安装,完全当作服务器使用,最小可以小到 32MB,不过 VPSee 推荐至少 64MB 才可以运行一个由 mysql/php/nginx 支持的小网站、博客。
  • 运行 CentOS 5.3 需要的内存要多一些,不用 GUI,最小安装,完全当作服务器使用,RedHat 推荐最小内存是 256MB;VPSee 推荐最小建议 128MB,我试过 64MB 虽然可以运行,但是明显感到慢,使用 yum 升级就能感觉到,就不用提 mysql/php/nginx 了,就算能运行起来也没多大实际意义。
  • Debian 5.0 的内存需求和 Ubuntu 类似,稍微可以偏低一些。
  • Gentoo 官方推荐最小 64MB,但是每次升级系统都需要编译,即使可以在 64MB 下安装运行意义也不大,因为每次升级软加包都需要下载代码编译,编译需要消耗大量 CPU 和内存。这也是 VPSee 不推荐在小 VPS 上使用 Gentoo 的原因。
  • Freebsd 官方推荐最小 24MB,同样的主要看应用,对于一个 mysql/php/nginx 应用,VPSee 推荐 64MB.

Dom0

为 Dom0 配置内存要稍微复杂一些,配置多了 DomU 可使用的内存就少了,配置少了就会担心 Dom0 不够用。有效限制 Dom0 的内存大小还有助于安全。假设 Dom0 本身不做任何其他的应用(当然也不包括 GUI)。如何分配内存让 Dom0 的内存最小而且又能最有效的管理那些 DomU 呢? Running Xen: A Hands-on Guide to the Art of Virtualization 这本书介绍了一些有用的经验,给 Dom0 分配多大内存没有一般公式可循,只能提供一些经验参考:

  1. 首先看 Dom0 上运行的 OS 对内存的需求怎么样,比如:Dom0 上如果跑的是 CentOS,这样 Dom0 通常最低需要 128MB,如果是 Debian 可能最低需要 64MB;
  2. 再看看需要一些什么样的服务,比如可能会在 Dom0 上运行 DNS/DHCP/SSH 之类的服务来支持 DomU;
  3. 可能需要在 Dom0 上做一些日常维护,比如:备份、管理 DomU、升级、运行一些 shell script、检查日志等,这会需要一些内存运行;
  4. DomU 与外界网络通信需要与 Xen 虚拟出来的网卡打交道,比如:bridge,routing,firewall 什么的,Dom0 要管理这些需要消耗一些内存;
  5. 为了保障安全,最好最小化 Dom0 的功能,最小化安装,只启动必须的服务,让 Dom0 只负责管理 DomU,最小化的策略还可以增加整个服务器的安全性。

举个实例,对于一个 2G 的双核机器来说,如果 Dom0 只是用来管理 DomU,给 Dom0 配置 128-256MB的内存就可以了,剩下的内存可以分出10-15个 128MB 的 DomU.

SnowFlock 快速克隆 Xen VM

这个周末看了一篇关于快速克隆 Virtual Machine(VM)的文章,SnowFlock: Rapid Virtual Machine Cloning for Cloud ComputingSnowFlock 是 University of Toronto 的一个项目,核心想法是把 Unix 操作系统中 fork 的概念引入到云计算,不过不是用来 fork 进程,是 fork 虚拟机,这个 fork 与原始的 Unix fork 有几点不同:

1、VM fork 可以 fork 到其他物理机器上,Unix fork 只能在本机操作系统内 fork;
2、parallel fork,一次 fork 调用可以创建多个 child VMs;
3、VM fork 从 parent VM 那里复制所有的进程和线程。

SnowFlock 从不同的物理机器上 fork 出相同的 VM,这些 VMs 连在一起构建一个私有 cluster,拥有自己的虚拟网络。SnowFlock 根据计算的需要分配计算资源,从众多的物理机器中创建一个合理大小的 Xen VM Cluster,由这个 cluster 来完成目标计算,完成计算后,这个 cluster 就自动消失了。

snowflock

把 Unix 中的 fork 概念用到云计算 VM 克隆中是个很有意思的想法,SnowFlock 如何做到快速克隆呢?做到 fork 并不难,最土的想法就是 fork 时利用虚拟机的 suspend/resume 功能,把 VM suspend 后将整个 VM 文件拷贝到别的机器上然后 resume 运行。但是这个过程太慢,在 VPSee 的 Mac 上 suspend 一个 vmware 虚拟机大概需要 30秒,又需要另外 30秒 resume。SnowFlock 克隆 VM 只需要不到1妙,它是如何做到这点的?

1、VM 文件里包含 memory image,disk image,各种状态、配置信息等,SnowFlock 只复制必要的状态信息(VM descriptor),这样就不必复制包含整个操作系统在内的 VM 文件,如果 disk image 设的是 10GB,那就不必复制 +10GB。Memory-On-Demand 允许 child VM 只在需要某个 memory 页面的时候才去 parent VM 那里克隆,可以在 fork 后进行,减少了初始克隆 VM 的体积;
2、VM 克隆的时候不必克隆所有的 memory image,只需要原始 image 中一小部分信息(Memory State),这又减少了需要克隆的体积;
3、child VM 可以在 fork 到其他机器上后再分配内存。如果先分配内存会造成 memory image 过大,影响克隆速度。如果 parent VM 分配了页面,比如 malloc,但是还没有用到这些页面、没有数据的话这些页面也用不必克隆到 child VM。还有一些可以循环使用的 kernel buffer 也不必克隆,,进一步减少克隆体积;
4、child VM 通常执行类似的代码和数据结构,如果 fork 多个 VMs 的话有助于 multicast;
5、把数据 multicast 给多个 VMs,只要有1个 VM 请求页面,这个页面也会被 multicast 给其他 VMs。一次操作就把数据分发给所有 VMs 还可以减少网络负载。

简单的说就是,尽可能减少 VM 携带的信息量来达到快速克隆的目的,这篇论文指出只需要克隆原 VM 0.1% 的信息就足够运行一个 child VM 了。SnowFlock 在 Xen 3 上实现了上述快速克隆的概念,具体实现过程很复杂,如有兴趣可参考论文和代码。SnowFlock 实现的简单图示:

snowflock

(图片来自 SnowFlock 官方网站和资料。)

Xen 的性能

周末看了来两篇关于 Xen 的论文,一篇是 University of Cambridge 发表的 Xen and the Art of Virtualization;另一篇是 Clarkson University 的 Xen and the Art of Repeated Research。Repeated Research 这篇是对 Virtualization 那篇做的重复试验,两篇论文的测试数据相似,很好的证明了 Xen 的性能优势,并且回答了 VPSee 感兴趣的4个问题:

本文数据、部分结论和图片均来自以上两篇论文。

1、Xen 相对 Native,VMware 等来说性能好多少?
从理论来说,使用 para virtualization 技术的 Xen 要比使用 full virtualization 的 VMware 性能要好。测试的结果也证明了这个说法, Xen 相对 Native Linux 来说性能损失不大,相对 VMware 来说性能要好1倍左右。
Xen Native VMware UML 性能对比

2、Xen 适合做 Web/VPS Hosting 吗?
Xen 非常稳定、可靠,一个普通的服务器(如果内存够的话)完全能够承受16个左右的 DomU/VPS 同时运行,但是如果同时运行128个左右的虚拟系统的话性能会很差,即使内存、硬件配置足够。下图中随着 DomU 的增加,Xen 总体性能基本能和 Native 持平。很显然 Xen 等虚拟技术并不是用来提高整个服务器性能的,而是通过隔离操作系统来充分发挥每个 DomU 上的计算能力,相比独立服务器虚拟技术极大的节约了计算资源、电力、物理空间、管理维护、IP地址等,所以被称之为“绿色计算”。
Xen Web和数据库服务器性能

3、Xen 能在一般老机器(5年左右)上运行吗?
可以,不但可以运行,而且运行得很好。在1台配置为 P3 1GHZ/512MB/40GB 的老机器上和1台 Xen 2.4GHz/2GB/146GB 的新机器上测试的结果显示,Xen 的性能损失比较稳定,与硬件配置好坏关系不大。也就是说在好机器上 Xen 的性能相对 native 来说损失是5%的话,那么在差机器上也相应损失5%,可以把 Xen 看作是真实硬件一样,随着硬件配置逐步升高相应性能也逐步提高。VPSee 做得简单测试显示有10%左右的性能损失。

4、Xen 在普通服务器上运行和在专门为虚拟设计的服务器上运行的差别?
就从性能方面来说,专门为虚拟环境设计的的 IBM zServer 服务器和普通的 Dell 服务器在相同硬件配置下性能基本没什么差别。但是就价格来说 zServer 要卖得要贵得多,这就是专门服务器专门的地方,卖的不是硬件配置,卖的是高可靠性、高扩展性、可管理性、可维护性等。