虚拟化的一般理论和考古学x86

引言

作者团队

发表者Anton Zhbankov （ AntonVirtual ， cloudarchitect.cc ）
合著者： Grigory Pryalukhin ， Evgeny Parfenov

通用虚拟化概念

我不得不看到很多关于虚拟化是什么的解释，并听取了很多争议，而没有更多地争论实际的结果。 如您所知，两个聪明人的争论归结为关于定义的辩论。 让我们定义什么是虚拟化以及虚拟化的来源。

虚拟化最接近的定义可能是“面向对象编程”的“抽象”。 或者，如果将其翻译成普通的俄语，则会将实现隐藏在抽象接口的后面。 当然，这可以立即解释所有内容。 让我们再试一次，但对于那些尚未学习编程的人。

虚拟化-将特定的实现隐藏在访问资源/数据的通用标准化方法之后。

如果您尝试将这一定义付诸实践，那么事实证明它适用于完全出乎意料的主题。 假设时钟。 因此，几千年前发明了日d，而在中世纪发明了一种机械日d。 有什么共同点？ 太阳和一些齿轮？ 废话。 然后是石英振荡器和其他所有东西。
最重要的是，我们有一个标准接口-指针或数字指针，它以通用标准格式表示当前时间。 但是，如果时间对我们来说足够准确，对我们来说，在盒子内具体实现这种机制是否重要？
“让我，”您可以说，“但是我认为虚拟化是关于机器，那里的处理器等等！
是的，这与汽车和处理器有关，但这只是一个特例。 让我们更广泛地看一下，因为本文大胆主张了一个一般理论。

POZOR！

宇和 啊！ Pozor！

本文的总体教育目标是将大量技术和恐怖词语与历史联系在一起，形成一定的结构，因此，这种情况包含了大量的有意简化。 当然，它也包含大量烦人的遗漏，甚至是错别字的错误。 仅欢迎建设性批评，特别是“让我把这部分带给您”的形式。

虚拟化类型

让我们从完全抽象的概念返回到我们心爱的计算机更熟悉的概念。

存储虚拟化

第一种可能是新手极客遇到的虚拟化类型-数据存储系统的虚拟化。 在这种情况下，存储系统不是通过磁盘通过光纤通道连接的大型阵列来使用，而是用作负责长期数据存储的逻辑子系统。

FS-> LBA-> CHS

以单个硬盘上存储系统的最简单情况为例。 处理数据的常用格式是逻辑驱动器上的文件。 该文件可以打开，读取，关闭。 但是，像文件这样的对象实际上并不存在-只有一种使用“驱动器：\ folder1 \ folder2 \ file”形式的寻址方法访问某些数据块的方法。 即 我们遇到了虚拟化的第一层-从助记符和易于理解到人类，我们将所有内容转换为系统可理解的地址。 在元数据表中，文件系统驱动程序查找其中存在哪种数据块，然后在逻辑块寻址（LBA）系统中获取地址。 在LBA系统中，块具有固定的大小并线性地相互跟随，即 某种程度上可能与将数据存储在磁带上有关，但是硬盘完全不同！ 在这里，我们转到虚拟化的第二层-将LBA寻址转换为CHS（汽缸/汽缸盖/扇区）。



反过来，已经在硬盘控制器中的CHS开始转换为物理参数以供读取，但这是完全不同的故事。
即使通过简单的访问文件（例如，观看带有医学信息的vidosik），我们也立即遇到了三层虚拟化。
如果各层没有开始以随机顺序和各种方式重叠，那么一切都会太简单了。

磁盘阵列

许多人错误地认为虚拟化的第二层是RAID（廉价/独立磁盘的冗余阵列）。

在所讨论的概念中，RAID的主要功能不是保护数据免受特定物理磁盘故障的能力。 RAID在几个（有时很多）独立的LBA地址之上提供了第二层LBA寻址。 由于我们可以访问RAID（无论RAID级别如何），就如同访问没有RAID的单个磁盘一样，因此我们可以放心地说：

RAID是磁盘虚拟化。

而且，RAID控制器不仅可以从多个物理磁盘创建一个大型虚拟磁盘，还可以通过添加另一层虚拟化来创建任意数量的虚拟磁盘。

查看虚拟化

我们许多人几乎每天都在使用的下一类虚拟化，但并不认为是虚拟化，它是到桌面的远程连接。

终端服务器，VDI，甚至只是通过VPN到服务器的RDP都属于会话虚拟化。 使用标准接口（监视器，键盘，鼠标），我们可以在真实机器上工作，也可以在带有容器化应用程序的链接克隆上的虚拟桌面上进行难以理解的设计，我们可以通过缓冲区将数据通过缓冲区传输到具有流传输的应用程序中。 否，除了设计它的人之外，谁还会弄清楚呢？

x86虚拟化简介

处理器的历史和概述

程序执行

在特别编程课程的第一节课中，弗拉基米尔·丹尼索维奇·莱柳克（Vladimir Denisovich Lelyukh，为他安息）对学生说：尽管计算机名叫计算机，但它不能计数，它可以假装它可以计数。 但是，如果某物看起来像鸭子，走路像鸭子，嘎嘎叫鸭子，从实际的角度来看，它就是鸭子。

让我们尝试记住这一点，以供进一步实际使用。

计算机，特别是处理器实际上并没有执行任何操作-它只希望在某些位置输入一些输入参数，然后通过可怕的黑魔法在某些位置给出某些结果。

在这种情况下，程序是严格按顺序执行的特定命令流，因此我们希望看到一定的结果。
但是，如果程序正在执行，那么如何输入数据呢？ 通常，以某种方式在计算机上进行交互？

为此，发明了硬件中断。 用户按下一个键-键盘控制器会发出信号，并且当前代码线程的执行会中断。 中断处理程序的地址记录在特定的存储区中，并在保存当前状态后将控制权转移到中断处理程序。 反过来，从理论上讲，处理程序应该快速处理所有内容，然后，他和处理程序，写下所需缓冲区中按下的键，然后将控制权返回。 因此，该应用程序似乎正在运行，并且我们可以与系统进行交互。

如果在退出该模式之前无法实现其他中断，则中断处理程序（处理程序的主要类型是设备驱动程序）有机会进入特殊的处理器模式。 最终，这通常会导致挂断问题-驱动程序中的错误不允许退出中断。

多任务

如果必须同时执行多个程序（带有数据和存储结构的代码流），该怎么办？ 显然，如果代码流多于能够执行它们的设备，那么这就是一个问题。

在直接切换到任务时执行任务时会出现伪多任务处理。

将来，将出现一个协作式（非抢先式多任务处理）-可执行任务本身就知道它不再需要处理器资源，并将控制权交给其他人。 但是，这还不够。

