Vm on Shell's Home

利用cgroups隔离多个进程资源消耗的尝试

Wed, 19 Feb 2014 10:14:23 +0800

setup

Add to /etc/fstab.

cgroup                  /sys/fs/cgroup  cgroup  defaults        0       2

Then sudo mount -a.

Change directory to /sys/fs/cgroup/. Use mkdir to create a new group, and initalize it like those.

echo 0-3 >> cpuset.cpus
echo 0 > cpuset.mems

Without those two step, next operator will failure.

echo 0 > memory.swappiness
echo 52428800 > memory.limit_in_bytes

Set memory limit 50M, and forbidden swap.

python test code

import os, sys, time, random, string
def main():
    l = []
    random.seed()
    raw_input()
    for i in xrange(1000000):
        for j in xrange(1000):
            t = list(string.letters)
            random.shuffle(t)
            s = ''.join(t)
            l.append(s)
        time.sleep(0.01)

if __name__ == '__main__': main()

Finally, it triggered OOM.

lxc和virtualbox和物理机的简单性能测试和对比

Thu, 23 Jan 2014 11:04:34 +0800

说明

测试各种虚拟化系统下的虚拟机性能。

测试使用sysbench。

CPU采用如下指令测试。

sysbench --test=cpu --num-threads=2 --cpu-max-prime=50000 run

文件IO采用如下指令测试。

sysbench --test=fileio --file-total-size=10G prepare
sysbench --test=fileio --file-total-size=10G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run

内存采用如下指令测试。

sysbench --test=memory --num-threads=2 --memory-access-mode=seq run
sysbench --test=memory --num-threads=2 --memory-access-mode=rnd run

线程采用如下指令。

sysbench --test=threads --num-threads=2 run
sysbench --test=mutex --num-threads=2 --mutex-locks=1000000 run

裸硬盘测试采用如下指令。

hdparm -tT <dev>

物理机上有三个文件系统，ext4/xfs/btrfs，前两者仅做fileio测试以对比性能。

另外做两个特殊文件系统对比，aufs带复制和aufs无复制。前者在只读层上准备好测试文件，而后进行随机读写测试。其中就附带了文件复制开销。后者在aufs建立后初始化测试文件，因此消除了文件复制开销。

所有测试都是测试数次，取最高者（因为低者可能受到各种干扰）。一般是2-3次。

物理机是一台DELL Intel 64位桌面系统，支持硬件虚拟化，有4G内存。系统采用debian jessie，测试于2014年1月17日-20日执行，内核3.12.6-2 (2013-12-29) x86_64。

虚拟机lxc是使用lxc切分的一台虚拟机，没有做资源限制。

虚拟机vbox是使用virtualbox切分的一台虚拟机，分配了所有CPU，打开了硬件虚拟化，分配了1G内存。

文件系统

ext4

Operations performed: 21311 Read, 14207 Write, 45440 Other = 80958 Total Read 332.98Mb Written 221.98Mb Total transferred 554.97Mb (1.8499Mb/sec) 118.39 Requests/sec executed

lxc简单介绍

Thu, 02 Jan 2014 12:48:17 +0800

基本安装

安装lxc包。

注意修改/bin/sh，链接到/bin/bash。lxc在某些版本上有一个bug，声明为/bin/sh却使用bash语法，导致不如此链接会出现错误。

lxc on debian wiki

镜像和设定

使用lxc-create -n name -t template生成镜像。

在/usr/share/lxc/templates可以看到可用的模板。

在/var/cache/lxc/debian会缓存生成过程的临时文件。

生成的镜像需要在镜像内安装lxc，否则无法使用lxc-execute。

资源限制

在config文件内，写入cgroup限定规则。注意，使用内存限定的话，需要在内核参数中加入cgroup_enable=memory。

在debian下，可以修改/etc/default/grub文件，使用update-grub重新生成规则。

GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory quiet"

在config文件中可以如下限定。

lxc.cgroup.memory.limit_in_bytes = 512M # 限定内存
lxc.cgroup.cpuset.cpus = 0 # 限定可以使用的核
lxc.cgroup.blkio.throttle.read_bps_device = 8:0 100 # 读取速率限定
lxc.cgroup.blkio.throttle.write_bps_device = 8:0 100 # 写入速率限定
lxc.cgroup.blkio.throttle.read_iops_device = 8:0 100 # 读取频率限定
lxc.cgroup.blkio.throttle.write_iops_device = 8:0 100 # 写入频率限定

