网段隔离的一种实现

网段隔离的一种实现
一套物理网络虚拟出多套网络

    客户中心点与多个分支点组网，每个分支点与中心点/汇聚点之间都开有一条点对点以太网专线。客户每个办公点都有多个应用，例如视频会议的、OA的、财务的等，这多个数据流之间需要彼此隔离，例如OA网段就不能访问视频会议。
    原本计划在汇聚端用汇聚口和客户设备对接，即一个物理光口里面划分多个逻辑接口，逻辑接口之间用VLAN隔离，但客户测试反馈没法实现隔离。
    后来咨询了设备厂家，给出建议，将汇聚端的汇聚口全部改为独立的物理端口，这样分支点到中心点之间全部是透明管道，里面传输的数据不管带不带VLAN、带什么VLAN，都可以双向传送；客户在中心点加三层交换机并配置ACL，每个分支点加一台二层交换机，分支点的前两个端口固定是走指定业务例如视频会议，无法和其他网段/业务互通，后面的端口固定走其他业务例如OA，也无法和其他网段/业务互通。问题解决。

MySQL的迁移

前天从原Ubuntu把某数据库迁移到新装Ubuntu虚拟机，开始以为每个数据库是一个独立文件夹，例如自带的 /var/lib/mysql/mysql/、/var/lib/mysql/performance_schema/，自己创建的数据库**，于是只迁移了**，其余没理，后来发现原来mysql中创建的用户没了，于是新建了用户： create user 'username'@'localhost' identified by 'password'; grant all privileges on name_of_db.* to 'username'@'localhost'; 接下来发现进去数据库**后能看到表，但是列不出表的内容，查了下，原来数据库内容不在**文件夹，仔细一看，**文件夹很小，几十万条数据不可能存在里面，一查原来mysql数据库默认都是放在 ibdata1 这个文件里面的，新ibdata1大小只有18M，原有ibdata1有90M。如果需要每个数据库单独存储，则需要设置，今天重新查了下，使用 show global variables; 里面显示的选项 innodb_file_per_table 默认 OFF，开启此项后默认存放在每个数据库的文件夹里，每个表单独一个文件。 于是将原有的 ibdata1 移动到新机，终于可以看到数据了，但是发现数据不全，前天睡前想了想，要仔细看下数据，看创建时间，以及对应的ID是否和log一致，昨天早上一看是OK的，之前吓了一跳，以为几个月来爬到的东西全没了。 总结下经验，移动数据库要么导出数据导入另一机器的数据库，或者使用mysql自带数据库迁移、复制之类的功能，要么将相关文件夹和文件全部移动或复制，包括 /var/lib/mysql/mysql/、/var/lib/mysql/performance_schema/、**自己的数据库、ibdata1、ib_logfile0、ib_logfile1，这些相关的文件都需要保留。

lvm硬盘的挂载

原虚拟机硬盘是逻辑卷lvm，启用新虚拟机后需要把原硬盘数据迁移过来，可以scp，但是有效率问题和权限问题，于是考虑直接挂载。 1.在新虚拟机添加原有虚拟机硬盘 2.新虚拟机未使用lvm所以默认没有装lvm2工具，使用sudo apt-get install lvm2安装（原虚拟机使用lvm于是默认安装lvm2工具 3.使用pvs或pvdisplay查看物理卷，使用vgs查看卷组，使用lvdisplay查看逻辑卷，其中逻辑卷状态为not available，/dev/下没有相关设备，于是使用sudo vgchange -ay /dev/ubuntu-vg激活，一次性激活了ubuntu-vg中的两个分区：root和swap_1 4.挂载：sudo mount /dev/ubuntu-vg/root /mnt 进入查看，文件属性都没变，所属用户名也没变，所有信息完全一样。

VMware的vmem文件失效清理

VMware guestOS从一台电脑挪到另一台电脑后，发现原有vmem文件（大小和当时所分配的内存一样）及对应文件夹很久都没有被修改过了，而另外有一个**.vmem和文件夹 是实时被修改的，怀疑原有的失效，而且在很久以前，于是尝试着删除并运行虚拟机，一切正常 总结：由于种种原因（例如怀疑重装VMware等）VMware会产生vmem及文件夹垃圾文件，vmem占用大小和内存一样，这时可删除之 后记20170220： 除vmem文件外，wmdk文件也容易产生垃圾，虽然并不一定占用空间。例如在删除虚拟机附带的另一个虚拟磁盘（虚拟机名为 Ubuntu 64 ，虚拟机自带的第一个虚拟磁盘是虚拟文件，对应的文件为 Ubuntu 64.vmdk 和 Ubuntu 64-s001.vmdk、Ubuntu 64-s002.vmdk、Ubuntu 64-s003.vmdk 等，而另一个虚拟盘为计算机硬盘的最后一个物理分区，对应配置文件为 Ubuntu 64-0.vmdk 和 Ubuntu 64-0-pt.vmdk ，可在虚拟机里自由删除和添加 ）后，对应的文件 Ubuntu 64-0.vmdk 和 Ubuntu 64-0-pt.vmdk 并没有被删除，下次添加时会从下一个编号开始，例如 Ubuntu 64-1.vmdk 和 Ubuntu 64-1-pt.vmdk ，删除/添加操作一次就产生了多余的两个文件，虽然文件很小。可以在虚拟机删除盘后手动删除这两个文件，再添加新盘，新的配置文件就和原来的名字一样 Ubuntu 64-0.vmdk 和 Ubuntu 64-0-pt.vmdk ，不会产生垃圾文件。

swap性能调优

hostOS为win7SP1 64位8G内存，guestOS为Ubuntu14.04 64位,分配2G内存，足够使用，原本不想分配swap，但当初在创建逻辑卷时分配了2G空间swap，想想还是挂载上吧，万一需要用到呢？但是普通情况下直接使用也不好，会降低速度，那就尽量先用内存吧，如何设置呢？ 在/etc/sysctl.conf中，使用vm.swappiness，设置成5吧，意味着内存使用了95%剩余5%的时候开始使用swap空间，重启系统生效，或者命令 sudo sysctl -p 重新加载配置文件后生效； 另外sudo sysctl vm.swappiness=10 或者 sudo su 后 echo 10 > /proc/sys/vm/swappiness 是临时修改swappiness值 而cat /proc/sys/vm/swappiness是查看swappiness值

Ubuntu swap分区无法加载的解决