而这里再次出现了干扰+假装的能力来拯救我们。 对于用户而言，严格同时执行对他们来说并不重要，看起来就足够了。
因此，只需挂起处理程序以中断计时器，计时器便开始控制接下来应执行哪个代码流。 如果计时器被触发得很频繁（例如15毫秒），那么对于用户来说，一切都看起来像是并行操作。 因此，现代人挤出了多任务处理。

实模式

本文中的真正处理器模式可以非常简单地描述-每个人都可以使用所有内存。 任何应用程序，包括恶意软件（恶意软件，恶意软件），都可以在任何地方访问，以进行读写。

这是Intel x86处理器系列的初始操作模式。

保护模式

1982年，英特尔80286处理器（以下简称286）出现了一项创新-一种受保护的操作模式，带来了内存工作组织方面的创新（例如，内存段类型的分配-代码，数据，堆栈）。 但是286处理器带给x86世界的最重要的事情是保护环的概念，我们仍然在使用它。

保护环的概念最初出现在GE645大型机的Multics操作系统中（1967年），其中部分实现了软件，而完全硬件已于1970年在Honeywell 6180系统中实现。



防御环的基本概念类似于中世纪的多层堡垒；最有价值的是位于多层墙后面的正中。 在这种情况下，最有价值的事情是无限制地直接访问RAM的任何区域并控制所有进程。 它们被保护环为零的进程所拥有。 在墙的后面，首先是不太重要的进程，例如设备驱动程序，最后是用户应用程序。 原理很简单-从内部可以进入外部，但是从外部向内禁止。 即 没有任何用户进程可以访问OS内核内存，这在早期的实模式下是可能的。

在Honeywell 6180的第一个完整实现中，实现了8个保护环，但是Intel决定将电路简化为4个，实际上，操作系统制造商开始只使用两个-零和第三个。

32位

1985年，发布了x86系列中另一个在架构上极为重要的处理器-80386（以下称为386），该处理器实现了32位存储器寻址并使用了32位指令。 当然，还有内存虚拟化。 如前所述，虚拟化是通过提供人工“虚拟”资源来掩盖实际实施情况。 在这种情况下，我们正在谈论内存寻址。 存储器段具有其自己的寻址，这与存储器单元的实际位置无关。
事实证明对处理器的需求如此之大，以至于它是在2007年之前生产的。
就英特尔而言，该架构称为IA32。

64位

当然，即使在2000年代中期没有虚拟化，该行业也已经遇到了32位的限制。 PAE（物理地址扩展）的形式有一些变通办法，但是它们使代码复杂化并减慢了速度。 过渡到64位已成定局。

AMD推出了其架构版本，称为AMD64。 在Intel，他们希望使用IA64平台（Intel Architecture 64），我们也将其称为Itanium。 但是，市场对这种架构的热情不高，因此，英特尔被迫实施对AMD64指令的支持，该指令最初被称为EM64T，然后才是Intel 64。

最终，我们都知道该体系结构为AMD64，x86-64，x86_64或有时为x64。

由于当时服务器的主要用途是物理的，没有虚拟化，因此虚拟化中的第一个64位处理器发生了技术上的有趣事情。 嵌套的虚拟机管理程序通常用作实验室服务器；并非每个人都能负担得起几个物理服务器群集。 最后，事实证明嵌入式虚拟机管理程序中的负载VM只能在32位模式下工作。

在最初的x86-64处理器中，开发人员在保持与32位操作模式的完全兼容性的同时，放弃了64位模式中功能的重要部分。 在这种情况下，问题在于极大地简化了内存分段。 在虚拟机管理程序异常处理程序正常工作的VM中，保证一小块内存不可侵犯的功能已删除。 因此，来宾操作系统能够对其进行修改。
随后，AMD返回了限制细分市场的可能性，而英特尔只是在等待硬件虚拟化的推出。

UMA

X86多处理器系统开始使用UMA（统一内存访问）模式工作，在该模式下，从任何处理器（访问存储单元的延迟）到任何内存条的距离都是相同的。 在Intel处理器中，即使在54xx代（Harpertown）之前出现了多核处理器之后，仍保留了这种工作方案。 从55xx（Nehalem）代开始，处理器已切换到NUMA架构。

从执行逻辑的角度来看，这是附加硬件线程的外观，您可以在其上分配代码流以并行执行。

NUMA

NUMA（非统一内存访问）-内存访问不均匀的体系结构。 在此体系结构内，每个处理器都有自己的本地内存，可以以低延迟直接对其进行访问。 其他处理器的内存以较高的延迟间接访问，这导致性能降低。

对于2019年的Intel Xeon可扩展v2处理器，内部体系结构仍然在插槽内保留UMA，而对于其他插槽却变成了NUMA（尽管不是真的，只是假装如此）。 AMD的Opteron处理器即使在最古老的UMA Xeon时代也具有NUMA架构，然后NUMA甚至进入插槽内部，直到罗马的最后一代，他们才回到NUMA =插槽。

虚拟机

虚拟机（VM，来自英文虚拟机）-一种软件和/或硬件系统，其模拟某些平台的硬件（目标是目标平台或来宾平台），并在主机平台上执行目标平台的程序（主机是主机平台） ，即主机平台），或虚拟化某个平台并在其上创建将程序甚至操作系统彼此隔离的环境。 维基百科
在本文中，我们将说“虚拟机”，意思是“系统虚拟机”，它允许以软件结构的形式完全模拟所有资源和硬件。
用于创建虚拟机的软件主要有两种-完整版和相应版。 虚拟化不完整。

完全虚拟化是一种模拟所有硬件（包括处理器）的方法。 允许您创建独立于硬件的环境，并在SPARC系统上运行用于x86平台的OS和应用程序软件，或者在熟悉的x86上运行带有Z80处理器的著名Spectrum模拟器。 完全独立的另一面是虚拟化处理器的高开销和较低的整体性能。

不完全虚拟化是一种不对100％的硬件进行虚拟化的方法。 由于不完全虚拟化在业界最为普遍，因此我们将对其进行讨论。 关于针对x86架构具有不完全虚拟化的系统虚拟机的平台和技术。 在这种情况下，处理器的虚拟化不完整，即 除了部分替换或隐藏某些系统调用外，虚拟机的二进制代码直接由处理器执行。

软件虚拟化

处理器体系结构和操作系统在零环上工作的习惯的明显结果就是问题-来宾OS内核无法在通常的地方工作。 零环被管理程序占用，您只需要让来宾OS也到达那里-一方面，我们会返回实模式并带来所有后果，另一方面，来宾OS不会期望任何人在那里，并且会立即破坏所有数据结构并丢弃汽车。