执行

lxc-start -n name /bin/echo hello

还可以用以下指令，在已经启动的container里执行进程。

lxc路由模式

Fri, 24 May 2013 09:25:36 +0800

为什么使用路由模式

lxc默认使用的是桥模式，这也是我在家里和公司里部署的模式。在这种模式下，lxc虚拟机可以直接和真实网络中的机器互相访问，就如同一台真的机器一样。路由模式则没有这个便利性。

但是桥模式有个缺陷，必须能够做出桥来。我们有做不出桥来的时候么？有，如果你用笔记本，大部分AP会拒绝第二个MAC地址的包。导致网桥可以组建，却永远无法正常使用。

第一种路由模式，双重NAT简版

双重NAT可以用于几乎所有场景，并且不会带来后遗症。然而，双重NAT的问题在于，物理网络不能直接访问虚拟机。对于很多设备来说，这就失去了价值。另外说一点，之所以叫做双重NAT，是因为多数时候物理网络接到外网还需要一次NAT。

lxc的双重NAT可以视为两步，建立NAT连接的虚拟网络，将lxc连接到虚拟网络。

第一步比较复杂，我们先从br0的建立开始说起。首先，你需要为虚拟网络分配一个不同的保留内网网段。如果使用同样的内网网段，在ARP查询的时候会从一个端口发出超过一个的MAC回应，这就退回了桥模式。

然后我们需要建立一个br0网桥作为配置的起点，对这个网桥赋予IP，配置路由和防火墙，并启动dnsmasq以便于dhcp和dns。这个模式之所以叫做简版，是因为我们先不讨论dnsmasq。

假如你的lxc内网网段是192.168.66.0/24，那么你大致可以如下配置：

brctl addbr br0
ifconfig br0 192.168.66.1
route add -net 192.168.66.0/24 dev br0
iptables -A INPUT -s 192.168.66.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.66.0/24 -j MASQUERADE

实际上，对于任何一种网口设备，将其配置为NAT的过程都是一样的。

第二步非常容易，在lxc的config文件内，指定网桥为br0就OK了。当然，作为略去dnsmasq的代价，你需要手工配置每台机器的IP地址和DNS服务器。

第二种路由模式，双重NAT

双重NAT的完整版需要在内网网口上启动dns，作为dns缓存代理和dhcp服务器。其余和第一种模式没有区别，只是你不需要手工指定IP和DNS服务器了。

当然，其实任何一种网口的NAT配置都是一样的。

第三种路由模式，双边交互路由

第三种路由模式的效果最好，虚拟机和真实机可以互相访问。但是这种模式需要能够修改物理网络网关的路由表。这种模式使用主机作为路由器，中转真实网络和虚拟网络。

我略去如何创造br以及如何将lxc连接到上面，这些前面有叙述。下面我简述一下双边路由最关键的几点。

最重要的重点，就是在真实网络的网关上，将你的真实物理机在外网的IP，配置为虚拟网络的下一跳网关。例如，对于上面的例子，我们应当在网关上如此配置。

route add -net 192.168.66.0/24 gw 192.168.1.4

如果不进行如此配置，物理网络所发出的包在到达网关后就不知道应当如何转发了。

在物理机上允许双边网络的所有包透过。你的包当然不能被防火墙挡掉。
虚拟网络的dhcp是不会传递到外网的，因此如果打算使用dhcp，还是需要开dnsmasq。

家庭电脑的虚拟化

Fri, 31 Aug 2012 16:39:38 +0800

家庭电脑，谁都会用。会来看我blog的人更应当是家里有一台，我知道有些还有不止一台的——别人家我不知道，我家里就算老妈和丈母娘一起来打游戏，我还能保证我和老婆人手一台的水平。

一堆机器，有好处也有坏处。好处是，基本坏掉哪台都不怕，备用的比较多，随便来一台就能跑。坏处是，这些机器的配置不同，习惯不同，性能也不同。我们家里更特殊的情况是——连系统还不一样。我自己用的是linux，老婆是win7，老妈是XP。