win7 VMware下Ubuntu 14.04 64位系统，guestOS挪到另一电脑后磁盘重新删除、添加，发现sudo fdisk -l结果中显示： ... Disk /dev/mapper/ubuntu--vg-root doesn't contain a valid partition table ... Disk /dev/mapper/ubuntu--vg-swap_1 doesn't contain a valid partition table 查了下据说逻辑卷都会被这样提示，不影响（从后面测试折腾来看，确实不影响，这个提示一直有） 进一步折腾发现 sudo parted /dev/sda print all 显示： ... Error: /dev/mapper/ubuntu--vg-swap_1: unrecognised disk label 这个就有问题了，继续执行free显示： ... Swap: 0 0 0 确实有问题，swap为0，没能被加载，sudo blkid结果里面也没有swap，而且/etc/fstab里面swap也没被注释掉，各种结果都正式swap加载有问题 继续用sudo pvdisplay、sudo vgdisplay、sudo lvdisplay（查询逻辑卷信息）查询一下，得知系统空间用的是逻辑卷，大小大概20G，其中18G用作Ubuntu存储目录，另外2G分给了swap，尝试手动挂载swap： sudo swapon /dev/mapper/ubuntu--vg-swap_1 和 sudo swapon /dev/ubuntu-vg/swap_1 （其实/dev/mapper/ubuntu--vg-swap_1和/dev/ubuntu-vg/swap_1是两个链接，均指向/dev/dm-1），均提示：swapon: /dev/mapper/ubuntu--vg-swap_1: read swap header failed: Invalid argument 继续查，网上有不少记录，Ubuntu官网就有两个相关问题贴：953875和1310058， https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/ https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22 指出是Ubuntu的一个bug，和加密软件有关，它把swap的UUID改变了 sudo blkid结果里面没swap的UUID，手动执行：sudo mkswap /dev/mapper/ubuntu--vg-swap_1，创建swap分区，执行结果显示了UUID，接下来将/etc/crypttab里面的UUID修改为正确的UUID（或者直接加-U参数指定UUID），另外在行的最后加一个“,offset=8”（8个512字节，网友测试6就可以了，有人建议8，有人1024；根据网友描述，按我的理解，前面那部分存储了UUID，而加密软件正好对这部分进行写操作，于是会改变UUID，所以swap从后面一点开始，避免被写导致，保持UUID不变），立马OK（不加offset也成功加载swap，结果和下面一样）： sudo swapon -a 后 free显示： ... Swap: 2093052 0 2093052 但又出现新提示： swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory locate cryptswap无结果，后来发现在/etc/fstab里面有两行关于swap的，开始我以为两行是相互配合的，现在看来是冲突了： /dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0 /dev/mapper/cryptswap1 none swap sw 0 0 查看/dev/mapper/下面并无cryptswap1文件或文件夹，想了想，也没有加密的计划，越简单越好，于是注释掉后面行，执行： sudo swapoff -a sudo swapon -a free结果显示正常 Ubuntu官网那两个贴还建议：sudo update-initramfs -u，于是也执行了（虽然不懂有什么用） 另外fstab里面直接用UUID指定分区： UUID=185ed9d3-bb19-4a8c-bc86-e57b226e9676 none swap sw 0 0 也可以； 后面继续摸索：sudo /etc/init.d/cryptdisks reload 之后 再 sudo fdisk -l，结果多了一个/dev/mapper/cryptswap1， （执行sudo /etc/init.d/cryptdisks reload的时候swapoff一下，不然出现分区已经挂载之类的提示，可能和这个有关） 这时修改/etc/fstab，使能：/dev/mapper/cryptswap1 none swap sw 0 0 挂载：sudo swapoff -a 后 sudo swapon -a，成功，说明之前的/etc/init.d/cryptdisks是没有加载或者有冲突（可能是fstab里两个swap项冲突），fstab只保留一个cryptswap1重启后OK 简单总结下swap挂载不上的解决： 最简单的可以直接在/etc/fstab里添加：UUID=**** none swap sw 0 0，并删除其余swap项(获取UUID可通过：sudo blkid，结合ls -al /dev/disk/by-uuid/查看现有磁盘设备的UUID；sudo lvdisplay查看逻辑卷UUID即LV UUID，与UUID不一样)，普通磁盘时建议此方式； 磁盘加密时建议此方式： 如果有装cryptdisks加密磁盘的工具（Ubuntu默认有），有/etc/crypttab，则检查里面UUID，或直接指定UUID重新创建swap分区：sudo mkswap -U **** /dev/mapper/ubuntu--vg-swap_1，或者sudo mkswap /dev/mapper/ubuntu--vg-swap_1后将结果中正确的UUID添加至crypttab对应的项；接下来在crypttab对应项后面加上“,offset=8”（避免UUID写在太前而被加密软件写操作覆盖改变）；然后fstab中保留唯一的swap项：/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0，或者确保/etc/init.d/cryptdisks开机启动能正常加载后保留fstab里swap唯一项：/dev/mapper/cryptswap1 none swap sw 0 0；最后sudo update-initramfs -u。如果偶尔系统启动后swap不加载的情况，执行sudo /etc/init.d/cryptdisks reload 后 重新加载 sudo swapon -a 即可。 今天20161224，看了下系统文件大概是20160101凌晨装的系统，大概就是2015末2016初吧，整整一年，把guestOS从一台电脑挪到另一台电脑后，今天才发现swap问题，并于今天内解决 参考： Ubuntu官方bug贴953875和1310058： https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/ https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22 以及： http://askubuntu.com/questions/462775/swap-not-working-on-clean-14-04-install-using-encrypted-home http://askubuntu.com/questions/462739/14-04-with-fde-and-swap-is-missing 后记： 刚才重新运行了一会，发现sudo init 6重启后OK，但sudo init 0后开机就挂载不了swap，/var/log/boot.log中出现： device-mapper: rename ioctl on cryptswap1_unformatted failed: Device or resource busy 手动sudo /etc/init.d/cryptdisks reload 后 sudo swapon -a 又能挂载，不想折腾了，也没必要加密了，于是直接不用加密了，参考： https://www.logilab.org/blogentry/29155 https://webcache.googleusercontent.com/search?q=cache%3awww.logilab.org/blogentry/29155&hl=en&tbo=d&strip=1 （启用加密用 sudo ecryptfs-setup-swap ）其中的描述： sudo swapoff -a sudo cryptsetup remove /dev/mapper/cryptswap1 sudo vim /etc/crypttab *remove the /dev/sda5 line* sudo /sbin/mkswap /dev/sda5 sudo swapon /dev/sda5 sudo vim /etc/fstab *replace /dev/mapper/cryptswap1 with /dev/sda5* 至于cryptdisks开机启动就不管了，没精力，也没必要，耗不了多少资源，而且万一以后要用呢 后记2（20161225）： /etc/crypttab 里面直接用#注释掉就可以了，也可以删除行 刚发现/etc/rc2.d/和/etc/rc5.d/是一样的，执行runlevel显示是2，在/etc/rc2.d/里面没有cryptdisks而/etc/rc6.d/里面有S59cryptdisks-early，说明关机后启动系统进入runlevel 2是没有运行cryptdisks的，所以/dev/mapper/cryptswap1没法正常加载，而如果重启则是进入runlevel 6，有执行S59cryptdisks-early，所以能正常加载/dev/mapper/cryptswap1，swap正常挂载。 小结一下： 如果不需要磁盘加密（不运行cryptdisks），/etc/fstab里直接 UUID=**** none swap sw 0 0 或 /dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0 并注释掉其余swap项； 如果有磁盘加密（运行cryptdisks），/etc/fstab里 /dev/mapper/cryptswap1 none swap sw 0 0 并注释掉其余swap项，同时保证开机启动项/etc/rc*.d/里面cryptdisks正常启动，而且cryptdisks配置正常：/etc/crypttab里面UUID正确而且行末加“,offset=8”避免前几个写有UUID的地方被写覆盖；如果cryptdisks异常则执行sudo /etc/init.d/cryptdisks reload 后 重新加载 sudo swapon -a 磁盘加密或不加密两种情况下如有修改系统文件则执行sudo update-initramfs -u更新一下 后记20170212： 修改/etc/fstab后重新加载生效的命令是mount -a即挂载所有，umount -a是卸载所有