但是，一切都非常简单地决定：因为对于虚拟机管理程序，来宾OS只是一组具有完全直接访问权限的内存页面，而虚拟处理器只是一系列命令，为什么不重写它们呢？ 虚拟机管理程序可以即时将需要零环特权的所有指令从要在虚拟处理器上执行的指令队列中剔除，然后将其替换为特权较少的指令。 但是，这些指令的结果以与来宾OS处于零环状态完全相同的方式呈现。 因此，您可以完全虚拟化任何内容，直到完全没有来宾OS为止。
该方法由开发团队在1999年在VMware Workstation产品中实施，然后在2001年在GSX服务器虚拟机管理程序（第二种类型，如Workstation）和ESX（第一类）中实现。

半虚拟化

准虚拟化是一个非常简单的概念，它假定来宾OS知道它在虚拟机中，并且知道如何访问主机OS的某些系统功能。这样就消除了模拟零环的问题-来宾OS知道零环不是零，并且行为相应。
x86中的准虚拟化出现在2003年的Linux Xen项目中。

还可以通过来宾OS中与虚拟机管理程序进行通信以减少虚拟化开销的特殊虚拟驱动程序，在具有完全虚拟化功能的虚拟机管理程序中实现某些准虚拟化功能。例如，适用于VM的VMware ESXi具有半虚拟SCSI适配器PVSCSI，可提高具有大量磁盘操作的VM（例如已加载的DBMS）的整体性能。用于半虚拟设备的驱动程序包含在其他软件包中（例如VMware Tools），或者已经包含在Linux发行版中（open-vm-tools）。

硬件虚拟化

随着虚拟化技术的发展和普及，两家平台制造商都渴望降低其支持成本，并从安全角度出发，以保证硬件的保护。

通过非常简单的方式解决了该问题-添加了Intel VT-x和AMD-V专有的硬件虚拟化技术，如果我们放弃了详细的技术细节，则将减去系统管理程序的第一个保护环。这样，最终确定了OS熟悉的零环工作状态。

虚拟机监控程序的类型

类型2（托管）

第二类管理程序是在主机操作系统上运行的应用程序。所有虚拟机调用均由上游主机操作系统处理。第二类型的管理程序在性能上受到严重限制，因为管理程序的应用（无权独家分配计算资源）被迫与其他用户应用程序竞争。在安全性方面，类型2虚拟机管理程序直接取决于用户OS的安全策略及其易受攻击的漏洞。如今，业界普遍认为，这种虚拟化平台不适用于企业级。但是，它们易于管理和部署，非常适合直接在软件开发人员的机器上进行跨平台开发和部署。

第二类管理程序的示例：VMware Workstation / Fusion，Oracle VM VirtualBox，Parallels Desktop，VMware Server（ex-GSX），Microsoft Virtual Server 2005

类型1（裸金属）

与以前的虚拟机管理程序不同，第一类虚拟机管理程序不需要通用操作系统。系统管理程序本身是一个整体，既控制计算资源的分配又控制I / O。在零安全环中，有一个微核，所有控制结构都在其上工作。在这种体系结构中，管理程序控制计算资源的分配，并且它本身控制虚拟机对设备的所有调用。长期以来，VMware ESX一直被认为是x86的第一类虚拟机管理程序，尽管现在我们将其归因于1+。如今，这种类型的唯一“诚实”代表是VMware ESXi，它是ESX的继任者，因为它与RHEL脱离了父部分。

例如，考虑ESXi体系结构。系统管理程序管理命令通过在VMkernel之上运行的代理API执行。这看起来像是与虚拟机管理程序的直接连接，但事实并非如此。无法直接访问管理程序，这在安全性方面将这种类型的管理程序与第二种类型的管理程序区分开来。



这里的缺点是设备驱动程序：为确保平台的“薄型”并消除版本之间不必要的复杂性，设备驱动程序轮换使用，这使物理基础结构依赖于HCL（硬件兼容性列表）。

类型1+（混合管理程序）

混合类型的系统管理程序（它们也是类型1 +，1a，1.5）的特征是将基本OS隔离到称为父分区（Microsoft Hyper-V术语中的父分区）或父域（Xen术语中的dom0）的特殊实体中。因此，在安装了虚拟机监控程序的角色之后，内核进入虚拟化支持模式，并且虚拟机监控程序负责在主机上分配资源。但是父级部分接管了处理对设备驱动程序和I / O操作的调用的功能。

实际上，父节成为虚拟化堆栈的所有实体之间的一种提供程序。从与设备的兼容性的角度来看，此方法很方便：您不需要像ESXi一样在虚拟机管理程序中嵌入设备驱动程序，这意味着设备列表正在扩展，并且对HCL的依赖性降低。优点包括将虚拟机管理程序从处理对设备驱动程序的调用的任务中卸载出来，因为所有调用均由父节处理。

类型1+虚拟机管理程序的顶级架构如下所示：



这种类型的虚拟机管理程序包括：已故的VMware ESX，Microsoft Hyper-V，基于Xen的虚拟机管理程序（各种Linux发行版中的Citrix XenServer和Xen实现）。回想一下，Citrix XenServer是基于RHEL的略微删减的操作系统，其版本和功能直接取决于Red-Hat Enterprise Linux的当前版本。对于其他Xen实现，情况没有太大不同：Xen虚拟机管理程序模式下是相同的Linux内核，而dom0域中是基本OS。这得出了明确的结论，即基于Xen的虚拟机管理程序属于混合类型，而不是诚实的1型虚拟机管理程序。

工业平台主要技术

将以VMware作为最先进技术的虚拟化平台的术语为基础。在本文中，我们将自己局限于管理程序本身的技术和基本控制系统。由其他产品实现的所有高级功能（需要额外的钱）将被保留在幕后。正如作者所认为的那样，技术被分为主要目的的有条件组，您有权与他们不同意。

服务水平协议

这是一组技术，主要影响SLA的可访问性（RPO / RTO）的性能。

哈

高可用性-一种确保虚拟机管理程序在群集中的VM具有高可用性的技术。万一主机死亡，VM会在尚存的主机上自动重新启动。效果：在HA +重启OS /服务超时之前最小化RTO。

金融时报

容错-一种即使在主机死亡的情况下也可确保VM连续运行的技术。在第二台主机上创建一个影子VM，该影子VM与主要主机完全相同，并重复其后面的指令。因此，VM状态的差异以数十或数百毫秒为单位进行度量，这对于许多服务来说是完全可以接受的。主机死后，执行将自动切换到影子VM。效果：将RTO降至零。

TCO

这是主要影响总体拥有成本的一系列技术。

vMotion

vMotion是一项用于将VM执行点从一台功能齐全的主机实时迁移到另一台主机的技术。同时，执行点的切换点小于网络连接超时，这使我们可以将迁移视为实时迁移，即 不会中断生产服务的工作。效果：针对计划内的服务器维护中断，将RTO降低为零，从而部分消除了中断本身。

