在与Fengqi.Asia（风起云）的潜在客户接触时，经常被问到如下问题：
我在之前的博客里介绍过SmartOS（这里，转载）。这里再说一下。首先SmartOS是基于illumos的。Illumos是从OpenSolaris继承而来的开源产品，而OpenSolaris又是基于Sun的Solaris 10操作系统而来的。所以SmartOS并不是运行于任何一个操作系统之上的应用系统，它本身就是操作系统。在Fengqi.Asia（风起云）和Joyent，我们把它当成是一个hypervisor，在上面运行Linux、Windows、FreeBSD和在KVM上的虚拟机。KVM是Joyent从Linux里剥离出来移植到SmartOS上的（参考链接）。
此外，SmartOS支持操作系统虚拟化，虚拟出SmartMachine。和KVM类似，一个SmartMachine看上去就是一个完整的机器，有自己的硬件（存储、网络和处理器）和操作系统以及库文件等。和KVM不同的是，没有格外的虚拟化层。这意味着不同的SmartMachine在同一硬件上共用操作系统（SmartOS）。
那为什么要推荐使用SmartMachine或SmartOS，而不是Linux呢？
从high level的角度来看，主要有以下几个原因：
我们来逐个细看。以下不仅适用于虚拟机，也适用于裸机。
一般来说，提到性能，我们在乎的多数是网络和存储的延迟、吞吐量，处理器的利用率等等。Brendan博客有一个关于SmartMachie、KVM、Xen的性能讨论文章（Virtualization Performance: Zones, KVM, Xen），我也翻译了一下（链接）。对于一般的计算，SmartOS和Linux区别不大，也许在任务调度方式上有些不同。
在网络方面，SmartOS使用了一个核心机制，叫做crossbow。除了提供虚拟的网络设备，相比Linux虚拟机，crossbow在SmartMachine上提供了更好的吞吐和延迟，也不会有网络抖动，从而有更好的传输效果，比如减少了重传。每个SmartMachine可以设置多达32个VNIC。有兴趣的可以看看这些文章：Solaris Crossbow实践指南（一）：VNIC和网卡复用，Solaris Crossbow实践指南（二）：虚拟网络和etherstub ，作者使用VNIC和Zone创建了一个新的HTTP服务器而没有添加新的硬件，采用VNIC技术提高了网络设备的利用率和复用性。而且crossbow还能在一个没有网络连接的系统中，采用etherstub和VNIC创建一个虚拟的网络环境，即能很方便地在一个物理主机上建立一个趋近于真实的并且“与世隔绝”的网络环境。还有这篇文章：如何使用 Oracle Solaris 11 网络虚拟化和资源管理限制应用程序流量，了解了如何用crossbow技术对数据链路和用户定义的流应用带宽限制进行网络流量管理，如何限制通过数据链路的所有流量，应用于流的带宽限制可以基于网络数据包的特征。这些技术可以单独使用，也可以组合使用，从而可以创建灵活的受控环境以满足网络资源管理的所有需要。这些文章都是几年前的，可见那时crossbow已经将网络虚拟化做得很好了。
就虚拟化而言，当运行SmartMachine时，进行网络I/O的代码路径和裸机运行SmartOS本身一样。在SmartOS的KVM里运行Linux和Windows时，使用crossbow做底层，还需要在虚拟机的操作系统网络代码中运行额外的代码，从而增加了额外的开销。同样道理，SmartMachine直接在SmartOS上进行磁盘I/O操作，但Linux和Windows需要在guest OS里运行额外的代码进行磁盘I/O。
就文件系统，SmartOS使用了ZFS，每个SmartMachine运行自己的ZFS数据集，每个Linux/Windows虚拟机有自己的ZFS卷。ZFS使用了Adjustable Replacement Cache (ARC)算法，在缓存文件系统数据或元数据方面做得非常好。这个视频（需要翻墙，by Brendan Gregg）详细地叙述了ZFS的性能。
这可以算是使用SmartOS的最主要的原因，特别对技术人员而言。可观测性是指工程师能看到程序、库文件及操作系统到底在做什么，即从应用到硬件中的整个软件栈活动都能被看到。这样做可以帮助调试或排错，定位并解决性能的问题。
传统进行debug和性能分析时，工程师会添加一些代码到程序中，比如通过调试器、输出语句或其他方式。有时这种做法并不容易知道问题所在，有时还需要重新编译代码或者重启程序/系统，有时可能添加的代码还会带来更多的潜在问题等等。
在这个方面，SmartOS提供了一个工具叫做DTrace。DTrace可以让你在任意时刻看到整个软件栈的情况，完全不需要添加额外的代码或工具在你的程序中。DTrace在生产环境下都是很安全的，也不需要重新编译或重启任何东西。此外，还有USE方法可以帮你定位你想跟踪的东西，Brendan Gregg写了篇文章专门介绍他的Utilization Saturation and Errors (USE) Method（链接1，链接2），有兴趣的朋友可以看看。注意USE方法可以用于任何系统：“It directs the construction of a checklist, which for server analysis can be used for quickly identifying resource bottlenecks or errors.”
DTrace机制可以用于：
DTrace肯定会用到Linux中（Github上的DTrace on Linux），不过用到生产环境中还需时日。
SmartOS间接地来自于Solaris，而后者一直以来在可靠和安全方面都广受好评。此外，ZFS校验和可保证数据不受损坏，使用写时复制（copy-on-write）机制确保活跃数据不会被被覆盖。ZFS文件系统有良好的一致性，自从2006年就被用于生产环境，易于管理。最近还被用于大数据方面。
除了ZFS和DTrace，SmartOS还使用了zones（zone是SmartOS的虚拟化后的实例。A zone is a virtualized instance of SmartOS that behaves like an isolated system even when functioning along side other zones on the same machine）。 Zones被用在SmartMachines和Linux/Windows虚拟机中。每个SmartMachine和Linux/Windows虚拟机都在自己的zone中运行。在一个zone中运行的进程没有权限访问运行在其他zone中的进程。每个zone被赋予了一个ZFS数据集或卷用于存储。运行KVM实例在他们的zone中意味着万一一个虚拟机有问题，它会在zone中解决，不会对其他租户（zone）带来任何的影响。 每个zone通过crossbow都有自己的虚拟网络栈，与其他zone的网络栈完全隔离，即你无法嗅探其他zone中的网络包。在一个zone中的设备不会被其他zone访问到。
资源分配和管理对于每个zone而言也是受控的。资源受控意味着一个zone内可以控制能使用多少内存，多少CPU，多少网络带宽等。此外，还有调整磁盘I/O优先级的机制（disk I/O throttling），也就是说一个zone不会在存在磁盘带宽竞争的情况下用尽网络带宽。SmartOS提供两种方式用于控制CPU消耗：第一种方式是，设置CPU下限。Fair share scheduler调度器允许管理员设置一个最低的必须保证的CPU资源。在系统被多个zone索取资源时，调度器发挥作用，保证每个zone获得公平的资源分配。当系统没那么繁忙时，一个zone可以“爆发”超过资源限制，直到达到为其设定的CPU资源上限。第二种方式是，设置CPU上限（CPU cap），比如有多少CPU时间可以分配给一个付费用户。这个可以用于管理用户对系统性能的期望值，即使在资源和负载都很低的情况下也可以这么做。
SmartOS中有一个用于管理服务的机制叫做Service Management Facility (SMF)。SMF是替代其他系统中的/etc/init.d脚本的。当然你还是可以使用/etc/init.d脚本，只是SMF给了你更细粒度的管理选择。还有一个机制叫Fault management (FMA)，具体就不解释了，给一句英文做参考吧： "fine-grained fault isolation and restart where possible of any component — hardware or software — that experiences a problem. The diagnosis system is used to trigger targeted automated responses or guided human intervention that mitigates a specific problem or at least prevents it from getting worse."
当然。对于很多人来说，正是因为对Linux熟悉，所以学习SmartOS的陡峭学习曲线会成为一道不小的障碍。但是毕竟SmartOS和Linux都是基于Unix的系统，两者是有区别但也没有到很难上手的级别。你可以看看这篇文章“SmartOS 与 Linux 不同点总结（Cheat Sheet ）”（源自The Linux-to-SmartOS Cheat Sheet）
还有就是，Linux有很多厂商驱动支持，很多软件可用。其实大多数写给Linux的软件都能用于SmartOS，移植的困难程度取决于软件有多少专属于Linux的代码在其中。就可移植性来说，如果程序员想要做到这点，在Linux、SmartOS以及FreeBSD上都进行测试是最低要求。