Linux安装MySQL遇到的问题

Linux(Ubuntu 14.04 VMware虚拟机，host为win7 64 SP1)安装MySQL，sudo apt-get install mysql-server，安装MySQL server且自带client，接下来想将datadir更改为host的一个单独的ntfs分区中，问题来了： 参考：http://blog.fens.me/linux-mysql-install/，虽然可更改配置文件/etc/mysql/my.cnf指定datadir的位置，但这里只是一处，使用中还会有其他地方的配置也需要做相应修改，于是做一个软链接到目标目录“sudo ln -s 目标 /var/lib/mysql”，同时修改/etc/apparmor.d/tunables/alias添加“alias /var/lib/mysql/ -> 目标目录”,重启apparmor：“sudo /etc/init.d/apparmor restart”，重启MySQL，起不来，查看“/var/log/mysql/error.log”，其中出现：“[ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.”以及“[ERROR] Fatal error: Can't open and lock privilege tables: Table 'host' is read only”，于是尝试修改目标目录及其中文件的属性，发现ntfs挂载后还不能改，于是修改/etc/fstab，目录的dmask和文件的fmask分别改为000和111，用户uid和组gid也修改为MySQL对应的编号（通过id mysql查询），重新挂载后问题依旧，而且不管是改为目标盘的子目录还是直接改为使用目标盘根目录，都一样，此外还尝试修改过apparmor配置“/etc/apparmor.d/usr.sbin.mysqld”，添加"目标目录 r,"和"目标目录/** rwk,"，重启apparmor依旧，“sudo /etc/init.d/apparmor stop”（此命令仅清除apparmor缓存）、“sudo /etc/init.d/apparmor teardown”（暂停apparmor），问题依旧，放弃做软链接的方法，尝试更改/etc/mysql/my.cnf中的datadir也不行，总是提示同样的error，尝试重新安装db到指定目录：“sudo mysql_install_db --user=mysql --datadir=目标目录”提示没修改权限，“sudo mysql_install_db --user=mysql --datadir=/var/lib/mysql/”倒是可以，删了原来复制过去的目录，重新复制/var/lib/mysql/也一样，最后想到一个办法，就让ntfs直接挂载在/var/lib/mysql/，复制mysql目录下的所有文件"sudo cp -rf /var/lib/mysql.bak/. /var/lib/mysql"，注意mysql.bak后面的点，如果没有就直接复制目录到/var/lib/mysql如果有就是复制目录里面的内容到/var/lib/mysql，打开apparmor，启动MySQL，终于OK。

安装NetIQ Chariot client Endpoint(IxChariot Endpoint)遇到的问题

NetIQ和Ixia是两家企业，Chariot 是NetIQ的一款测试网络的产品，Ixia成为这款产品的reseller，产品名为IxChariot。 Chariot分为console和client，client也叫Endpoint，console分发script到client控制client执行测试，console和client可以是不同的设备，例如console在A，两个client分别在B和C。 win7 64 SP1安装endpoint时，第一次使用NetIQ Chariot 5.4文件包里的client安装程序，总是提示: Error 1920. Service Ixia Performance Endpoint(IxiaEndpoint) failed to start. Verify that you have sufficient privileges to start system services. 尝试管理员权限执行、XP兼容模式，照样不行，网上搜了下，找到了Ixia的一份pdf文档，里面说是没有安装qWAVE(Quality Windows Audio/Video Experience)导致，且给出了win2008里面具体的方法：控制面板里面打开Windows功能-qWAVE，我在win7里面没看到对应选项，反而是在services.msc里面看到了Quality Windows Audio Video Experience服务，开启之后再次安装endpoint提示依旧，放弃；使用另一个ENDPOINT4.5简易版.exe，绿色软件，出现进程，无界面，另外还下载了一个IxChariot 7.10 SP3 Endpoint安装后有进程，命令行运行endpoint提示“The Windows Endpoint can only be run as a service”，实际上，client（即endpoint）只需要有一个进程存在即可，操作、管理，全在console完成，不幸的是console在win7 64 SP1安装后，选择script时总是错误，提示pwinlist->locateoraddelementwithkey本该为true实际为false，点进去看有错误码CHR0117，尝试换了script路径、管理员权限、更换安装路径，都试过也不行，安装到winXP虚拟机里面可正常运行，目前console只支持win，而endpoint支持各种平台，包括虚拟机

VMware Workstation环境下Ubuntu磁盘性能

hostOS为win7 64，安装VMware Workstation，guestOS为Ubuntu 14.04 64，除了默认磁盘外，还挂载了hostOS的同一物理磁盘（所有分区均为NTFS）下的一个分区，平时使用时，根据经验反而是虚拟机原有虚拟磁盘性能优于虚拟机挂载的裸磁盘。由于准备在虚拟机中安装数据库，于是仔细比较了一下双方性能，运行hdparm，显示双方读性能几乎一致，裸磁盘稍稍逊一筹；使用dd测试读取性能，双方差不多；使用dd测试写性能，虚拟磁盘性能优于裸磁盘，但加上参数oflag=dsync（使dd操作接近数据库写操作）后，虚拟磁盘性能非常差，而裸磁盘保持，所以结果反而是裸磁盘性能比虚拟磁盘性能好很多。针对即将安装的数据库，最终选择挂载裸磁盘。

在win7laptop上装rhel和Ubuntu

2014-06-14 在一个已装有win7的laptop上想装一个rhel和一个Ubuntu Server，laptop没有光驱，没有grub，CPU架构64位，准备装64位系统。 相对来说，Ubuntu的安装手段要更convenient，既有LiveCD（曾经免费邮寄了一张livecd 8.04 LTS），也有U盘启动盘制作工具（Ubuntu有个工具为http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/）。这两种方法都试过，可以正常进入安装程序，但我偏偏想先装rhel6.5，于是重新下载了rhel-server-6.5-x86_64-boot.iso，用UltraISO写进U盘，想从U盘启动引导rhel-server-6.5-x86_64-dvd.iso，但停在一个说是要按enter的地方不动了，网上搜了不少，也试过多个类似的U盘启动盘制作工具，都不行，于是最后找来官方文档Red Hat Enterprise Linux 6 Installation Guide--Installing Red Hat Enterprise Linux 6 for all architectures，仔细研究，使用dd命令（dd if=*source* of=*dest*）将ISO写进U盘（此时U盘就等于这个ISO，没有其他用处了，插进win系统提示格式化），第一次直接用rhel-server-6.5-x86_64-dvd.iso可是这个方法居然不支持这个laptop，只好将rhel-server-6.5-x86_64-boot.iso写进U盘，能引导，但就是找不到rhel-server-6.5-x86_64-dvd.iso，仔细研读手册后发现这种引导方式还只支持FAT不支持NTFS的，只好把rhel-server-6.5-x86_64-dvd.iso放进另一个FAT32格式的U盘，并且同目录下要有images目录，目录里面要有install.img和product.img，product.img可选，而且不能有其他文件！限制真多！这样rhel就顺利装上去了；下一步装Ubuntu，之前的U盘dd之后怎么都无法作为引导盘了，格式化、工具软件，都不行，最后只能再dd一次，终于可以了。