存储vMotion

Storage vMotion是一项用于将VM存储点从一个功能齐全的存储实时迁移到另一个功能的技术。同时，磁盘系统的工作不会停止，因此可以认为迁移是实时的。效果：将计划停机的RTO降低到零以进行存储维护，从而部分消除了停机本身。

DPM

分布式电源管理-一种技术，用于控制主机负载的级别以及随着群集负载的变化而打开/关闭主机的电源。需要DRS才能运行。效果：总体上降低了功耗。

分布式vSwitch

分布式vSwitch是一项用于集中管理虚拟主机交换机的网络设置的技术。效果：减少了重新配置网络子系统的工作量和复杂性，降低了出错的风险。

EVC

增强的vMotion兼容性是一项技术，可在自动模式下屏蔽VM的可用处理器指令。它用于使不平衡群集中的VM工作与最旧的处理器系列保持一致，从而能够将VM迁移到任何主机。效果：节省基础架构的复杂性，同时逐渐增加容量/部分升级集群。

服务质量

这是一组在服务质量方面主要影响SLA性能的技术。

vNUMA

vNUMA是一项允许来宾OS与大型计算机（vCPU或vRAM> NUMA节点）的VM虚拟NUMA拓扑通信的技术。效果：对支持NUMA的应用软件的性能没有造成任何损失。

资源池

资源池-将多个VM组合到一个资源池中以控制消耗或保证资源分配的技术。效果：简化管理，提供服务水平。

限制/储备

有限和冗余的处理器/内存允许您限制资源的分配，反之亦然，以确保在资源短缺和竞争的情况下分配资源，从而确保维护高优先级的VM /池。

DRS

动态资源调度程序-主机根据负载自动平衡VM，以减少群集中的资源碎片并为VM提供一定级别的服务。需要vMotion支持。

存储IO控制

存储IO控制是一项限制“嘈杂邻居”的技术，该技术是具有高磁盘负载的低优先级计算机，可将昂贵的存储系统的性能用于生产性工作负载。例如，一个索引系统/内部搜索引擎和一个高效的DBMS。

网络IO控制

网络IO控制是一种技术，用于限制“嘈杂的邻居”，即具有较高网络负载的低优先级计算机。

存储集成（VAAI等）

集成部分中包含两类技术：

• 虚拟化管理系统与存储管理系统的集成可以极大地简化卷/存储气球向管理程序的选择和呈现，从而减少错误的风险和工作的复杂性。
• 协议级别集成-VAAI，ODX。这些技术使您可以卸载磁盘子系统，将部分标准负载转移到处置智能存储中。例如，此类别包括诸如归零块，克隆VM等操作。因此，大大减少了到存储系统的通道，并且存储系统本身以更优化的方式执行磁盘操作。

安全性

微细分

实际使用中的虚拟网络细分是建立虚拟分布式防火墙的能力，该防火墙可控制主机内部的虚拟网络。极大地增强了虚拟网络的安全性。

无代理AV

技术支持无代理防病毒。虚拟机管理程序将VM磁盘操作的流量定向到选定的服务VM，而不用由来宾OS中的代理检查。大大减少了处理器和磁盘系统的负载，有效地消除了“反病毒风暴”。

超融合系统

顾名思义，融合系统是具有功能组合的系统。在这种情况下，我们指的是VM的存储和执行的结合。看起来很简单，但是市场营销突然中断了。

术语“融合系统”是第一次，营销人员进入市场。融合系统销售普通的经典服务器+存储+交换机。不到一个合作伙伴编号。甚至他们甚至都没有卖，而是制作了一篇名为“参考架构”的论文。我们真诚地谴责这种方法，并继续进行架构考虑。

建筑学

保持融合作为一种架构原则，我们在单个系统中获得了VM的存储点和执行点的组合。

换句话说，融合架构意味着使用相同的硬件服务来执行VM并将它们存储在本地磁盘上。好吧，因为应该有容错能力-在聚合架构中，存在一层分布式SDS。

我们得到：

• 经典的系统-软件，存储，交换和服务器来自不同的地方，由客户/集成商共同完成。单独的支持合同。
• 融合系统-全部来自一种来源，一种支持，一种合作伙伴编号。不要与一个供应商的自组装混淆。

事实证明，我们的融合架构一词已被采用。与主管的情况完全相同。

超融合系统-具有融合架构的融合系统。
当然，这并非没有营销人员的第二次来临。出现了融合系统，其中没有存储组合，但是在分布式SDS的控制下有专用的存储节点。在营销战的框架内，甚至出现了特殊术语“分解的HCI”（“分解的超垂直基础结构”）。尤其是，例如，具有相似系统的NetApp最初进行了激烈的争夺，要求将其系统称为超融合的权利，但最终被放弃。NetApp HCI今天（2019年末）-混合云基础架构。

实施方案

由于超融合系统可与虚拟化一起使用，因此实际上有两个半的实施选择。

• 1.内核模块。SDS作为虚拟机管理程序核心的整体，例如vSAN + ESXi
• 1.5父节模块。SDS作为服务作为虚拟机管理程序的父部分的一部分，例如，S2D + Hyper-V
• 2.虚拟机。SDS被实现为每个主机上的专用虚拟机。Nutanix，Cisco Hyperflex，HPE简化。

显然，除了讨论的对嵌入式性能产生影响的问题之外，还有一个非常重要的问题，即第三方管理程序的隔离和支持。在情况1中，很明显，这只能是来自管理程序提供程序的单个系统，而2可能可以在任何管理程序中工作。

货柜

容器化虚拟化虽然在技术上与完全虚拟化有很大的不同，但其结构看起来非常简单。与OSI网络模型一样，问题是水平的。容器虚拟化级别更高-在应用程序环境级别，而不是物理级别。

容器虚拟化的主要任务是将操作系统分为独立的部分，隔离的应用程序不会相互干扰。完全虚拟化不是由操作系统共享的，而是由物理服务器共享的。

VM与容器

两种方法的优缺点都非常简单，并且正好相反。

完全虚拟化（VM）使铁水平完全独立，包括完全独立的OS，磁盘和网络堆栈。 另一方面，由于我们遵循方案1 application = 1 server，因此每个应用程序都需要自己的OS，自己的磁盘和网络堆栈。 即 有多种资源消耗。

这些容器与主机OS具有通用的磁盘和网络堆栈，并且它们一起使用整个物理服务器（最近才是虚拟的或虚拟的）上的一个核心，总​​体上，您可以在相当大的环境中大幅节省资源。

从历史上看，x86最初具有用于所有内容的容器以及物理服务器。 在完全虚拟化问世之后，容器的重要性急剧下降了近15年，并且厚虚拟机在企业界占据了主导地位。 当时，容器位于提供数百个相同类型Web服务器的托管服务器上，而这些服务器需要轻便。 但是近年来，自2015年以来，容器以云原生应用程序的形式回到了企业现实。

