OSv 最初是由 Cloudius Systems（现在的 ScyllaDB）设计和实现的，但目前它由一个小型志愿者社区维护和增强。如果您热衷于系统编程或者想要学习并帮助我们改进 OSv，那么请在OSv Google Group 论坛上与我们联系 ，或者随时为新人提出任何好的问题。有关如何格式化和发送补丁的详细信息，请阅读 此 wiki （我们也接受拉取请求）。
OSv 是一种开源多功能模块化Unikernel，旨在作为虚拟机管理程序之上的 microVM 安全地运行单个未经修改的 Linux 应用程序，与为各种物理机设计的传统操作系统相比。从头开始构建，可轻松部署和管理微服务和无服务器应用程序，并具有卓越的性能。
OSv 被设计为按原样运行未修改的 x86-64 和 aarch64 Linux 二进制文件，这实际上使其成为Linux 二进制兼容的 unikernel （有关 Linux ABI 兼容性的更多详细信息，请阅读 此文档）。特别是，OSv 可以运行许多托管语言运行时，包括 JVM、 Python、 Node.JS、 Ruby、Erlang以及构建在这些运行时之上的应用程序。它还可以运行用直接编译为本机机器代码（如 C、C++、 Golang 和Rust）的语言编写的应用程序 ，以及GraalVM 和WebAssembly/Wasmer生成的本机映像。
OSv 在 Firecracker 上的启动速度可快至约5 毫秒，使用低至 11 MB 的内存。OSv 可以在许多虚拟机管理程序上运行，包括 QEMU/KVM、 Firecracker、 Cloud Hypervisor、Xen、VMWare、 VirtualBox和 Hyperkit 以及 AWS EC2、GCE 和 OpenStack 等开放云。
有关 OSv 的更多信息，请参阅wiki 主页 和http://osv.io/。
为了在 OSv 上运行应用程序，需要通过将 OSv 内核和应用程序文件融合在一起来构建映像。从高层次来看，这可以通过两种方式实现：
- 通过使用位于的 shell 脚本
./scripts/build从源代码构建内核并将其与应用程序文件融合，或者 - 通过使用capstan 工具，该工具使用预构建的内核并将其与应用程序文件组合以生成最终映像。
如果您的目的是尝试以尽可能最少的努力在 OSv 上运行您的应用程序，那么您应该采用绞盘
路线。有关介绍，请阅读本
速成课程。有关绞盘的更多详细信息，请阅读此更详细的文档。预构建的 OSv 内核文件 ( osv-loader.qemu) 可以由capstan从OSv 常规版本页面自动下载，也可以从夜间版本存储库手动下载。
如果您熟悉 make 和 GCC 工具链并且想要尝试最新的 OSv 代码，那么您应该阅读自述文件的这一部分，以指导您如何设置开发环境并构建 OSv 内核和应用程序映像。
我们的目标是每年发布 2-3 次 OSv。您可以在 github 上找到最新的版本 以及许多已发布的工件，包括内核和一些模块。
此外，我们还建立了基于 Travis 的 CI/CD 管道，其中对 master 和 ipv6 分支的每次提交都会触发最新内核的完整构建，并将一些工件发布到夜间版本存储库。每次提交还会触发将新的 Docker“构建工具链”映像发布到Docker hub。
OSv 的组件wiki 页面中很好地解释了 OSv 的设计。您可以在原始USENIX 论文及其演示文稿中找到更多信息 。
此外，您可以在wiki 主页以及http://osv.io/和http://blog.osv.io/上找到许多有关特定 OSv 组件设计的好信息。不幸的是，其中一些信息可能已经过时（尤其是在http://osv.io/上），因此如果有疑问，最好在邮件列表上询问。
在下图中，您可以看到 OSv 跨逻辑层的主要组件。从顶部的 libc 开始，它很大程度上基于 musl，然后是中间的核心层，由 ELF 动态链接器、VFS、网络堆栈、线程调度程序、页缓存、RCU 和内存管理组件组成。最后是由时钟、块和网络设备驱动程序组成的层，允许 OSv 与 VMware 和 VirtualBox 等虚拟机管理程序或基于 KVM 和 XEN 的虚拟机管理程序进行交互。
没有官方的最新性能指标将 OSv 与其他 unikernels 或 Linux 进行比较。一般来说，OSv 在磁盘 I/O 密集型工作负载方面落后于 Linux，部分原因是 VFS 中围绕读/写操作的粗粒度锁定（如本期所述）。在网络 I/O 密集型工作负载中，OSv 应该表现得更好（或者至少习惯了，因为 Linux 自那时以来已经进步了很多），如 Redis 和Memcached的性能测试所示。您可以在主 wiki、http://osv.io/benchmarks上找到一些旧的“数字” ，以及本自述文件底部列出的一些论文。
因此，OSv 可能不是最适合运行 MySQL 或 ElasticSearch，但应该为微服务或无服务器等一般无状态应用程序提供相当稳定的性能（至少如一些论文所示）。
目前（截至 2022 年 12 月）隐藏所有符号构建的loader.elf通用 OSv 内核（工件）的大小约为 3.6 MB。与完整库和 ZFS 文件系统库链接的内核大小为 6.8 MB。请阅读模块化wiki，以更好地了解如何构建内核、进一步减小大小以及如何定制以在特定虚拟机管理程序或特定应用程序上运行。libstdc++.so.6
与其他 unikernel 相比，OSv 内核的大小可能被认为相当大。但是，请记住，OSv 内核（即 unikernel）提供了以下 Linux 库的功能子集（请参阅它们在 Linux 主机上的大致大小）：
libresolv.so.2( 100K )libc.so.6( 2MB )libm.so.6（1.4MB）ld-linux-x86-64.so.2( 184K )libpthread.so.0( 156K )libdl.so.2( 20K )librt.so.1( 40K )libstdc++.so.6( 2MB )libaio.so.1( 16K )libxenstore.so.3.0( 32K )libcrypt.so.1( 44K )
OSv 在只读 FS 和网络关闭的情况下，在 Firecracker 上启动速度可达约5 毫秒，在使用 microvm 机器的 QEMU 上启动速度甚至更快约3 毫秒。然而，一般来说，启动时间取决于许多因素，例如虚拟机管理程序，包括各个半虚拟设备、文件系统（ZFS、ROFS、RAMFS 或 Virtio-FS）的设置以及一些启动参数。请注意，默认情况下，OSv 映像是使用 ZFS 文件系统构建的。
例如，目前 Firecracker 上 ZFS 映像的启动时间约为 40 毫秒，而常规 QEMU 的启动时间约为 200 毫秒。此外，较新版本的 QEMU (>=4.0) 通常启动速度更快。在 PVH/HVM 模式下在 QEMU 上启动（也称为直接内核启动，通过-k选项启用run.py）应该总是更快，因为 OSv 是在 64 位长模式下直接调用的。请参阅
此 Wiki，了解 OSv 支持的引导方法的简要回顾。
最后，传递给内核的一些启动参数可能会影响启动时间：
--console serial- 这会禁用初始化缓慢的VGA 控制台，并且可以在 QEMU 上缩短 60-70 毫秒--nopci- 这会禁用 PCI 设备的枚举，特别是如果我们知道不存在任何设备（带有 microvm 或 Firecracker 的 QEMU），并且可以减少 10-20 毫秒--redirect=/tmp/out- 如果应用程序记录大量日志，写入控制台可能会严重影响性能（30-40%），因此将标准输出和错误重定向到文件可能会大大提高性能
您始终可以通过添加参数来查看启动时间细分--bootchart：
./scripts/run.py -e '--bootchart /hello'
OSv v0.57.0-6-gb442a218
eth0: 192.168.122.15
disk read (real mode): 58.62ms, (+58.62ms)
uncompress lzloader.elf: 77.20ms, (+18.58ms)
TLS initialization: 77.96ms, (+0.76ms)
.init functions: 79.75ms, (+1.79ms)
SMP launched: 80.11ms, (+0.36ms)
VFS initialized: 81.62ms, (+1.52ms)
Network initialized: 81.78ms, (+0.15ms)
pvpanic done: 81.91ms, (+0.14ms)
pci enumerated: 93.89ms, (+11.98ms)
drivers probe: 93.89ms, (+0.00ms)
drivers loaded: 174.80ms, (+80.91ms)
ROFS mounted: 176.88ms, (+2.08ms)
Total time: 178.01ms, (+1.13ms)
Cmdline: /hello
Hello from C code
OSv 需要至少 11 M 内存才能运行hello world应用程序。尽管只有 4 年前的三分之一，但与其他 Unikernel 相比仍然不少。生成许多线程的应用程序可能会利用构建内核的优势，并选择进一步减少内存利用率（请参阅此补丁conf_lazy_stack=1的注释以更好地理解此功能）。
我们计划通过向 L1/L2 内存池添加自调整逻辑来进一步降低这个数字。
OSv 附带大约 140 个单元测试，这些测试在每次提交时执行并在 ScyllaDB 服务器上运行。子树下还有许多额外的测试tests/，此时尚未自动化。
您可以通过多种方式运行单元测试：
./scripts/build check # Create ZFS test image and run all tests on QEMU./scripts/build check fs=rofs # Create ROFS test image and run all tests on QEMU
./scripts/build image=tests && \ # Create ZFS test image and run all tests on Firecracker ./scripts/test.py -p firecracker
./scripts/build image=tests && \ # Create ZFS test image and run all tests on QEMU ./scripts/test.py -p qemu_microvm # with microvm machine
此外，还有一个自动化测试框架
，可用于运行大约 30 个真实应用程序，其中一些应用程序在压力下使用ab或wrk工具。目的是捕捉单元测试可能遗漏的任何回归。
最后，可以使用Docker 文件在不同的 Linux 发行版上测试 OSv。
OSv 只能构建在 64 位 x86 和 ARM Linux 发行版上。请注意，这分别意味着 64 位 x86 的“x86_64”或“amd64”版本以及 ARM 的“aarch64”或“arm64”版本。
为了构建 OSv 内核，您需要一台带有 Linux 发行版的物理机或虚拟机、GCC 工具链以及 OSv 构建过程所依赖的所有必要的包和库。最快的设置方法是使用 OSv 附带的Docker 文件。您可以使用它们构建自己的 Docker 映像，然后启动它以构建 OSv 内核或在其中的 OSv 上运行应用程序。请注意，主 docker 文件依赖于Ubuntu 或Fedora的 预构建基础Docker 映像 ，这些映像在每次提交时都会发布到 DockerHub。这应该会加快构建最终映像的速度，因为所有必需的软件包都作为基础映像的一部分安装。
或者，您可以手动克隆 OSv 存储库并使用setup.py 安装所有必需的软件包和库，只要它支持您的 Linux 发行版，并且您的计算机上安装了 git 和 python 3：
git clone https://github.com/cloudius-systems/osv.git cd osv && git submodule update --init --recursive ./scripts/setup.py
它setup.py可以识别并安装许多 Linux 发行版的软件包，包括 Fedora、Ubuntu、
Debian、LinuxMint 和 RedHat 发行版（Scientific Linux、NauLinux、CentOS Linux、Red Hat Enterprise Linux、Oracle Linux）。请注意，我们仅积极维护和测试 Ubuntu 和 Fedora，因此您对其他发行版的体验可能会有所不同。最近还添加并测试了 CentOS 7 的支持，因此它应该也可以工作。setup.py
实际上 Docker 文件在内部使用它来达到相同的结果。
如果您喜欢在 IDE 中工作，我们建议您使用Eclipse CDT （可以按照本wiki 页面中的说明进行设置）或 JetBrains 的 CLion ，可以按照本指南中的说明使用所谓的编译数据库进行设置以与 OSv makefile 一起使用。
构建 OSv 就像使用 shell 脚本一样简单，./scripts/build
该脚本通过委托主makefile
来构建内核并使用大量 Python 脚本来编排构建过程，例如./scripts/module.py
构建应用程序并将其与内核融合到放置在./build/release/usr.img(或./build/$(arch)/usr.img一般情况）。请注意，构建应用程序并不一定意味着从源代码构建，因为在许多情况下，应用程序二进制文件将使用 shell 脚本位于 Linux 构建机器上并从中复制./scripts/manifest_from_host.sh
（有关详细信息，请参阅此 Wiki 页面）。
可以使用shell脚本，build如下例所示：
# Create default image that comes with command line and REST API server ./scripts/build# Create image with native-example app ./scripts/build -j4 fs=rofs image=native-example
# Create image with spring boot app with Java 10 JRE ./scripts/build JAVA_VERSION=10 image=openjdk-zulu-9-and-above,spring-boot-example
# Create image with 'ls' executable taken from the host ./scripts/manifest_from_host.sh -w ls && ./scripts/build --append-manifest
# Create test image and run all tests in it ./scripts/build check
# Clean the build tree ./scripts/build clean
命令 nproc 将自动计算 make 的作业/线程数./scripts/build。或者，可以按如下方式导出环境变量 MAKEFLAGS：
export MAKEFLAGS=-j$(nproc)
在这种情况下，make 和scripts/build 不需要参数-j。
有关如何使用构建脚本的详细信息，请运行./scripts/build --help.
创建qcow2 格式的./scripts/build图像。build/last/usr.img要将此映像转换为其他格式，请使用该./scripts/convert
工具，该工具可以将映像转换为 vmdk、vdi 或 raw 格式。例如：
./scripts/convert raw
默认情况下，OSv 内核是针对本机主机架构（x86_64 或 aarch64）构建的，但也可以通过添加arch参数在 Intel 机器上为 ARM 交叉编译内核和模块，如下所示：
./scripts/build arch=aarch64
目前，仅在 Fedora、Ubuntu 和 CentOS 7 上支持交叉编译aarch64./scripts/download_aarch64_packages.py版本的 OSv，并且可以使用该脚本下载相关的 aarch64 gcc 和库的二进制文件。OSv 还可以在 ARM 硬件（如 Raspberry PI 4、Odroid N2+ 或 RockPro64）上的 Ubuntu 上本地构建。
请注意，截至最新的0.57.0 版本，OSv 的 ARM 部分已经得到了极大的改进和测试，在功能方面与 x86_64 端口相当。此外，所有单元测试和许多高级应用程序（如 Java、golang、nginx、python、iperf3 等）都可以在启用了 KVM 加速的 Raspberry PI 4 和 Odroid N2+ 上的 QEMU 和 Firecraker 上成功运行。
有关 aarch64 端口的更多信息，请阅读此 Wiki 页面。
在引导过程结束时，OSv 动态链接器从作为映像一部分的磁盘上的文件系统加载应用程序 ELF 和任何相关库。默认情况下，构建的映像包含./scripts/build
格式化为 ZFS 的磁盘，您可以在此处阅读有关该磁盘的更多信息。ZFS 是一个出色的读写文件系统，如果您想在 OSv 上运行 MySQL，它可能是一个完美的选择。但是，如果您想运行无状态应用程序，这可能有点过大了，在这种情况下您可以考虑
Read-Only FS。最后，您还可以让 OSv 从 RAMFS 读取应用程序二进制文件，在这种情况下，文件系统将作为内核 ELF 的一部分嵌入。您可以通过将 参数设置为三个值之一来指定构建映像磁盘的文件fs系统./scripts/build- zfs、rofs或ramfs。
此外，还可以挂载 NFS 文件系统，该文件系统最近已转变为可作为模块插入的共享库，以及新实现和改进的Virtio-FS 文件系统。/etc/fstab可以通过添加适当的条目或传递引导参数来设置 Virtio-FS 挂载，如本Wiki中所述。此外，最近 OSv 已得到增强，能够直接从 Virtio-FS 文件系统启动。
最后，自 0.57 版本起，ZFS 支持也得到了极大改进，并且有许多方法和设置可以使用 OSv 构建和运行 ZFS 映像。有关详细信息，请阅读Filesystems wiki的 ZFS 部分。
运行由 构建的 OSv 映像scripts/build非常简单：
./scripts/run.py
默认情况下，run.py在 KVM 下运行 OSv，具有 4 个 vCPU 和 2 GB 内存。您可以通过将相关参数传递给run.py. 有关如何使用该脚本的详细信息，请运行./scripts/run.py --help。
可以run.py在 QEMU/KVM、Xen 和 VMware 上运行 OSv 映像。如果在 KVM 下运行，您可以通过按 Ctrl+A X 终止。
或者，您可以使用在Firecracker./scripts/firecracker.py上运行 OSv 。如果缺少的话，该脚本会自动下载 firecracker 二进制文件，并接受参数数量，例如 vCPU 数量、内存命名等。您可以从此wiki了解有关在 Firecracker 上运行 OSv 的更多信息。run.py
请注意，为了在 QEMU 或 Firecracker 下的 Linux 上以最佳性能运行 OSv，您需要启用 KVM（这只能在物理Linux 机器、EC2“裸机”(i3) 实例或支持 KVM 嵌套虚拟化的 VM 上实现） ）。验证 KVM 是否已启用的最简单方法是检查是否/dev/kvm存在，以及您的用户帐户是否可以对其进行读取和写
5D39
入。可能需要将您的用户添加到 kvm 组，如下所示：
usermod -aG kvm <user name>
有关在 OSv 上构建和运行 JVM、Node.JS、Python 和其他托管运行时以及 Rust、Golang 或 C/C++ 应用程序的更多信息，请阅读此wiki 页面。有关可以在 OSv 上构建和运行的各种示例应用程序的更多信息，请阅读 osv-apps 存储库 README。
默认情况下，run.py 启动 OSv 时
用户网络/SLIRP处于打开状态。要以更高性能的外部网络启动 OSv，您需要启用-n如下-v选项：
sudo ./scripts/run.py -nv
-v 用于 KVM 的虚拟主机，可提供更好的性能，其设置需要 Tap 设备，因此我们使用 sudo。
或者，可以将 OSv 作为与 Tap 设备一起使用的非特权运行，如下所示：
./scripts/create_tap_device.sh natted qemu_tap0 172.18.0.1 #You can pick a different address but then update all IPs below
./scripts/run.py -n -t qemu_tap0
--execute='--ip=eth0,172.18.0.2,255.255.255.252 --defaultgw=172.18.0.1 --nameserver=172.18.0.1 /hello'
默认情况下，OSv 会生成一个dhcpd类似线程，自动配置虚拟网卡。静态配置可以在 OSv 中通过配置网络来完成，如下所示：
ifconfig virtio-net0 192.168.122.100 netmask 255.255.255.0 up
route add default gw 192.168.122.1
要在 Firecracker 上启用网络，您必须显式启用-n选项firecracker.py。
最后，请注意，OSv 的主分支仅实现网络堆栈的 IPV4 子集。如果您需要 IPV6，请从ipv6 分支构建 或使用发布到nightlyreleases repo 的IPV6 内核。
- OSv可以用gdb进行调试；有关更多详细信息，请阅读此 维基
- OSv内核和应用程序可以被跟踪和分析；有关更多详细信息，请阅读此维基
- OSv 附带管理/监控 REST API 服务器；有关更多详细信息，请阅读 这个和 那个 wiki 页面。还有一个更轻量级的监控 REST API 模块 ，它实际上是前一个模块的只读子集。
如果您想了解有关 OSv 的更多信息或提出问题，请通过OSv Google Group 论坛与我们联系。您还可以在Twitter上关注我们。
在网上找到的有关 OSv 的较新文章列表：
- P99 演示：OSv Unikernel — 优化来宾操作系统以在云中运行无状态和无服务器应用程序
- Unikernels 与容器：微服务应用程序背景下的深入基准测试研究
- 迈向专业操作系统内核的实用生态系统
- Unikernels 的性能评估
- Unikernels 的安全视角
- 服务器应用程序的 OSv 性能评估
- 云平台中 KVM、Docker 和 Unikernels 的时间配置评估
- Unikernels - 超越容器到下一代云
您可以在http://osv.io/resources和http://blog.osv.io/找到一些较旧的文章和演示文稿。