XP下两个不同用户同时登录的实现

1、下载经过修改的TermSrv.dll(比较流行的是2055这个版本)，在安全模式下，注意：是安全模式！下覆盖下面两个文件（覆盖前做好备份）：
C:\Windows\system32\TermSrv.DLL，C:\Windows\system32\dllcache\TermSrv.DLL。

如果提示拒绝，需要到服务中停掉terminal***这个和终端服务相关的服务（必须禁止后重启，不能直接停），再覆盖
2、正常登陆Windows XP，如果系统的文件保护功能提示TermSrv.DLL文件被修改，问是否要复原，选择否。
3、运行内容为以下命令的bat文件，或者自行修改注册表相关键值：

@echo off
setlocal
set regkey="HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core"
reg add %regkey% /v EnableConcurrentSessions /T REG_DWORD /D 1 /f
endlocal
对应注册表项为：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\Licensing Core，在该键下新建一个名为“EnableConcurrentSessions”的DWORD值，并设置该值的数据为1。
4、在Windows XP用户帐户管理中启用了“欢迎屏幕”、“快速用户切换”功能。

经过这4步后，重启即可三个用户同时登录（网上说两个，但本人实验是可以三个同时的），而且可以三个同时远程登录，SP2，SP3都可以，但必须是不同用户

除此之外，windows下同一或不同用户多次登录的终极解决办法是“WinConnect Server XP”，破解版支持21用户。但本人在虚拟机中实验失败，相关的betwin terminal服务启动不了。

最后，vnc在Windows下的VNCServer支持同一用户多次登录（如果开机就开启服务则登录之前就可以用vnc连上去），但几个窗口看到的是同一桌面，不能不同用户同时登录（连用户名都没有的选择），所以两个人共用XP不能考虑vnc。

另外在linux下，tsclient这个rdp客户端，实际支持rfb（vnc所用协议）/rdp（terminal server所用协议）等多个协议。使用rdp协议时，它的后台是rdesktop，实际上可以在命令行里直接用rdesktop。rdesktop有一个参数-0，表示直接登录一台机的console。

VMware的host和guest之间通信的尝试

VMware的guest和host之间的通信方式有三种：
bridged、NAT、host-only

第一个，桥接，实质上是让网卡进入混杂模式，同时监听两个IP，对应的物理网卡没有连接起来时，guest里的网卡是搜寻不到网络地址的，会有一个含有感叹号的黄色小三角，只有外面的host的网卡连上后，里面的guest的网卡才能连上，而且里面的虚拟网卡在外面网卡的连接状态改变后，反应没那么快。连接上后，相互都可以ping通。
在VMware里面可以配置桥接的目标是哪个网卡。

第二个，NAT，VMware提供一个NAT服务器，host的网络连接中出现的虚拟网卡VMnet8相当于连到内网的网卡，地址比如说是192.168.48.1，NAT服务器也是网关的地址为192.168.48.2，guest都和它交互，它们互相可以ping通。但192.168.48.1ping不通192.168.4.2。这些IP都接到一个虚拟交换机上

第三个，host-only，NAT实质上是它的一种特殊情况，一个提供了NAT服务器和DHCP服务的host-only。host-only提供一个虚拟的交换机，所有网卡连接到上面。所有虚拟网卡都可以和VMnet1交互，相互可以ping通。如果需要连接到外网，可以手动将VMnet1和物理网卡打通，最简单的在XP中共享网卡即可。

三种方式都可以使host和guest相互通信，bridged需要物理网卡连通才行（比如，只需要连到一个不能连通外网的路由器上即可），NAT和host-only在没有网络环境的情况下就可以

三者都可以使虚拟机和外网连接，bridged需要增加一个能连外网的IP即可，NAT只要主机能连就行，host-only和NAT类似但需要手动配置NAT服务或者共享网络连接

bridged连外网，实质只是让物理网卡进入混杂模式，同时监听多个IP
而NAT和host-only都是虚拟出一个网卡，虚拟机通过这个网卡来和外网交互，当然这个虚拟网卡需要和物理网卡桥接起来，NAT自动完成，host-only需要手动设置

bridged符合习惯，只要像主机一样配置
NAT方便，不需要其他设置，主机能上网虚拟机就能
host-only很灵活，可以自己组网做实验



下面是刚碰到的问题：
1. 笔记本两个网卡，默认的桥接是自动选择的，两个网卡都被选中，自己可以选择桥接到有线网卡还是无线网卡上
2. 虚拟机中的网卡总是电缆被拔出的状态，有个红叉，搞了半天发现是虚拟机中VMware Tools中网卡的勾没有勾上，这个也可以在VMware右下角的小图标上单击选中
3. 虚拟机XP中对ping是否回显的设置（防火墙中设置）默认是不回显的，搞了半天最后发现是这个原因，导致里面ping得通外面，但外面ping不通里面

读《An Overview of Virtual Machine Architectures》[1]

这篇文章主要介绍了虚拟机的概念，分类，起源，以及必要性。

早期的计算机是这样设计的：硬件首先被设计出来，软件是专门针对相应硬件而设计的。每个系统都有着自己的指令集，而软件则针对这个特殊的指令集设计。这些软件包括操作系统，汇编程序（以及后来的编译程序），还有应用程序。只需要一个小用户社区，相对简单的程序，和固定的硬件。但当用户群体扩大时，操作系统变得越来越复杂，应用程序也迅速增加，于是为每一个新的计算机系统重写和发布软件都成为一个艰巨的任务。

于是软件兼容性和可移植性的必要性显得格外重要。与此同时，各个计算机公司的硬件设计者也趋向于体现一定共同的硬件特征。新的设计往往与以往的设计类似。直到20世纪60年代初的IBM360家族，充分的软件兼容性被充分的认识并被明确的提出。IBM360系列有许多模型，覆盖了大范围的硬件资源，因此提供了不同性能和价格层次，而这些机器可以运行同样的软件。

为了达到这一点，软硬件间的接口必须被严格的定义与控制，系统指令集（ISA Instruction Set Architecture）的概念被提出。