容器0.1

chroot

1979年的容器原型是chroot。

“ Chroot是在类似Unix的操作系统上更改根目录的操作。 使用修改后的根目录启动的程序只能访问该目录中包含的文件。”

即 实际上，隔离只是在文件系统级别，否则只是操作系统中的正常过程。

Freebsd监狱

更为先进的是1999年出现的免费BSD监狱。 Jail允许您基于基础FreeBSD创建具有其自己的应用程序和配置文件集的成熟虚拟OS实例。 肯定有人在说-监狱在集装箱里做什么，因为这是半虚拟化！ 他们将部分正确。

但是，在完全虚拟化（及其以半虚拟化形式出现的变体）之前，监狱缺乏在来宾VM中运行不同版本的内核以及将VM迁移到另一个主机系统的能力。

Solaris区域

Solaris Zones是一种操作系统虚拟化技术（容器虚拟化），于2004年在Sun Solaris中引入。 基本原则是低虚拟化开销。

并没有获得太大的普及，而是迁移到了OpenSolaris以及基于OpenSolaris的发行版中，该发行版将于2019年上市。

容器1.0

在容器1.0时代，容器化的两个主要方向出现了-这些是托管提供商的商业产品，以及应用程序的容器化。

Virtuozzo / OpenVZ

俄罗斯SWsoft于2001年推出了其第一个版本的容器虚拟化Virtuozzo，其目标是托管提供商市场。 由于决心和特定的商业目标受众，该产品非常成功并获得了普及。 从技术上讲，在2002年，展示了在8个处理器服务器上同时运行2500个容器的情况。

在2005年，出现了用于Linux的Virtuozzo容器的开放版本，称为OpenVZ。 并几乎成为托管VPS的黄金标准。

x

LinuX容器（LXC）是另一种基于名称空间和cgroup的知名容器虚拟化，它于2008年出现。它是当前流行的docker等的基础。

容器1.1（应用程序虚拟化）

如果将其余的容器设计为将基本OS划分为多个部分，那么为什么不撕下系统的这一层并将其与应用程序及其所有周围环境包装在一个盒子中。 然后，可以将这个现成的程序包作为常规的用户级应用程序启动。

应用程式v

Microsoft应用程序虚拟化（App-V），以前是Softricity SoftGrid-一种用于在隔离的沙箱中（然后是Microsoft）对特定应用程序进行容器化（相反的容器）的技术。 2006年，Microsoft收购了Softricity初创公司，该公司实际上改变了这个容器。

Thinapp的

VMware ThinApp（以前称为Thinstall）是来自Jilt的应用程序容器化产品，于2008年被VMware收购。 VMware估计，全球所有打包应用程序中有90-95％使用此技术。

容器2.0

容器2.0出现的历史与软件开发过程的变化密切相关。 企业希望缩短产品上市时间等重要参数的愿望迫使开发人员重新考虑创建软件产品的方法。 瀑布式开发方法（较长的发布周期，整个应用程序已更新）被敏捷替代（较短的，固定时间的发布周期，应用程序组件已独立更新），并迫使开发人员将整体应用程序分离为组件。 尽管单片应用程序的组件仍然很大，并且可以放置在虚拟机中的组件并不多，但是当一个应用程序由数十个或数百个组件组成时，虚拟机不再非常适合。 此外，还会出现辅助软件版本，库和依赖项的问题，通常会出现以下情况：不同的组件需要不同的版本或不同配置的环境变量。 这些组件必须分发到不同的虚拟机，因为 几乎不可能在同一OS中同时运行多个版本的软件。 VM的数量开始像雪崩般增长。 在这里，容器出现在舞台上，允许在一个来宾OS的框架内创建几个隔离的环境来启动应用程序组件。 应用程序的容器化使您可以将单个应用程序继续细分为更小的组件，并转移到一个任务=一个组件的范例-一个容器，这称为微服务方法，每个这样的组件都是微服务。

引擎盖下的容器

如果您从系统管理员的角度看一下容器，那么这些只是具有自己的pid的Linux进程，等等。 怎样才能使容器中运行的进程彼此隔离，并一起消耗客户机OS的资源？ 任何现代Linux发行版的内核中都存在两种标准机制。 第一个是Linux命名空间，它确保每个进程都能看到自己的操作系统表示（文件系统，网络接口，主机名等），第二个是Linux控制组（cgroup），从而将进程限制为消耗来宾OS资源（CPU，内存）网络带宽等）。

Linux命名空间

默认情况下，每个Linux系统都包含一个名称空间。 所有系统资源（例如文件系统，进程标识符（Process ID），用户标识符（User ID），网络接口）都属于此名称空间。 但是没有人阻止我们创建其他名称空间并在它们之间重新分配系统资源。

当新进程启动时，它将在名称空间，系统标准或已创建的名称空间之一中启动。 并且此过程将仅看到用于运行它的名称空间中可用的那些资源。

但是，并非所有事情都那么简单，每个进程都不属于一个名称空间，而是属于每个类别中的一个名称空间：

• 挂载（MNT）
• 进程ID（pid）
• 网络（net）
• 进程间通信（ipc）
• 悉尼科技大学
• 用户ID（用户）

每种类型的名称空间都会隔离相应的资源组。 例如，UTS空间定义了进程可见的主机名和域名。 因此，来宾OS中的两个进程可以假定它们正在不同的服务器上运行。

网络名称空间决定了网络接口的可见性，内部的进程将仅看到属于该名称空间的接口。

Linux控制组（cgroups）

Linux控制组（cgroups）是Linux系统的内核系统机制（Kernel），它限制进程对系统资源的消耗。 每个进程或进程组将无法获得比其分配的资源（CPU，内存，网络带宽等）更多的资源，并且将无法捕获“其他”资源-相邻进程的资源。

码头工人

如上所述，Docker并不是这样发明容器的。 容器已经存在了很多年（包括基于LXC的容器），但是Docker通过创建第一个系统使容器在不同机器之间轻松便捷地传输，使它们非常流行。 Docker创建了一个用于创建容器的工具-打包应用程序及其依赖项，并在安装了Docker的任何Linux系统上运行容器。

Docker的一个重要功能是不仅应用程序本身及其在完全不同的Linux发行版之间的依赖关系的可移植性，而且还包括环境和文件系统的可移植性。 例如，在CentOS上创建的容器可以在Ubuntu系统上运行。 在这种情况下，在启动的容器内，文件系统将从CentOS继承，并且应用程序将认为它在CentOS之上运行。 这有点类似于虚拟机的OVF映像，但是Docker映像的概念使用层。 这意味着仅更新映像的一部分时，无需再次下载整个映像，仅下载已更改的层就足够了，就好像OVF映像可以更新OS而无需更新整个映像一样。