为了解决文件共享的问题，我采用了NAS，而且是自己组装的小型服务器。对于小型家庭网络，NAS是个很不错的主意。然而电脑不仅仅有文件而已，还有配置呢。老婆的win7是直接连接到电视上的，所以我经常需要和她抢电脑。然而chromium的绑定gmail只能有一个——用我的还是她的就是一个问题，这是两个人用一台电脑的配置共享问题。同时，我的小上网本则是另一个极端。我希望上网本上和主机能共享同一个配置，虽然chromium的同步能力很强，但是很多东西不是chromium能同步的掉的。包括emacs配置，bookmark，打开文件。ssh密钥，系统环境。这是另一个问题，一个人用两台电脑的共享配置。当然，说到这里同时还有一个问题，我不希望用自己的小上网本，毕竟atom的速度和主机没法比，io速度也慢，内存也少。

所以，我最终的解决方案就是——虚拟化。在win7中装一台虚拟机，里面跑一个linux，再通过上网本远程控制这台linux，这样至少解决了我自己的问题。在小上网本上，可以高速的使用浏览器，和主机同一个配置。在主机上，和老婆分开配置。在老婆使用电脑的时候，和她分离的，不受干扰的使用电脑。

实际上，要解决这个问题，最好的方案是基于linux的multiseat系统。由于是multiseat，所以我和老婆同时使用。由于linux是用户分离的系统，所以可以互不干扰。唯一的遗憾是，同一个用户不能同时登录两个X，Xauthority文件会互相覆盖，因此在用户登录的情况下不能使用vnc。

当然，为什么不能用multiseat，你们懂。。。不懂的可以看我上一篇文章。

kvm虚拟化的性能对比

Mon, 19 Mar 2012 07:09:38 +0800

废话不多说，4G的机器，debian testing，amd64内核32位环境。用kvm切出一个768m的机器，debian testing，64位内核64位环境。对比起来有点不公平，不过基本说明问题。

用lmbench对比两者的性能，报告我就不贴了。基本结论如下：

1.纯计算: kvm内比真机还快，或者至少性能相当。估计是32位环境的关系。

2.syscall, read, write, select: 都是kvm快。

3.Protection fault,AF_UNIX sock stream latency,fork+exit,fork+execve: 真机比kvm快至少4倍，最多可达6倍。

4.文件读写api: 真机比kvm快3倍以上。

5.socket性能: pipe是kvm快，unix file是真机快。

6.iozone: 两者吞吐性能几乎一致，有时kvm比真机还快。可能和真机的ext3上面堆满碎片结构有关。

基本结论，kvm在计算和io上都没什么太大问题，主要问题在于各种涉及ring0指令的内核调用方面（好像这也是虚拟化的通病）。在虚拟化系统中，尽量避免大量的内核调用，尽量减少碎片调用，增大IO块。

有一种错误，叫做太常见了以至于视而不见

Mon, 20 Feb 2012 06:19:51 +0800

最近整XEN，出了一个奇怪的错误。

ERROR (SrvDaemon:355) Exception starting xend((22, 'Invalid argument'))
Traceback
(most recent call last):
File "/usr/lib/xen-4.0/lib/python/xen/xend/server/SrvDaemon.py", line 335, in run
xinfo = xc.xeninfo()
Error: (22, 'Invalid argument')

根据网络上的内容，首先排除没有xen模块——有了，然后是/proc/xen目录是否mount——有了，然后是/sys/hypervisor/下面的一堆属性——有了，然后是版本——不对。xen-utils-4.1是4.1.2版本，而xen-tools是4.2版本。不过xen-utils并不依赖xen-tools，没有后者应当也可以运行这些玩意。hypervisor和xen-utils的版本是一致的。那问题是什么？

出错的文件是/usr/lib/xen-4.1/lib/python/xen/lowlevel/xc.so里面发生的异常，下载xen的源码检查，这个函数主要是检查属性。属性检查会出什么错？

正在一头雾水的时候，突然想起一个问题。我安装的是xen-hypervisor-4.1-amd64，因为kernel是linux-image-3.1.0-1-amd64。然而，我这个系统有一个非常大的特殊——在64位CPU上运行的32位系统。因此，实际上xen-utils是32位的。行了行了，下面的事情用膝盖都能想到。

叹气，这世界上，真的有种错误，叫做太常见了以至于视而不见。不要认为自己不会犯。

简易debian livecd打造手册

Thu, 16 Feb 2012 01:10:21 +0800

废话不说，上干货。先装一下syslinux，genisoimage，kvm，debootstrap，squashfs-tools。