除此之外，操作系统被设计为可以对应用程序屏蔽硬件异构性。操作系统负责管理硬件资源，保护正在运行的应用程序和用户数据，支持控制共享，并提供其他有用的功能。由于应用程序对操作系统提供的服务有很强的依赖性，这些操作系统服务和操作系统接口也变为标准化中重要的一个环节。到今天为止，仅有少量的标准操作系统。此外，操作系统不再彼此独立的工作，他们通过计算机网络负责资源和数据的共享。

为使软件与硬件匹配而设计的标准化接口使大规模复杂的和各种各样的软件系统能被开发出来。正是这些标准化接口，软件才能更灵活而且有更好的可移植性。然而，这还并不能称得上完美，因为有一些不同的，互不兼容的ISA和操作系统，因此软件可移植性受到这个软件开发平台的限制。用户程序被限制到一个特定的指令集和一个特定的操作系统。简言之，软件只能运行在一个特定类型的物理机器上。

虚拟机（VM Virtual Machine）可以解决这一物理机限制并提供更大限度的可移植性和灵活性。虚拟机是这样实施的，在一个执行平台上增加一层软件让他被上层软件看来完全是另外一个甚至是几个不同平台.虚拟机可以运行那些运行在相应物理机上OS或ISA之外的OS或ISA.

处理器,内存,I/O设备,网络资源都可以被虚拟化.当一个处理器或系统的状态处于虚拟化时,它实质上与一块特定的物理硬件分离.这意味着一个虚拟程序或系统能暂时与特定的物理资源关联起来,而这种关联能被实时的改变.

虚拟化技术能增强系统安全性,提升系统性能,简化软件迁移,并使基于网络的与平台无关软件成为可能.

传统的计算机系统体系结构有许多优点.主要的系统设计工作分离开来,硬件设计者和软件设计者可以相对独立的工作.事实上,,硬件,OS,应用程序这3个主要组成部分通常都由不同的公司在不同时间(甚至是相隔数年)开发.应用程序开发者不需要弄清楚OS内部的变化,硬件和软件能根据不同的进度被升级.软件能在具有相同ISA的不同硬件平台上运行.正因为这种体系架构所具有的优点使它持续存在了几十年,并吸引了大量投入.

然而,传统体系架构也有一些明显缺点.随着软硬件变得越来越复杂,计算机应用程序越来越多样化,这些缺点显得越来越突出.



主要部件仅在彼此恰好搭配时才正常工作.不同系统的部件不具备互操作的能力.为一个特定ISA编译的应用软件不能在一个有着不同ISA的硬件上运行.在一个严重依赖网络的环境中,这个问题变得更加突出.把一组用网线连接起来的计算机视为一个单一系统,而软件能在计算机件自由迁移,这样做有极大的好处.而传统计算机系统体系结构限制了这种灵活性.

第二个问题就是计算机系统更新或升级常常受到底层接口的限制,因为软件层需要支持那些已经被开发出几年甚至是几十年的底层接口.例如,一个新的软件概念的提出可能会受到一个老的"祖传的"ISA的限制.硬件开发可能也会由于要支持以前的ISA而受到限制,一些高性能的革新也会受到限制.而且,即使ISA经过扩展,支持新的革新(实际情况也常常如此),他们同时也必须支持老的ISA,而这些老ISA又很少用到,成为冗余的包袱.

第三个问题就是跨接口(软硬件间)的优化很难实现.软硬件开发者一般在不同公司,而且一般在不同时间,彼此很少交流,所以让他们合作跨越接口来对系统进行优化是一件很难的事情.例如,应用软件和硬件的独立开发意味着程序二进制代码并非为某个特定的硬件而作优化.通常只有一个版本的二进制代码被发布,它很有可能就只为一个处理器模型作了优化(如果它做过优化的话).此外,编译器的开发常常滞后于处理器的开发,所以相应二进制代码常常针对一个早期版本处理器作优化,而不是针对它们正在运行的处理器.

最后,在一个传统计算机系统中,一个操作系统与一个硬件平台匹配,所有应用程序都在单一OS的管理与保护下共存.这不仅使所有用户都被限制在同一OS下,而且因为系统软件的共享使OS存在一些安全问题.

在计算机系统中,对于不同层面的抽象,看到的"机器"也不同.从"进程"(process)的角度,机器包括一个已经分配给进程的内存地址空间,一些用户级寄存器,以及能使该进程执行自己代码的那些指令.I/O系统对于进程来说是很抽象的东西.磁盘和其他辅存就是一些能被它们访问的文件的集合.在桌面环境中,进程通过GUI中的窗口与用户交互.而进程与I/O系统交互的唯一方式是操作系统调用,不管是直接还是通过提供给进程的库.

而从一个更高层次来看,底层"机器"支持着一整个"系统"(system).一个系统是一个能同时支持属于不同用户的进程的完全的执行环境.所有进程共享同一文件系统和其他I/O资源.系统环境持续存在,其间不断有进程产生和消亡.系统分配物理内存和I/O资源给进程,使进程通过OS与属于它们的资源交互.

正如一个"机器"的概念可以从进程角度看也可以从系统角度看,虚拟机也可以有进程级别和系统级别的.正如其字面意思,一个进程虚拟机能支持单个进程.它随进程的产生而产生,随进程的终止而终止.例如,Intel x86PC运行Linux,其上通过Java虚拟机运行Java进程.Java虚拟机环境能通过Java库执行Java字节码程序并进行I/O操作.同样的系统也可以通过能对PowerPC指令进行仿真的进程级虚拟机来支持PowerPC/Linux应用程序.所有这些进程都能同时存在于同一系统环境中,彼此之间可以交互.例如一个PowerPC进程能生成一个x86进程并通过共享内存与之通信.如果是在一个桌面系统中,它们都由各自的独立窗口,并在同一X-windows的GUI中出现.

一个系统级的虚拟机提供一个完备的系统环境.这个环境支持多用户进程,包括一个文件系统,为进程提供I/O设备访问权限,而且对于桌面,它支持GUI.

对于实现虚拟机来说,有两种重要的标准化接口,它们大致对应了进程级虚拟化和系统级虚拟化.首先是ISA,包括用户和系统指令.用户指令可提供给应用程序和OS;系统指令包括特权操作,这些特权操作允许直接操作,分配,和观察读取(observation)共享的硬件资源(处理器,内存,I/O).

另一种是应用程序二进制接口(ABI, Application Binary Interface).ABI也有两个主要组成部分.第一个是所有用户指令组成的集合(系统指令并不属于ABI),第二个是系统调用接口.在ABI层面上,所有的应用程序通过系统调用接口调用OS来与共享的硬件资源间接的进行交互.




进程VM






进程级VM为用户应用程序提供一个虚拟的ABI环境,包括复制(replication),仿真(emulation),和优化(optimization).

多道程序设计(multiprogramming)