Docker创建了一个生态系统，用于创建，存储，传输和启动容器。 Docker世界包含三个关键组件：

• 图像-图像，是包含您的应用程序，必要环境和启动容器所需的其他元数据的实体；
• 注册-仓库，Docker镜像的存储位置。 有多种存储库，从官方的-hub.docker.com到以公司基础架构中部署的私有存储库结尾；
• 容器-一个容器，从Docker映像创建的Linux容器。 如上所述，这是一个在装有Docker的Linux系统上运行的Linux进程，与其他进程和OS本身隔离。

考虑容器的生命周期。 最初，开发人员完全从头开始或使用已创建的映像作为基础（记住层），使用其应用程序（docker build命令）创建Docker映像。 此外，开发人员可以直接在自己的计算机上启动该映像，也可以将其转移到另一台服务器上。 为了可移植性，经常使用存储库（docker push命令）-它们将映像加载到存储库中。 之后，可以将映像下载到任何其他计算机或服务器（docker pull）。 最后，从该映像创建一个工作容器（docker运行）。

Kubernetes

正如我们已经说过的那样，微服务的概念意味着将单片应用程序划分为许多小服务，通常执行一个功能。 好吧，当有数十种这样的服务时，仍然可以通过例如Docker进行手动管理。 但是，当有成千上万的此类服务时该怎么办？ 除了工业环境外，您还需要一个测试环境以及用于产品不同版本的其他环境，即 乘以2，乘以3甚至更多。 Google也面临同样的问题，其工程师是最早在工业规模上使用容器的人之一。 因此，Kubernetes（K8s）诞生了，它以Google产品中的博格（Borg）名称命名，后来被大众大众使用并更名。

K8s是一个易于部署，管理和监视容器化应用程序（微服务）的系统。 众所周知，任何Linux机器都适合启动容器，并且容器彼此隔离，并且K8可以在不同Linux发行版的控制下使用不同的硬件管理不同的服务器。 所有这些都有助于我们有效地使用可用的硬件。 像虚拟化一样，K8s为我们提供了一个公共资源池，用于启动，管理和监视我们的微服务。

由于本文主要针对虚拟化工程师，因此，为了对K8s的操作原理和主要组件有一般的了解，我们建议您阅读与K8s和VMware vSphere相似的文章： https ://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- 使用者232cc2f69c58

X86工业虚拟化历史

的VMware

VMware于1998年问世，首先是开发第二种类型的系统管理程序，后来又称为VMware Workstation。

该公司于2001年通过两个虚拟机管理程序进入服务器市场-GSX（Ground Storm X，第二种类型）和ESX（Elastic Sky X，第一类）。 随着时间的流逝，服务器应用中第二种类型的前景变得显而易见，即 没有 付费的GSX首先变成了免费的VMware Server，然后完全停止并掩埋。

2003年，出现了Virtual Center中央管理系统，vSMP技术以及虚拟机的实时迁移。

2004年，VMware被存储巨头EMC收购，但仍独立运营。

2008年，VMware成为事实上的行业标准，刺激了Citrix，Microsoft等竞争性产品的快速增长。很明显，需要获得免费版本的虚拟机管理程序，这是不可能的，因为ESX的父级部分使用了非常商业化的RHEL。 以更轻松，更免费的方式代替RHEL的项目于2008年通过busybox系统得以实施。 结果就是今天众所周知的ESXi。

同时，公司正在通过内部项目和对初创公司的收购来发展。 几年前，VMware产品列表占据了A4的几页，所以我们只说一说。 2019年的VMware仍然是本地企业完全虚拟化市场中的事实上的标准，占有70％以上的市场份额，并且是绝对的技术领导者，对历史的详细回顾值得一读。

Connectix

Connectix成立于1988年，一直致力于各种系统实用程序的开发，直到采用虚拟化技术为止。 1997年，创建了第一个用于Apple Macintosh的VirtualPC产品，使Windows可以在虚拟机中运行。 Windows版VirtualPC的第一个版本出现在2001年。

2003年，Microsoft购买了VirtualPC，并与Connectix达成协议，开发人员转而使用Microsoft。 之后，Connectix关闭。

VHD（虚拟硬盘）格式是由Connectix for VirtualPC开发的，并且提醒一下，Hyper-V计算机的虚拟磁盘在其签名中包含“ conectix”。
您可能会猜到，虚拟PC是第二种经典的台式机管理程序。

微软公司

微软进入工业虚拟化的旅程始于购买Connectix并在Microsoft Virtual PC 2004中对Connectix Virtual PC进行品牌重塑。经过一段时间的开发，Virtual PC在Windows 7中被命名为Windows Virtual PC。在Windows 8和更高版本中，Virtual PC被替换为桌面版本的Hyper-V。

基于Virtual PC，创建了Virtual Server服务器管理程序，该管理程序一直存在到2008年初。 由于在VMware ESX之前存在明显的技术损失，因此决定减少第二种虚拟机管理程序的开发，转而使用其自己的第一类虚拟机管理程序，即Hyper-V。 业界有一种非正式的观点，认为Hyper-V在架构上与Xen惊人地相似。 与Java中的.Net大致相同。

“当然，您可能会认为微软偷走了Java的想法。” 但这不是真的，微软启发了她！ -（摘自Microsoft代表在Windows 2003 Server演示中的演讲）

从奇怪的时刻开始，可以注意到，在Microsoft内部，零度使用专有虚拟化产品是可以选择的。 虚拟化文章中有Technet的屏幕截图，其中托盘中清楚地显示了VMware Tools徽标。 此外，2009年莫斯科平台的Mark Russinovich用VMware Workstation进行了演示。

为了进入新市场，Microsoft使用高度修改的Nano Server（具有Hyper-V，S2D和SDN支持）创建了自己的公共云Azure。 值得注意的是，最初，Azure在某些方面远远落后于本地系统。 例如，仅在2018年，Azure中才出现了对第二代虚拟机的支持（支持安全启动，从GPT分区启动，PXE引导等）。 在内部部署中，自Windows Server 2012R2开始就已知第二代VM。 门户解决方案也是如此：直到2017年，Azure和Windows Azure Pack（具有SDN和Shielded VM支持的多租户云解决方案，于2013年取代System Center App Controller）都使用了相同的门户设计。 微软宣布在公共云上开设一门课程之后，Azure向前发展并实施了各种专有技术。 在2016年左右，您可以观察到一个完全合乎逻辑的情况：现在Windows Server中的所有创新都来自Azure，但并非相反。 将部分文档“按原样”从Azure复制到内部部署的事实表明了这一点（请参阅Azure SDN和Network Controller上的文档），这一方面表明了对内部部署解决方案的态度，另一方面表明了解决方案之间的关系在实体和架构方面。 谁从谁那里抄袭了，这到底是怎么回事，这是一个有争议的问题。