$ mkdir debcd
$ cd debcd
$ mkdir isoroot
$ cp/usr/lib/syslinux/isolinux.bin isoroot/
$cat > isoroot/isolinux.cfg << "EOF"
prompt 0
default linux
label linux
kernel vmlinuz
append initrd=initrd.img
EOF
$ cp /boot/vmlinuz-3.2.0-1-amd64 isoroot/vmlinuz

完成上述步骤后，你就准备好了一个基础的iso镜像文件系统，并有了一个基础的引导模块和内核。现在，我们尝试把这玩意烧到iso上，并且测试一下。

$genisoimage -o output.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table isoroot/
$ sudo kvm -cdrom output.iso -m 512

如果没法装kvm，换成qemu。屏幕会停在内核引导过程中——因为你没有initrd.img，所以在isolinux.cfg中指定的initrd就不正确。下面我们会设法弄一个initrd.img。

$ cp -a /etc/initramfs-tools/ initramfs
$ mkinitramfs -d initramfs -o isoroot/initrd.img
$genisoimage -o output.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table isoroot/
$ sudo kvm -cdrom output.iso -m 512

现在看看？你应该能看到有initrd被加载上去了，但是很可惜，没有root，因此也无法启动。所以下一步，我们需要弄一个root。

论同时的双系统－－准虚拟对双系统的进一步扩充

Mon, 12 Jan 2009 01:04:00 +0800

熟悉贝壳的人都知道，贝壳是个linux爱用者，不过因为工作关系，经常要使用windows。贝壳在自己的笔记本上使用了linux/windows混合双系统，并通过共用磁盘的方式共享数据，解决这个问题。但是长期的使用表明，这种解决方案存在几个巨大的瑕疵。首先是系统切换时间常，因此长期在一个系统中工作，而很少触及另外一个系统。其次是稳定性差，windows下一旦崩溃，进入linux后就需要检测数据盘，80G的数据慢慢扫描，感觉晕到死。那么是否有一种方案，能够同时使用两个工作级系统（注意，不是实验级，贝壳成功的在windows下的vmware里跑了一个oracle，这个可以说是实验级的典范。然而工作级系统的要求和实验级完全不同）。

从系统发展史的角度来说，我们可以预见，将来的系统将是脱离硬件的。首要的原因就是和硬件不相匹配的各个层级的计算能力需求。现在系统发展有两个极端，一个是虚拟机，试图将一个硬件整体分离，运行多个系统。另一个是高性能集群，试图将多个硬件合并，运行一个系统。从根本上说，这是因为高性价比的硬件集中在了一个性能区间，而实际的性能需求却是完全分离的，因此我们才会出现如此两类完全背离的需求。而现在有大量宝贵的人力浪费在了系统和硬件结合，系统稳定性问题上，这无疑是对将来发展的一个巨大瓶颈。虽然无法预知将来的技术发展会以何种方式解决这个问题，然而可以预见的是，解决硬件和性能的背离将是人类计算机发展史上一个重要的里程碑，解决这个问题的人必定会在计算机历史上留下重重的一笔。

同时，更进一步，贝壳揣测，将来的解决方案将是系统硬件调度/驱动和系统软件管理分离。一个软系统拥有一个用户表和一个硬件表，硬件表上写他可能有10个键盘，两个显示器，或者一堆其他设备。系统借助某个可信方案，管理了一系列虚拟抽象设备和真实设备形成的映射。作为系统层以上的软件，我们只要关心如何操作这个虚拟设备即可。而实际上，我们可以通过管理参数和对应关系实现各种需要。例如我们可以将多个机器的硬件管理核心加入一个系统，形成集群。或者我们可以在一个机器的硬件管理核心上加入多个系统，形成虚拟机。这个基本是分布系统的观点。如此一来，系统层软件就无法得知也无需得知自己是在到底运行在什么环境下。只是这个系统设计方案对高性能要求的子系统（主要是显卡）相当不利。

从揣测回到现实，为了实现一个工作级系统（幸好，还不是工业级），我们需要为系统制定一些评判标准，以判别各个方案的优劣。我们首先能想到的评判标准就是速度，一个慢吞吞的系统解决方案是没有任何实用价值的。当然，这个速度是有差异的，可能是linux快一些，windows慢一些，或者相反。我们假定实际的需要是windows快一些，因为linux可以通过定制进行加速。