第一种也是最常见的VM,它是如此普遍以至于我们甚至没有认为它属于虚拟机.传统的多道程序设计为每个用户进程提供这样一个假象:自己拥有一整个属于自己的机器.每个进程都有一个属于自己的地址空间,并有权访问一个文件结构.OS使硬件被分时复用,并管理底层硬件资源.事实上,OS为每一个并发执行的应用程序提供被复制的进程级虚拟机.而且,这种进程的数量几乎不受限制:进程虚拟机可以被自由的复制.

仿真和动态二进制翻译(emulation and dynamic binary translators)



对进程级虚拟机提供来说,一个更具有挑战性的问题是让在一个指令集机器上编译的程序能运行于另一个不同指令集机器之上.应用程序针对一个源ISA被编译,但在另一个不同的目标ISA上被执行.由于是不同的ISA,所以需要虚拟机对源ISA的执行进行仿真.最直接的仿真的方法就是解释(interpretation).一个解释程序执行目标ISA的取指,译码,并模拟源指令的执行.这是一个相对缓慢的过程,一条源指令对应大量的当地指令(native instruction).

需要更好性能的话,二进制翻译是一种选择.在二进制翻译过程中,源指令块被转化为有等价功能的当地指令.翻译的过程可能会有相对较大的开销,但一旦一个指令块被翻译,就能被缓存起来并被复用,这整个过程要比解释快得多.因为二进制翻译常被用于进程VM,所以它们常被叫做动态二进制翻译.

解释和二进制翻译有着不同的性能特征.解释的启动开销较小,但当一条指令被仿真时会消耗大量时间.另一方面,二进制翻译有较大的初始化开销,但对每一个重复执行来说很快.结果,一些虚拟机借助剖析手段采用了分阶段仿真模型.起初,一块源指令被解释,同时用剖析手段来决定哪些指令序列经常被用到.然后,一个经常被用到的块被翻译.一些系统更进了一步,采用了代码优化措施:如果剖析表明某个块经常被用到,就对其进行优化.在大多数仿真虚拟机中,解释和翻译在单个程序整个运行过程中都出现.

动态优化(dynamic optimizers)

大多数动态翻译器都不仅仅把源代码翻译成目标代码,而且作一些优化工作.一个动态优化器在一个正在运行的程序上可以进行一些统计,例如建一个剖析文档(profile),然后用这些剖析信息来实时的对二进制代码进行优化.

高级别VM:完全独立于平台



对于以上描述的VM,跨平台的可移植性显然是一个很重要的目标.但仿真的方法有很大开销.相比之下,高级语言VM环境要更优.

传统系统的与平台无关代码的发布是这样一个过程:首先由编译器前端把高级语言程序转化为中间码,接着由编译器后端把中间码转化为针对特定系统的目标代码.这时目标文件就可以发布了.

对于高级语言虚拟机环境来说,过程有所不同.首先由编译器把高级语言程序编译为可移植代码.这时可移植代码就可以被发布了.然后由虚拟机执行可移植代码.

高级VM的优点在于只要VM能在目标平台上运行软件就能被彻底移植.尽管这会有些复杂,但比起为每个平台开发一个编译器并对每一高级语言应用程序进行重编译要简单得多,同时比起传统的进程VM要简单得多.

系统虚拟机(system virtual machines)



系统VM提供一个完备的系统环境,多个进程,甚至是属于多用户的不同进程可以共享.在20世纪60年代和70年代初,虚拟机的概念被提出.

在经典VM模型中,VMM置于硬件层之上,虚拟机在最上面.VMM运行在最高特权模式.VMM能以完全透明的方式截获并执行所有guest OS与硬件交互的行为.

系统VM的另一种实现方式把虚拟化软件置于一个已有的OS之上,它能利用下面的OS提供的设备驱动和其它底层服务.但这样做会损失一些性能.




全系统VM:仿真

在以上描述的"经典"系统VM中,所有OS和应用都必须和底层硬件的ISA保持一致.但在有些重要场景下,OS及应用同硬件的ISA不能保持一致,这样就导致了用仿真方式实现的系统VM的出现.透明被称作"全系统"(whole system)VM,因为把所有软件都虚拟化了.最常见的实现方法就是把VMM和软件置于运行在物理硬件上的传统OS之上.由于不易利用底层系统ISA特性(如虚拟内存管理和陷阱截取),所以仿真会受到很大限制,此外,如果host和guest硬件特性有很大不同,那么会出现很多问题.



1. http://www.cse.psu.edu/~bhuvan/teaching/spring06/papers/overview.pdf

读《3D Benchmarking - Understanding Frame Rate Scores》[1]

这篇文章主要介绍了一些3D benchmarking的基础知识，例如帧率，填充率等等。

平台对3D性能的影响

首先是平台对3D性能的影响。这里的平台指的是带有芯片组的主板，内存，处理器，PCI或AGP插槽等这些部件组成的整体。平台先对图像进行一些处理，再将计算过后的图像的顶点和纹理通过PCI或AGP传送给显卡。平台的速度越快，单位时间内传送给显卡的帧数据就越多，如果平台不够快，就会让显卡闲着，帧率降低。

对平台来说，各种图像分辨率都一样，原因很简单：平台把顶点传送给3D芯片，顶点之间的相对坐标并没有因为图像分辨率的改变而改变。此外，系统对色彩深度也不感冒，内存和总线带宽对这个确实有一定影响，但对当今大多数3D benchmark来说，这些因素是可以忽略不计的。

如果平台是系统的瓶颈的话，不同分辨率和不同色彩深度对3D benchmark的影响微乎其微。因为3D芯片始终等着平台传送过来的3D数据。在这种情况下一个更好更快的3D芯片并不能使帧率提高。

填充率带来的影响

接下来是填充率对整体性能造成的影响。填充率是指在单位时间内被渲染的像素数（帧率被定义为在单位时间内被显示的帧的数量）。对于同样的帧率，更高分辨率比较低分辨率需要更好的渲染性能。现在的3D芯片都有几个渲染管道，能同时并行的工作。一个渲染管道通常能在一个时钟周期内渲染一个像素。最大像素填充率＝3D芯片时钟频率*渲染管道数*3D卡内的3D芯片数。

当平台性能足够好时，瓶颈转移到显卡上，这时帧率随着图像分辨率的提高而下降。

32位色彩的图像和16位色彩的图像对于系统来说几乎是一样的，因为对系统来说渲染32位色彩的图像和渲染16位色彩的图像几乎完全一样，一个像素渲染时间完全一样，所以只要瓶颈是在纯的帧填充率上，16位色和32位色的帧率是一样的。

内存带宽的巨大影响

在以前显存带宽并不存在问题，但进入新千年以来，显存带宽也成为一个瓶颈。显卡对显存带宽有很高要求。首先是在帧缓冲区，每处理一个像素，渲染单元都要访问帧缓冲区几次。接下来是Z缓冲区，它的访问极其频繁以至于Intel在其集成显卡i810中专门加入了显示高速缓存（display cache）。然后是纹理缓存，对每一个像素，它也要被访问多次。T&L-unit（T&L单元？）也要耗带宽，至少有一个小小的影响。最后是RAMDAC（随机存储器数模转换器），他读取前端帧缓存并把图像显示到屏幕上。更高分辨率和更高刷新率都会使RAMDAC更频繁的访问帧缓存。