2018年3月，微软首席执行官萨蒂亚·纳德拉（Satya Nadela）正式宣布，公共云正在成为公司的优先事项。 显然，这象征着本地产品的服务器系列的逐渐折叠和褪色（但是，早在2016年就出现了停滞状态，但首个Windows Server beta版和其他本地产品系列已得到确认），但Azure Edge是最低要求的服务器客户办公室中用于无法带到云的服务的基础架构。

虚拟铁

Virtual Iron成立于2003年，提供了Xen的商业版本，并且是最早向市场提供完整的硬件虚拟化支持的公司之一。
在2009年，Oracle被接管来开发自己的虚拟化Oracle VM系列并在x86上进行扩展。在此之前，Oracle VM仅在SPARC平台上提供。

Innotek

在2007年初，Innotek GmbH发布了第二种专有的桌面虚拟机管理程序VirtualBox，该软件可免费用于非商业用途。同年，发布了一个开源版本。

在2008年，它被Sun收购，随后又被Oracle收购。 Oracle保留免费使用该产品用于非商业目的。
VirtualBox支持三种格式的虚拟磁盘-VDI（本机），VMDK（VMware），VHD（Microsoft）。作为主机操作系统，支持Windows，macOS，Linux，Solaris和OpenSolaris。 VirtualBox for FreeBSD的分支是已知的。

伊本

大型机是数据中心的主计算机，具有大量的内部和外部内存（供参考：在60年代，认为1MB的内存过大）。实际上，大型机是一个计算中心：最初的计算机占据了整个机房，并由巨大的机架组成。如今，它被称为数据中心。但是在同一机房的数据中心中可以有数千台计算机，而在计算技术兴起之初，一台计算机占据了整个房间。每个机架出售一台（！）计算机设备（带有内存的单独机架，带有存储设备的单独机架以及单独的外围设备）。这台巨大机器的核心是带有处理器的机架-被称为主机或大型机。切换到晶体管集成电路后，这种科学和工程思想奇迹的规模大大缩小，IBM大型机及其类似物开始被理解为大型机。

在20世纪60年代，整个大型机的计算能力租赁，更不用说购买它，花费了很多钱。很少有公司和机构能够负担得起这种奢侈品。租用计算功能每小时进行一次（现代的现收现付模型在公共云中的原型，不是吗？）。顺序允许访问租户进行计算。合理的解决方案是并行化计算负担，并使租户的计算彼此隔离。

IBM剑桥科学中心首次基于IBM System / 360-67大型机提出了在一个大型机上隔离多个操作系统实例的想法。该开发称为CP / CMS，实际上是第一个虚拟机监控程序，提供了半虚拟化。 CP（控制程序）-虚拟机管理程序本身，它创建了多个独立的“虚拟机”（VM）。 CMS（最初为Cambridge Monitor System，后来更名为Conversational Monitor System）是一种轻量级的单用户操作系统。奇怪的是，CMS仍然存在，并且仍在最新一代的z / VM大型机中使用。值得注意的是，在当时和90年代以前，虚拟机意味着逻辑上的物理磁盘分离（磁盘或存储设备是共享的，虚拟机管理程序没有使用自己的需求提供存储）以及使用分时技术的专用虚拟内存和处理器时间。 VM不提供网络交互，因为当时的VM与计算和存储数据有关，而不是与传输它们有关。从这个意义上讲，当时的VM更像是容器，而不是现代意义上的VM。

1972年8月2日，第一个基于CP / CMS的商业化虚拟机管理程序（称为VM / 370）出现在System / 370系列大型机上。该系列操作系统的总称是VM，作为本节的一部分，VM将被理解为IBM虚拟机管理程序。同时运行多个操作系统，确保系统稳定性和将用户彼此隔离（一个用户的操作系统错误不会影响另一用户的计算）的能力是革命性的，并成为VM / 370商业成功的关键因素。一个奇怪的事实：当时在苏联，计算机科学科学研究所（明斯克）的努力非常成功地克隆了System / 370体系结构，并以欧盟计算机的名义创建了自己的模拟VM / 370（支持嵌入式虚拟化！-有可能开发最基本的OS）。这样的大型机被社会主义阵营的研究机构和国防企业所使用。

80年代可以安全地称为“大型机时代”。 VM是操作系统开发人员的成功之举，为此编写了应用程序并进行了计算。在这十年中，由VM OS主导的数据库份额开始在大型机中占据主导地位。最重要的更改之一是逻辑分区访问资源（LPAR），它实际上提供了两个虚拟化级别。客户端现在可以在不同LPAR中运行的VM系统中使用同一组处理器，I / O设备和调制解调器，并允许将资源从一个VM系统迁移到另一个VM系统。这使IT组织可以在处理工作负载高峰时提供一致的性能。为了简化不断增长的客户群，VM被分为三个独立的产品，80年代末可用：

VM / SP-System z服务器的常用多用途虚拟化操作系统
HPO（高性能选件）-适用于较旧System z服务器模型的高性能VM / SP
VM / XA（扩展体系结构）-支持扩展S / S体系结构的VM变体370

在90年代初，x86架构的简单性和便利性对客户越来越有吸引力，并且大型机迅速失去了相关性。大型机已被集群系统取代，例如grunge，它们同时取代了华丽的金属。但是，对于某些类别的任务，例如，在构建集中式数据仓库时，大型机在生产率和经济角度上都证明了自己的合理性。因此，一些企业仍在其基础架构中使用大型机，而IBM设计，发布和支持新一代产品。

Linux Xen

Xen（发音为zen）是在Ian Pratt的指导下在剑桥大学计算机实验室开发的虚拟机管理程序，并根据GPL进行分发。第一个公开版本出现在2003年。随后，Ian继续开发其商业版本的虚拟机监控程序，从而建立了XenSource公司。
在2013年，Xen受到Linux Foundation的控制。

XenSource的

XenServer和XenEnterprise产品已经在市场上存在了几年，于2007年底被Citrix收购。

思杰XenServer

思杰以5亿美元的价格收购了XenSource，因此无法将其商业化。更准确地说，我并没有真正尝试这样做，没有将XenServer作为主要产品，而是依靠永久许可证的廉价性。在非常成功的VMware ESX中，坦率地说销售不成功之后，它决定于2009年将XenServer免费和完全开源地发布到世界上。但是，XenCenter专有管理系统代码未打开。
值得一提的是，尽管思杰和微软在工业虚拟化领域的关系一直很密切，但它们在时间上却是有趣的巧合。

Citrix XenApp和XenDesktop尽管有通用的市场名称，但与Xen虚拟机管理程序无关。