我们的第二个评判标准就是稳定性，经常会崩溃的系统不比慢吞吞的系统好到哪里去，甚至会更加让人讨厌。虽然工作级系统并没有工业级那样高的要求，然而高负荷稳定，宕机平均频率低于3天/次还是要保证的。而后我们还希望两个系统可以做到数据互通，即两个系统间的数据尽可能的共享，至少要做到文件和邮件的共享。最后，我们希望解决方案简单易用，便于实施和维护。

而后，我们列出了一个原始方案，和以下几个改进解决方案，并给出优劣评价，谨供大家参考借鉴。同时我们在其中还补充了一些无法实际解决问题的虚拟化解决方案，并且说明无法使用的原因，供适合的人自行选用。

原始方案，windows+linux+数据分区。此种方案是最中规中矩的，性能最高的方案。具有对硬件最好的支持，最容易的维护。如果需要运行游戏（尤其是魔兽，WOW），这也是唯一可行的工作级方案。稳定性评价属于尚可，主要由于ntfs在linux的稳定性并不好，ext3在windows需要使用非官方驱动，和某些（就是avast）驱动不兼容。数据互通比较方便，通过数据分区可以轻松的共享文件和邮件。

windows虚拟方案，vmware+虚拟分区。这种方案是改进方案中唯一可以跑游戏的，因为虚拟机随时可以关上。性能上满足windows快 linux慢的要求，虚拟系统显示性能良好，也可以通过文件共享部分的解决数据共享问题（文件共享方便，邮件共享困难）。稳定性很好，基本没有什么不稳定的问题出现，操作和维护都不困难。然而之所以一开始这种方案就被排除在外，主要是因为这种方案无法让linux驱动实体硬件，无法通过机器启动。这样也许对一些跑起来玩玩的人或者是内核工程师/测试员比较有用，然而如果要在linux里面进行大量工作，编译程序，运行服务，这种方案就力有未逮。因此这个方案可以说是一个实验级方案，而非工作级。

windows虚拟方案，vmware+实体硬盘。速度一般，windows快linux慢，基本和上面一个方案一样，唯一的区别就是linux也可以被实际驱动。然而这也成了整个方案的最大败笔，因为linux的驱动灵活性不如windows，因此无法经受这种系统切换的动作。举例来说，真实的机器上，硬盘是sata的，作为sda识别和使用。而虚拟机上则是IDE的，被识别成了hda。于是启动环境一变，就需要修改大量配置来调和这个问题。又例如，在真实机器上，X使用fglrx驱动，而虚拟机下面要用mesa。如果我在/etc/xorg.conf中不指定驱动，那么真实机器的驱动也会变成 mesa，导致性能下降。如果指定驱动，又会导致虚拟机内X无法运行。诸如此类的问题林林总总，需要大量细节修正，因此维护复杂，稳定性差，不建议正式使用。在贝壳机器上更严重的，出现了虚拟机内和虚拟机外争抢数据分区的状况，这种情况下数据分区实质是被当做盘阵用了。使用非专用的磁盘作为底层共享存储，并在上面运行ext3系统，这是及其危险和愚蠢的。

linux虚拟方案，xen。速度超快，但是上来就在贝壳的机器上暴出几个问题，因而没有继续测试。首先是安装xen后x无法启动，出现fglrx驱动无法加载的状况。其次是xen要求使用虚拟盘启动，可贝壳经常需要跑到windows下面打游戏。因此在简单测试后被剔除出局。感觉这种方案的最大问题在于配置管理太过复杂，debian下面已经很轻松了，只需要安装对应内核，使用工具建立虚拟机，但是依旧感觉麻烦到一塌糊涂。相信这种方案在专业级服务器领域应当有不俗表现。

linux虚拟方案，openvz。这种方案压根就不适合贝壳的状况，因为这个虚拟方案要求宿主和客户必须是同一CPU同一系统（不要求同一linux发行）。主要用于希望将一个主机切分成多个独立的同构主机，以达到分离管理的目的（例如业务服务器和数据库服务器分离）。需要做大型网络管理/虚拟主机业务的人可能会对这个虚拟方案感兴趣。

linux虚拟方案，vmware。速度一般，linux快windows慢，视频效果不错。vmware毕竟是商业公司，视频驱动挺齐全的。但是内核驱动的编译麻烦到死，首先是要求编译器版本和主内核编译器版本一致，于是贝壳去搞了个gcc-4.1，然后连接了上去。下面又是内核头定义出现版本差异，搞到现在还没有搞定。谁能搞的定的给个参考，最好是debian上的解决方案。