显存是如此被频繁访问以至于随着分辨率提高或色彩深度提高，内存带宽对帧率的影响越来越大。

小结

在较低分辨率时，平台的性能是整个系统瓶颈，显卡一直在等待CPU传送过来的3D数据，而在高分辨率时，存储器带宽的限制使填充率不会很高。总之，要在高分辨率情况下得到高的帧率，要么就提高存储器带宽，要么减小对存储器带宽的依赖。

1. 3D Benchmarking - Understanding Frame Rate Scores. http://www.tomshardware.com/reviews/3d-benchmarking,205.html

读《Virtualization in Linux: A Review of Four Software Choices》[1]

作者比较了四种可以在Ubuntu Linux下运行的虚拟化产品：免费且开源的x86仿真器Qemu；闭源但免费的Virtual Box和VMware-Server；商业化产品Parallels Workstation。

除了Virtual Box，其他三个都可以在Ubuntu的源上找到，也就是说可以用sudo apt-get install命令安装。

至于界面，Virtual Box和Parallels使用QT写的，而且Virtual Box的界面最干净，最适合于新手。总的来说，Qemu的界面友好程度最差。

在性能比较上，VMware Server和Virtual Box持平，Qemu次之，最差的是Parallels，可笑的是，Parallels是这4款虚拟化产品中唯一的收费产品。

比起VMware Server，Virtual Box在最大最小化窗口和激发透明效果时有些闪动，但并不影响用户使用；此外Virtual Box是这4款虚拟化产品中唯一一款能设置显存（Video Memory）大小的虚拟化产品。对于Qemu，文中作者没有在guest Os中使之发出声音。

最后结论是，如果对于一般用户推荐Virtual Box，对于其他用户可以考虑一下VMware Server，因为Virtual Box是一个轻量级的虚拟化产品，它要比VMware Server小的多，没有那些对用户来说并不需要的多余功能和属性。

1. Virtualization in Linux: A Review of Four Software Choices. http://www.techthrob.com/tech/linux_virtualization.php

读《An Introduction to Virtualization》[1]

主要介绍了虚拟化技术以及一些已有的虚拟机产品。文章结构大致如下：虚拟化发展历史，虚拟化定义，虚拟化带来的好处，虚拟化实现技术，仿真和模拟，最后是很多虚拟化产品。

广义上，网格技术和PVM也属于虚拟化技术，所以虚拟化技术并不是一般所认为的把多个单 位的某种计算机资源整合成一个有机整体的技术，而是根据用户对计算机资源的需求，把底层的物理资源的异构性屏蔽掉，让上层用户感觉不到底层异构性，满足用户使用计算机资源的实际需求。

文中列出了一大堆虚拟化技术的必要性，比如安全，负载均衡，资源分配灵活等等等等一大堆。

IBM的逻辑分区（LPAR, Logical Partitioning）和动态逻辑分区（DLPAR, Dynamic Logical Partitioning）只能针对IBM的操作系统或Linux操作系统；除此之外，IBM还有z/VM。

Sun的虚拟化产品有Shade（与华盛顿大学西雅图分校合作研究），以及在Solaris上用到的一些技术：静态分区（Static Partitioning），动态分区（Dynamic System Domains），容器（Solaris Containers）等。

HP的HP-UX虚拟分区（VPAR, Virtual Partitions）。

FreeBSD的jail技术。

微软的Virtual Server和Virtual PC（由被微软收购的Connectix开发）

此外，还有程序语言级别的虚拟机，UCSD P-System上的UCSD PASCAL语言（在上世纪70年代和80年代初）；JVM；微软的 .NET CLI。

TCP/IP协议栈的虚拟化：有些应用场景下并不需要对整个操作系统进行虚拟化，而只是对TCP/IP协议栈进行虚拟化，相互间彼此隔离的TCP/IP协议栈既可以在内核中提供，也可以作为用户进程运行。

1. An Introduction to Virtualization. Amit Singh. http://www.kernelthread.com./publications/virtualization/

读《Adaptive Display Algorithm for Interactive Frame Rates During Visualization of Complex Virtual Environments》[1]

作者针对复杂虚拟环境虚拟化中的交互式帧率提出了一个适应性显示算法。算法基于一个层次模型表示法，能在不同细节层次上来描述目标物体，而且能够用各种不同的渲染算法来绘图。算法背后的思想就是适应性地调整图像质量，以维持一个固定的用户自定义的目标帧率。作者做了约束性优化来为每一个有可能可见的物体选择细节的层次和渲染算法，目的是为了在目标成帧时间之内产生“最好” 的图像。其他已有的细节省略算法在对复杂模型的虚拟化中有着几乎难以察觉的图像质量差异，而测试结果表明该算法比起这些算法有着更稳定的帧率。

作者用到了如下两个公式：

(1)

(2)

第一个公式是前提条件，第二个是需要求其做大化值的。（1）中在层次L下用R算法对物体O进行渲染所需代价是Cost（O,L,R），所有物体所需渲染代价值和要小于目标成帧时间TargetFramTime；收益Benefit(O,L,R)表示在层次L下用算法R对物体O渲染的收益，所有物体的收益之和要尽可能的大。

Cost的定义是一些启发式的规则，Benefit也是。具体地说，Cost定义如下：

(3)

作者假设每个像素所需时间与像素和物体个数成比例，Cost取C1Poly(O,L)+C2Vert(O,L)与C3Pix(O)中的较大者。C1，C2，C3对一个固定的渲染算法和机器来说是常量。Poly(O,L)代表多边形物体O在层次L上所需时间，Vert(O,L)表示顶点O在层次L上所需时间。

对于收益Benefit，定义如下:

(4)

其中，
(5)

收益就是目标物体大小，精确度，重要性因子等因素之间的乘积。而精确度定义为1-Error。

文中主要借鉴了贪心算法，选择的值最小的情况。为了维持一个用户自定义的稳定的帧率，该算法会动态调整图像质量，选择所需的细节层次以及一个合适的算法来渲染每一个潜在可视的物体并在目标成帧时间内生成“最好”的图像。

[1] T. A. Funkhouser and C. H. Sequin. Adaptive display algorithm for interactive frame rates during visualization of complex virtual environments. Computer Graphics, 27(Annual Conference Series): 247–254, 1993.

读《Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines》[1]

当今操作系统支持各种各样的大量类型的设备，在操作系统中大部分代码都是与设备驱动相关的。新的操作系统尝试两种方法来减少设备驱动代码的量和复杂程度。一种是想办法尽量精简已有的设备驱动模块，另一种是对不同驱动模块尽量重用。本文作者提出了一种驱动程序复用技术，该技术无需修改驱动程序，更重要的是，这种实现方式增强了新操作系统实例相对于被重用驱动的独立性，而驱动程序的相对独立性又增强了系统的可靠性。