亚马孙

亚马逊于2006年推出了名为EC2（弹性计算）的公共IaaS云产品。最初，EC2平台使用Xen虚拟机管理程序，随后Amazon将平台分为三个部分，每个部分都使用虚拟机管理程序的单独分支和版本，以最大程度地减少代码错误对服务可用性的影响。

2017年，用于重载的KVM作为EC2中的附加虚拟机监控程序出现。有意见认为，这表明将来EC2会逐渐完全转移到KVM。

Linux QEMU / KVM

QEMU（快速仿真器）是一种通用软件，用于仿真各种平台的硬件，并根据GPL v2许可进行分发。除了x86，还支持ARM，MIPS，RISC-V，PowerPC，SPARC，SPARC64。由于具有完全虚拟化的平台的多功能性，QEMU缺乏与非虚拟化系统相当的性能。为了加快QEMU在x86上的工作，提供了两个主要选项，但最终被Qumranet的KVM（基于内核的虚拟机）开发所拒绝。

我们说的是KVM-我们的意思是QEMU KVM，因此，我们获得了基于KVM虚拟机管理程序的所有平台的qcow2虚拟磁盘格式（QEMU写时复制2）。
尽管QEMU最初是作为第二类型的管理程序，但QEMU / KVM是第一类管理程序。

Qumranet

一家以色列公司，曾是KVM虚拟机管理程序和SPICE协议的开发商和主要赞助商。该公司成立于2005年，在将KVM集成到Linux内核中后声名fa起。 2008年9月4日，被Red Hat收购。

红帽子

像所有GNU / Linux发行版制造商一样，直到2010年，Red Hat在其发行版中都内置了对Xen虚拟机管理程序的支持。但是，作为市场的主要参与者和重要的品牌，我考虑了自己对虚拟机监控程序的实施。然后，基于不起眼但很有前途的KVM虚拟机管理程序作为基础。红帽企业虚拟化2.2（RHEV）的第一版于2010年推出，该产品声称是由于Qumranet的发展而与Citrix和VMware竞争VDI解决方案市场的一部分，而后者是两年前被收购的。现成可用的高可用性群集，实时迁移和M2M迁移工具（仅RHEL）可用。值得注意的是，从当时的文档来看，Red Hat在描述解决方案体系结构时保留了Xen表示法。

2018年10月28日，IBM宣布购买Red Hat。

开栈

从历史上看，OpenStack项目的出现是为了与VMware在x86重型服务器虚拟化领域的实际垄断形成对比。该项目于2010年出现，这要归功于Rackspace Hosting（一个云提供商）和NASA（为其自己的Nebula平台打开了代码）的共同努力。这种情况很糟糕的原因是，VMware在2012年加入了OpenStack项目管理，并在创始活动家之间引起了一阵愤慨。

随着时间的推移，Canonical（Ubuntu Linux），Debian，SUSE，Red Hat，HP，Oracle加入了该项目。

但是，并非一切都顺利。2012年，NASA离开了该项目，选择了AWS。2016年初，HPE完全关闭了基于OpenStack的Helion项目。

作为OpenStack项目的一部分，KVM已被用作标准虚拟机管理程序。但是，由于该方法的模块化，因此可以使用其他虚拟机管理程序来实现基于OpenStack的系统，例如，仅剩下来自OpenStack的控制系统。

关于OpenStack项目，有各种各样的见解，从热情的崇拜到严重的怀疑和苛刻的批评。批评并非没有道理-使用OpenStack时记录了许多问题和数据丢失。但是，这并不能阻止风扇拒绝一切并提及系统的实现和操作中的曲率。

OpenStack项目不仅限于虚拟化，而且随着时间的推移，已经成长为大量的各种子项目和组件，用于在公共云服务堆栈领域进行扩展。此外，OpenStack的重要性可能应该在本部分中进行精确评估-这些组件已成为虚拟化领域以及其他领域的许多商业产品和系统中的关键。

在俄罗斯，公共云之外的OpenStack主要以其在替代进口产品中的作用而闻名。OpenStack打包了绝大多数虚拟化解决方案和产品（包括超融合系统），并进行了不同程度的改进。

Nutanix AHV

自成立以来，Nutanix一直是专门用于VMware vSphere的产品和平台。但是，部分原因是希望扩展对其他虚拟机监控程序的报价，部分是由于与VMware关系的政治危机，因此决定开发自己的虚拟机监控程序，这将完善盒装平台并允许放弃第三方产品。选择了KVM作为其自己的虚拟机管理程序，该虚拟机管理程序在平台框架内称为AHV（Acropolis HyperVisor）。

平行线

在Virtuozzo的版本7中，该公司从其自己的虚拟机管理程序切换到KVM。

Proxmox

Proxmox VE（虚拟环境）是奥地利公司Proxmox Server Solutions GmbH基于Debian Linux的开源项目。第一次发布是在2008年。
该产品支持LXC容器虚拟化（以前称为OpenVZ），并通过KVM虚拟机管理程序进行完全虚拟化。

平行/ Virtuozzo / Rosplatform

SWsoft由Sergey Belousov于1999年成立，负责托管管理软件。 2003年，新西伯利亚的竞争对手Plesk被收购。

2004年，SWsoft收购了俄罗斯公司Parallels Nikolai Dobrovolsky及其产品Parallels Workstation（Windows下的第二种台式机管理程序）。
合并后的公司保留了其Parallels的名称，并将很快通过Parallels Desktop for Mac（MacOS的第二种桌面虚拟机管理程序）来开拓市场。

作为服务器虚拟化的一部分，重点继续放在托管提供商和数据中心上，而不是企业使用上。由于该特定市场的特点，Virtuozzo和OpenVZ容器而不是系统虚拟机成为了关键产品。随后，Parallels尝试使用Parallels Bare Metal Server产品（随后是Parallels Hypervisor和Cloud Server，然后是Virtuozzo）进入企业服务器虚拟化市场，但收效甚微，并为其云存储增加了超融合性。托管提供商的自动化和编排工作仍在继续。

2015年，在服务器虚拟化产品的基础上，创建了Rosplatform平台项目-从技术上（从法律和组织方面出发）相同的Virtuozzo，仅具有经过修改的墙纸并且在俄罗斯软件注册中心中。基于Rosplatform平台软件和Depo设备，IBS创建了Scala-R软件包超融合产品。

在版本7之前，Virtuozzo使用了自己设计的管理程序；在版本7中，过渡到了KVM。因此，Rosplatform也基于KVM。
在几次合并，收购和品牌重塑之后，下一张图片将在2019年形成。

Parallels Desktop是Parallels的子公司，并出售给Corel。所有的自动化都交给了Odin，然后卖给了IngramMicro。服务器虚拟化仍属于Virtuozzo / Rosplatform平台品牌。