linux虚拟方案，kvm。这个是贝壳目前使用的方案，基本比较理想。速度很快，和xen基本差不多，显示速度不如vmware（理论上说装好显卡驱动应该会好点，不过贝壳找不到CLDC5446的XP驱动，那是Win32和Win95时代的显卡）。linux快windows慢，但是还在可忍受范围内。稳定性很好，只要测试通过，运行中到目前为止没有死机（当然很多参数是加了之后开机即死机）。数据可以通过samba互通，邮件也同样可以互通。然而使用samba无疑复杂很多，而且性能并不太好。只是从稳定性上说，让linux自己去驱动ext3总比半吊子的windows驱动更好，同时也不会出现争抢的问题。易用性上还算可以，无论是内核编译还是系统使用都不太难，最大的麻烦就是网络配置。根据贝壳的测试，在真实机器上superpi运行100W 位需要45秒，虚拟机内需要54-60秒，尤其在换用kvm-72.2后反而更慢了（54下降到60，折合真实机器83.3％下降到75％）。

总体来说，贝壳更倾向于使用全开源的准-全虚拟解决方案kvm，主要因为他简便易行，对系统影响小，不改变现有系统。同时性能高，稳定性好。主要需要解决显卡效率问题。如果以上问题无法彻底解决，贝壳打算换用linux下的vmware，想办法搞定他的内核模块。

Linux下的模拟器

Wed, 27 Jun 2007 18:25:39 +0800

模拟器是一个很模糊的概念，究竟什么是模拟器？这个问题可能对于诸多玩友并不困难，但是对于程序员却是很难界定。什么是模拟器，bochs算吗？wine算吗？POSIX子系统算吗？OS/360算吗？

下面所定义的模拟器是至少具备以下几个特征的。

1.模拟目标机的CPU。按照这个特征，wine就被剔除出模拟器的范畴。这种东西其实最好规划在模拟子系统中(虚拟机)，这类软件是以本地CPU真实运行为基础特征的。如果这样被算入模拟器，那Windows算不算？

2.模拟目标机的硬件响应。这个特性其实说了和没说一样的。

限于贝壳接触的限制，目前我们的目标系统仅仅涵盖以下几种机器。GB/GBA NES/SNES(FC/SFC) NeoGeo MD 街机

PS。这几种机器相信应该没有人不知道吧。其中FC就是中国风靡一时的红白机。

我们来看看对应的模拟器。注意以下全是Linux系统下的模拟器，FreeBSD之类的需要进一步测试。

gngb

只能用于GB，GBA无法模拟。

gnuboy

和gngb看不出什么区别。

Visual Boy advance

至少从名字上知道能模拟GBA，不过我没有用，下面会说原因。

fceu

FC模拟器，非常好用的东西，有Windows版。除了吞食天地2外还没有模拟不出来的东西(贝壳语：为什么是我喜欢的吞食天地啊～～～)。不过贝壳一样没用，下面有原因。

mednafen

万能的救世主，最全能的模拟器(Linux下)。支持GB/GBA NES NeoGeo涵盖除了MD外的大多数系统，开源而且方便好用，具备Win32版本。不过吞食天地2一样模拟不出来。(贝壳：为什么～～～)

mopher

严格来说这不是Linux模拟器，而是WinCE的。不过鉴于一样是偏门系统，贝壳就顺便介绍以下好了，是GB/GBA

NES/SNES MD的全能模拟器。

dgen

唯一的，也是最好的MD模拟器，可惜在AMD64系统上运行不大正常。

mame

就是Windows下超强模拟器mame的Linux版本，唯一能够模拟街机的模拟器。发布版本超多，支持Windows,

Mac, Linux, Xbox(贝壳：?!), CE(贝壳：??!!),

Nokia9210(贝壳：???!!!)。简直是模拟器族啊——！

pcsx

PS模拟器，其实是PS2啦。支持Windows, Linux,

DreamCast(表问贝壳最后一个是啥东东)。如果你没有超级强劲的CPU就想都别想。

X GL SDL问题

这三者都是图形界面接口。一般来说，Xv是2D最快的，GL是3D最快的。所以能用X的不用SDL，能用SDL的不用GL，跑3D没的商量。

建议大家安装一个mednafen的X版本，一个mame的X版本。不是AMD64的装一个dgen，CPU够劲的装一个pcsx。基本上面的机器都能模拟了