二进制驱动程序的重用已经由cohosting实现，就像VMware Workstation所做的一样，作者受启发发明了该方法。这种方法对原有设备驱动进行完全重用，并有着很强的隔离性。这种方法并没有整合驱动代码，而是让所有驱动程序留在它们原有的完全兼容的运行环境，原有的操作系统中。被包在原有操作系统中的设备驱动运行在一个专用的VM中，这样就几乎能保证语义受到保护，而且不兼容性也仅限于由VM复用而导致的时钟行为。现在，作者已经能够成功重用大量的网络、磁盘、和PCI设备驱动。

这种方法有较好的性能：对于网络，吞吐率仍然只占原系统的3-8%；每一个额外增加的虚拟机仅仅只增加0.12%的CPU利用率；驱动间的隔离需要额外CPU开销，而这可以通过硬件加速来降低，例如用直接DMA处理进站的包。

新的OS和被重用驱动间的接口组成了极少量的代码，比起旧的驱动程序代码要少多了。

这篇文章主要对虚拟机驱动部分作了优化，使驱动程序重用性提高，同时提高了虚拟机算系统的可靠性，使整个系统的性能有所提高。

参考文献

1. J. LeVasseur, V. Uhlig, J. Stoess, and S. Gotz. Unmodified device driver reuse and improved system dependability via virtual machines. In Proceedings of the 6th Symposium on Operating Systems Design and Implementation, San Francisco, CA, Dec. 2004.

读《Blink: 3D Display Multiplexing for Virtualized Applications》[1]

这篇文章主要介绍了作者研究的针对虚拟化应用的3D显示的多路复用技术。他们开发了一个虚拟机的显示系统：Blink。该系统比传统的C/S模式所需的上下文切换次数要少，能消除冗余的图像缓存的复制与清空。同时Blink也比直接使用物理显卡的设备更安全。

Blink不允许客户端直接操作物理的网卡设备，而是给每个客户端一个虚拟处理器VP（Virtual Processor），客户端可以对它进行编程。最后Blink用JIT编译技术和对VP程序的简单静态分析，把它们进行复合。

为了减小开销，Blink使用了Blink存储过程。与运行在GPU上的显示列表不同，一个Blink存储过程就是一个运行在显示服务端CPU上的BlinkGL程序。存储过程就是一系列OpenGL命令，每条命令都包括一个操作码和一个参数集。Blink服务端包括一个JIT（Just In Time）编译器，这个即时编译器的作用就是把BlinkGL转换为CPU机器码。这一过程很快，因为BlinkGL很简单。

用OpenGL来共享显示器有这样一个坏处：针对每一个更新，整个显示器上的图像都要重画。而Blink可以在一定程度上避免这个问题：每一个客户端只能对屏幕的一个子区域进行操作，在规定的区域之外，客户端是无法进行操作的。这样就可以在原来的基础上对系统性能进行提升。

Blink运行在Xen之上。Blink server端运行在Domain0上，它直接操作物理显卡，Blink server实质上是一个普通的OpenGL应用程序；Blink客户端运行在Domain U上，由Blink server上的BlinkGL复用器合成。

相应的性能测试表明，在同样的性能下Blink能支持更多的VM，而在同样的条件下Blink的性能明显好。

最后得出的结论是虚拟机间好的隔离性并非一定要牺牲图形图像处理性能。用JIT编译技术和共享内存协议，服务端和客户端的通信开销减少了。最后让多个应用程序在同一个屏幕上显示而不需要off-screen缓冲区。

参考文献

1. J. G. Hansen. Blink: 3d display multiplexing for virtualized applications. Technical Report 06/06, DIKU – University of Copenhagen, Jan. 2006. http://www.diku.dk/jacobg/pubs/blink-techreport.pdf.

读《I/O Virtualization Using Mellanox InfiniBand And Channel I/O Virtualization (CIOV) Technology》[1]

这篇文章就是Mellanox公司给它的InfiniBand做的一个介绍，和GbE（Gigabit Ethernet）与FC（Fibre Channel）作了比较，阐述了InfiniBand的好处。

Mellanox公司的InfiniBand针对的是服务器虚拟化领域。服务器的虚拟化有以下几点好处：

1. 增加服务器利用率。可以按需动态把应用程序分配到物理机上。

2. 减少宕机时间，增加可靠性。不健康的物理机服务器可以很容易的在不影响运行在之上的服务的情况下关机维护。这可以通过物理机间的无缝迁移实现。而当服务器修好后，又可以把虚拟机迁移回来。

3. 动态资源分配和负载均衡。按负载需要，可以把新增物理资源动态分配给正在运行的VM，或者开启新的VM。同样，也可以把VM迁移到新的资源相对更多的物理机上。

4. 面向服务的体系结构。以上的几个特性，使得服务器资源的分配可以纯粹的根据应用程序和用户的服务需要进行。

现在，IO虚拟化有3中途径。

1. 全虚拟的，基于软件的IO虚拟化。

2. native IO虚拟化：结合了基于软件的虚拟化和基于硬件的虚拟化。

3. 旁路（pass-through），基于硬件的IO虚拟化。

基于软件的IO虚拟化如图所示。VMM在这种情况下作为VM和物理IO适配器间的桥梁。这样有好处也有坏处。

可以增强对老软件的兼容性和VM及应用程序的稳定性。迁移时间少宕机时间。更高的服务器利用率。但这样也限制了运行在服务器上VM的数量，同时伴随着更小的IO带宽和更大的IO延迟。

用Mellanox的InfiniBand用CIOV（Channel I/O Virtualization）技术能用于基于软件的IO虚拟化，这样不仅可以有软件虚拟化有点，而且可以让网络和存储域网络共享适配器，一个适配器还可以被共享为多个物理适配器。

CIOV用更小的开销实现了更好的性能。文章接着列举了两种方案证实他的观点。

native IO虚拟化解决方案

VM和物理IO适配器间传递的数据绕开了VMM，但控制路径和内存映射功能仍由VMM控制。

IO数据通路的性能有了很大提高；IO数据通路延迟有了很大降低；CPU利用率比软件IO虚拟化时要好得多，一个物理机能支持更多的虚拟机。缺点是，每个VM有了一个新的驱动栈，需对VM中的应用作重新优化；迁移时需要重启VM，动态负载平衡和减少的宕机时间，所带来的便利没有了；

Mellanox的CIOV对VMM层和VM层都有好处：由于绕开了VMM，VMM中不需要嵌入虚拟交换机的功能。

接着又用一个案例说明了CIOV用更小的开销实现了更好的性能。

旁路硬件IO虚拟化

完全绕开了VMM，不需要VMM干预。

InfiniBand同GbE和FC比较有很大优势，单位适配器网络吞吐率、单位适配器SAN吞吐率、购买价格、维护费用、IO功率消耗、兼容性、管理透明性等方面都要强于GbE和FC。InfiniBand与GbE间，与FC间都可以实现互操作，这更增加了InfiniBand的适用面。

[1] http://www.zdnet.com.au/whitepaper/0,2000063328,22445637p-16001293q,00.htm