长期以来，Maxnet Systems公司一直使用从版本5.0开始的免费版本的VMware-ESXi作为管理程序。 vSphere的付费版本消除了许可模式，而免费版本具有许多缺点，这些缺点在付费版本中不可用，但是您可以忍受。 但是，当在新版本的ESXi中，新的Web界面拒绝使用旧的Web界面，并且对RAID阵列的监视不再显示出生命迹象时，该公司决定寻求一种更通用和开放的解决方案。 该公司已经对LXC（Linux容器）具有良好的经验和良好的印象。 因此，显而易见的是，梦想中的系统管理程序将是混合的，并且可以将KVM和LXD组合在一起以适应不同的负载-LXC的进化延续。 在寻找有关KVM的信息时，该公司面临着误解，耙子和有害做法，但经过测试和时间，一切都准备就绪。
关于如何应对从ESXi到KVM的迁移，而不是一
ke而就 ，将告诉
Lev Nikolaev （
疯子 ）-高负载系统的管理员和开发人员，信息技术培训师。 让我们谈谈网络，存储库，容器，KVM，LXD，LXC，资源调配和便捷的虚拟机。
序言
我们将立即识别关键思想，然后将对其进行更详细的分析。
网络。 尽管接口的速度不超过1 Gb / s，但桥接足以满足您的需求。 一旦您想榨出更多的东西-它就会限制您。
仓库。 创建一个共享的网络存储。 即使您尚未准备好在网络内部使用10 Gbit / s，甚至1 Gbit / s也将为您提供125 MB / s的存储空间。 对于许多负载而言，这几乎是足够的，虚拟机的迁移将是基本问题。
容器还是KVM？ 利弊，陷阱。 哪种类型的负载最好放置在容器中，哪种类型的负载最好留在KVM中？
LXD或LXC 。 是LXD LXC吗？ 还是其他版本？ 还是附加组件？ 这是怎么回事？ 让我们消除神话，了解LXD和LXC之间的区别。
方便的供应 。 哪个更方便：每次拍摄相同的映像或从头开始安装系统？ 每次如何快速准确地做到这一点？
方便的虚拟机。 有关引导加载程序，分区和LVM的故事将非常恐怖。
杂项 。 许多小问题：如何快速将虚拟机从ESXi拖到KVM，如何良好迁移，如何正确虚拟化磁盘？
搬迁原因
从ESXi迁移到KVM / LXD的疯狂想法从何而来？ ESXi在中小企业中很受欢迎。 这是一个好又便宜的虚拟机管理程序。 但是有细微差别。
我们从5.0版开始-方便，一切正常！ 下一版本5.5相同。
从6.0版开始，它已经变得更加困难。 在ESXi上，在需要Windows实用程序之前，Web界面并没有立即从6.5版开始免费。 我们对此表示赞同。 运行OS X的人会购买Parallels并安装此实用程序。 这是众所周知的痛苦。
监控定期闪烁。 必须在服务器控制台中重新启动管理服务-然后CIM Heartbeat再次出现。 我们忍受着，因为他并不总是跌倒。
ESXi 6.5版本-垃圾，废物和暴行。 糟糕的管理程序。 这就是为什么。
- Angular在Web界面的入口处掉了一个例外。 一旦输入用户名和密码-立即例外！
- 远程监视RAID阵列状态的功能不起作用，因为它对我们很方便。 以前很方便，但是在6.5版中，一切都很糟糕。
- 英特尔对现代网卡的支持较弱 。 来自Intel和ESXi的网卡会引起痛苦。 ESXi支持论坛上有一个与此有关的痛苦话题。 VMware和Intel不是朋友，并且关系在不久的将来不会改善。 可悲的是，即使是付费解决方案的客户也会遇到问题。
- ESXi内无迁移 。 除非迁移被视为暂停，否则请复制并启动过程。 我们将汽车置于暂停状态，快速将其复制并在其他地方启动。 但是，将其称为迁移是不可能的-仍然很简单。
看完所有这些内容后，我们有了使用ESXi 6.5的疯狂想法。
愿望清单
首先，我们写了一个愿望清单，列出了我们要实现的理想未来。
通过SSH和Web进行管理以及更多可选操作。 Web界面很棒，但是在使用iPhone出差时，转到ESXi Web界面并执行某些操作并不方便且困难。 因此，管理所有内容的唯一方法是SSH，没有其他方法。
Windows虚拟化。 有时，客户要求提供奇怪的东西，而我们的使命是帮助他们。
始终提供最新的驱动程序和配置网卡的能力 。 足够的愿望，但是在纯ESXi下无法实现。
实时迁移，而不是集群 。 我们希望能够将计算机从一个虚拟机管理程序拖到另一个虚拟机管理程序，而又不会感到任何延迟，停机或带来任何不便。
愿望清单已经准备好，然后开始困难的搜索。
选择的面粉
市场围绕着具有不同调味料的KVM或LXC。 有时候Kubernetes似乎在上面的某个地方，那里一切都很好，阳光和天堂，在下面的水平还有Morlocks-KVM，Xen或类似的东西...
例如，Proxmox VE是Debian，它是由Ubuntu的内核提取的。 看起来很奇怪，但是它能投入生产吗？
楼下的邻居是Alt Linux。 他们提出了一个漂亮的解决方案：他们将Proxmox VE打包在一起。 他们只是将软件包放在一个命令中。 这很方便，但是我们不会将Alt Linux投入生产，因此不适合我们。
拿KVM
最后，我们选择了KVM。 他们不愿意这样做，例如Xen，因为社区的存在-KVM还有更多功能。 似乎我们总能找到问题的答案。 后来我们发现，社区的规模并不影响社区的质量。
最初，我们计算出将使用Bare Metal机器，添加正在使用的Ubuntu，然后从上方滚动KVM / LXD。 我们依靠运行容器的能力。 Ubuntu是一个著名的系统，在解决启动/恢复问题方面毫不奇怪。 如果管理程序未启动，我们知道该踢哪儿。 一切对我们来说都很清楚方便。
KVM速成课程
如果您来自ESXi，那么您会发现很多有趣的事情。 学习三个词：QEMU，KVM和libvirt。
QEMU将虚拟化OS的愿望转化为常规流程的挑战。 几乎在任何地方都有效，但速度缓慢。 QEMU本身是独立的产品，可虚拟化许多其他设备。
现场还有一堆
QEMU-KVM 。 这是QEMU的Linux内核模块。 虚拟化所有指令非常昂贵，因此我们有一个KVM内核模块，该模块
仅转换少量指令 。 结果，这将大大加快速度，因为只处理了通用集中的百分之几的指令。 这就是虚拟化的全部成本。
如果只有QEMU，则无需绑定即可启动虚拟机，如下所示：
$ qemu < >
在描述网络的参数中，阻止设备。 一切都很棒，但是不方便。 因此，存在libvirt。
libvirt的目标是成为所有管理程序的单一工具 。 它可以与任何东西一起工作：与KVM，与LXD。 似乎仅学习libvirt的语法仍然存在，但实际上它的工作原理比理论上差。
这三个词是在KVM中引发第一个虚拟机所需要的。 但同样，有细微差别...
Libvirt具有用于存储虚拟机和其他设置的配置。 它将配置存储在xml文件中-从90年代开始就非常时尚，流行。 如果需要，可以手动编辑它们，但是为什么，如果有方便的命令。 同样方便的是，对xml文件的更改具有出色的版本控制。 我们使用
etckeeper-版本目录等 已经可以使用etckeeper了，现在是时候了。
LXC速成课程
关于LXC和LXD有许多误解。
LXC是现代内核使用名称空间的能力-假装它根本不是它原来的核心。
您可以为每个容器创建任意数量的名称空间。 形式上，核心是一个，但是它的行为就像许多相同的核心。 LXC允许您运行容器，但仅提供基本工具。
落后于Ubuntu并积极推动容器向前发展的Canonical发布了
LXD（类似于libvirt） 。 这是一个绑定，可以更轻松地运行容器，但是内部仍然是LXC。
LXD是基于LXC的容器管理程序。
企业在LXD中占统治地位。 LXD将配置存储在其数据库中-目录
/var/lib/lxd 。 在那里，LXD将其配置引至SQlite中的配置。 复制它没有任何意义，但是您可以记下用于创建容器配置的命令。
并没有这样的卸载，但是大多数更改是由团队自动执行的。 这是Docker文件的类似物，仅具有手动控制。
生产量
我们所有人航行时所面对的是什么。
联播网
关于KVM中的网络，互联网上有多少令人讨厌的事情！ 90％的材料说使用桥。
停止使用网桥！
他怎么了 最近，我感觉到容器正在发生混乱：将Docker置于Docker之上，以便您可以在观看Docker的同时在Docker中运行Docker。 大多数人不了解桥梁在做什么。
它将您的网络控制器置于
混杂模式，并接收所有流量，因为它不知道哪个流量，哪个流量不知道。 结果，所有的网桥流量都经过一个出色的，快速的网络Linux堆栈，并且进行了大量复制。 最后，一切都是缓慢而糟糕的。 因此，请勿在生产中使用电桥。
SR-IOV
SR-IOV是在网卡内进行虚拟化的能力 。 网卡本身能够为虚拟机分配其自身的一部分，这需要一些硬件支持。 这将防止迁移。 迁移缺少SR-IOV的虚拟机很痛苦。
SR-IOV应该在所有虚拟机管理程序支持的迁移中使用。 如果没有，那么macvtap适合您。
macvtap
这适用于那些网卡不支持SR-IOV的用户。 这是网桥的简化版本：一张网卡上挂有不同的MAC地址，并使用了
单播过滤 ：该网卡不接受所有内容，而是严格按照MAC地址列表进行操作。
在Toshiaki Makita
的精彩演讲
，虚拟交换技术和Linux Bridge中可以找到更多的血腥细节。 他充满痛苦和折磨。
90％的关于如何在KVM中建立网络的资料都是无用的。
如果有人说Bridge非常棒，请不要再与该人交谈。
使用macvtap，由于减少了副本，
CPU节省了大约30％ 。 但是混杂模式有其细微差别。 您无法从管理程序本身-从主机连接到来宾计算机的网络接口。 Toshiaki的一份报告对此进行了详细说明。 但总而言之-它不起作用。
从虚拟机管理程序很少使用SSH。 在此处启动控制台更为方便，例如Win-console。 可以“监视”接口上的流量-您无法通过TCP连接，但是管理程序上的流量是可见的。
如果您的速度超过1千兆位-选择macvtap。
在接口速度高达每秒1吉比特或大约1吉比特的情况下，也可以使用网桥。 但是，如果您有10 Gb网卡，并希望以某种方式处理它，则仅保留macvtap。 没有其他选择。 SR-IOV除外。
系统联网
这是在管理程序本身上存储网络配置的好方法 。 在我们的例子中，这是Ubuntu，但对于其他系统，systemd可以工作。
我们曾经有一个文件
/etc/network/interfaces ，我们都保存在其中。 每次都难以编辑一个文件-systemd-networkd允许您将配置拆分为多个小文件。 这很方便，因为它可与任何版本控制系统一起使用：它已发送到Git，您可以看到何时以及发生了什么更改。
我们的网络人员发现了一个缺陷。 当您需要在管理程序中添加新的VLAN时，我去配置。 然后我说：“ systemctl重新启动systemd-networkd”。 目前，一切都很好，但是如果引发了来自此计算机的BGP会话，则它们会中断。 我们的网络人员不同意这一点。
对于虚拟机监控程序，没有任何不好的事情发生。 Systemd-networked不适合边界边界，BGP较高的服务器和虚拟机管理程序-非常好。
系统联网远非最终的，永远不会完成。 但这比编辑一个大文件更方便。 在Ubuntu 18.04中，systemd-networked的替代方法是Netplan。 这是一种配置网络并踩踏耙子的“酷”方法。
网络设备
在虚拟机管理程序上安装KVM和LXD之后，您将看到的第一件事是两座桥。 一台是自己制作的KVM，另一台是LXD。
LXD和KVM正在尝试部署其网络。
如果您仍然需要一座桥（用于测试机器或进行游戏），请杀死该桥（默认情况下已打开并创建您自己的桥），这是您想要的。 KVM或LXD很难做到这一点-滑dnsmasq，然后恐怖开始了。
贮藏
不管您喜欢哪种实现，都可以使用共享存储。
例如，用于虚拟机的iSCSI。 您不会摆脱“故障点”，但可以
在一个点上合并存储 。 这开辟了新的有趣机会。
为此，数据中心内必须至少有10 Gb / s接口。 但是，即使您只有1 Gbit / s，也不必担心。 这大约为125 MB / s-对于不需要高磁盘负载的虚拟机管理程序来说非常好。
KVM可以迁移和拖动存储。 但是，例如，在工作负载模式下，将虚拟机转移到几个TB上是很痛苦的。 对于使用公共存储的迁移，仅RAM是基本的。 这样
可以减少迁移时间 。
最后，LXD还是KVM？
最初，我们假设对于内核与主机系统匹配的所有虚拟机，我们将采用LXD。 在我们需要采用其他核心的地方-采用KVM。
实际上，这些计划没有成功。 要了解原因，请仔细研究LXD。
尺寸
主要优点是节省了内核上的内存。 内核是相同的，并且当我们启动新容器时，内核是相同的。 在此，利弊结束，利弊开始。
必须安装具有rootfs的块设备。 这比听起来难。
确实没有迁移 。 它基于我们的同胞看到的奇妙的阴沉仪器criu。 我为他们感到骄傲，但在简单的情况下criu无效。
zabbix-agent在容器中的行为异常 。 如果在容器中运行它，那么您将看到来自主机系统而不是容器的一系列数据。 到目前为止，无能为力。
查看虚拟机管理程序上的进程列表时，无法快速了解特定进程从哪个容器中增长 。 花时间找出那里有什么名称空间，什么地方。 如果某处的负载比平常跳得更多，那么很快就无法理解。 这是主要问题-响应能力的限制。 针对每种情况进行一次小型调查。
LXD的唯一优点是节省核心内存并减少开销。
但是KVM中的内核共享内存已经节省了内存。
到目前为止，我认为没有理由引入认真的生产和LXD。 尽管Canonical在该领域已尽了最大努力，但LXD的生产带来的问题多于解决方案。 在不久的将来情况不会改变。
但是，不能说LXD是邪恶的。 他很好，但在少数情况下，我将在稍后讨论。
u
Criu是一种令人沮丧的实用程序。
创建一个空容器，它将与DHCP客户端一起到达并告诉它：“挂起！” 收到错误消息是因为有一个DHCP客户端：“恐怖，恐怖！ 他用“ raw”符号打开插座-真是一场噩梦！” 更糟的地方。
容器的印象：无需迁移，Criu每隔一段时间就会工作。
我“喜欢” LXD团队的建议，该如何处理Criu，这样就不会出现问题：
-
从存储库中获取较新的版本！而且我可以以某种方式从包中放入它，以免运行到存储库中吗？
结论
如果您要创建CI / CD基础结构，LXD很棒。 我们使用LVM-逻辑卷管理器，从中创建快照，然后在其上启动容器。 一切正常！ 其次，创建一个新的干净容器，该容器用于测试和滚动厨师-我们正在积极使用它。
LXD不足以进行大量生产 。 如果LXD运作不正常，我们无法弄清楚该如何处理生产中的LXD。
选择KVM，仅选择KVM！迁移
我会简单地说一遍。 对我们来说，迁移是一个我们喜欢的美好新世界。 那里的一切都很简单-有一个迁移团队和两个重要选项：
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
如果您在Google中输入“ KVM迁移”并打开第一个材料，则会看到一个迁移命令，但没有最后两个键。 您不会看到它们很重要的提示：“只需执行此命令！” 运行命令-它确实可以迁移，但是仅如何迁移？
重要的迁移选项。
undefinesource-从我们要从其迁移的虚拟机管理程序中删除虚拟机。 如果您在进行了这样的迁移后重新启动，则剩下的虚拟机管理程序将重新启动该计算机。 您会感到惊讶，但这是正常的。
没有第二个参数-持久-移动到的虚拟机管理程序根本不会将其视为永久迁移。 重新引导后，系统管理程序将不记得任何内容。
- virsh dominfo <vm> | grep persistent
没有此参数，虚拟机将在水面上旋转。 如果第一个参数没有指定第二个参数，则猜测会发生什么。
KVM有很多这样的时刻。
- 网络：他们总是向您介绍桥梁-这是一场噩梦！ 您阅读并认为-怎么回事？
- 迁移：他们也不会说任何可理解的东西，直到您撞到这堵墙。
从哪里开始？
要迟到-我在说别的事情。
设置：如何部署
如果您对标准安装选项感到满意，那么预装的机制就很好。
在ESXi下，我们使用了virt-install。 这是部署虚拟机的常规方法。 可以方便地创建一个预置文件，在其中描述Debian / Ubuntu的映像。 通过向其提供ISO分发工具包和预设文件来启动新机器。 然后，汽车自动滚动。 您通过SSH连接到该服务器，将其挂接到厨师上，滚动Cookie-就这样，赶紧去生产！
但是，如果您有足够的virt-install，我有个坏消息。 这意味着您还没有想做其他事情的阶段。 我们结束了，意识到仅安装virt-install还不够。 我们来到了一个“黄金映像”，我们克隆并启动了虚拟机。
以及如何安排虚拟机？
我们为什么来到这个形象？为什么供应很重要？ 因为在社区中仍然缺乏了解，因此虚拟机与常规计算机之间存在很大差异。
虚拟机不需要复杂的引导过程和智能引导加载程序 。 将虚拟机的磁盘连接到具有完整工具集的计算机要比在恢复模式下尝试离开某个地方容易得多。
虚拟机需要简化设备 。 为什么在虚拟磁盘上需要分区？ 人们为什么要带一个虚拟磁盘并在其中放置分区而不是LVM？
虚拟机需要最大的可扩展性 。 通常，虚拟机会增长。 这是一个“很酷”的过程-增加MBR中的分区。 您删除了它，这时擦了擦额头上的汗水，然后想：“现在就不写，就不写！” -并使用新参数重新创建。
LVM @ lilo
结果，我们来到了LVM @ lilo。 这是一个引导加载程序，可让您从单个文件进行配置。 如果要编辑GRUB配置，您正在编辑一个特殊的文件，该文件控制模板引擎并构建怪异的boot.cfg，然后使用Lilo-一个文件，仅此而已。
无分区LVM使系统变得完美而轻松。 问题在于GRUB不能没有MBR或GPT，它会冻结。 我们告诉他：“ GRUB在这里定居，”但他不能，因为没有分区。
LVM使您可以快速扩展并进行备份。 标准对话框：
-伙计们，您如何进行虚拟备份？-...我们带一个块设备并复制。-您是否尝试重新部署？-恩，不，一切对我们有用！您可以随时在虚拟机中舔块设备，但是如果有文件系统，则其中的任何记录都需要进行三个动作-此过程不是原子的。
如果要从内部对虚拟机进行快照，则该虚拟机可以与文件系统对话，从而使其达到所需的一致状态。 但这并不适合所有情况。
如何建立一个容器？
要启动和创建容器，模板中包含常规工具。 LXD提供了Ubuntu 16.04或18.04模板。 但是，如果您是高级战斗机，并且不想使用常规模板，而是可以自定义的自定义rootfs，则会出现问题：如何在LXD中从头开始创建容器？
从头开始的容器
准备rootfs 。 Debootstrap将对此提供帮助：我们说明需要哪些软件包，哪些不需要，然后安装。
向LXD解释我们要从特定的rootfs创建一个容器 。 但首先，使用简短命令创建一个空容器：
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
它甚至可以自动化。
一个有思想的读者会说-rootfs我的容器在哪里？ 它在哪里指示？ 但是我没有说完这些！
我们将容器的rootfs挂载到该容器中。 然后，我们指示rootfs容器将位于此处：
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
同样，这是自动化的。
容器寿命
容器没有自己的内核 ，因此加载起来更容易
： systemd，init和flight！
如果您不使用常规工具来使用LVM，则在大多数情况下，要启动容器，您将需要在管理程序中挂载容器rootfs。
有时，我会找到有关建议autofs的文章。 不要这样做。 Systemd具有自动安装的单位，但autofs没有。 因此，可以并且应该使用systemd自动安装单元，但是autofs不值得。
结论
我们喜欢带有迁移功能的KVM 。 借助LXD，这还没有实现，尽管为了测试和构建基础架构，我们在没有生产负荷的情况下使用了它。
我们喜欢KVM的性能 。 看起来比较熟悉，看到与该虚拟机相关的流程，并了解我们在做什么和做什么。 这比使用带有容器的奇怪工具集更好地找出水下撞击的类型要好。
我们对迁移感到高兴。 这主要是由于共享存储。 如果我们通过拖动磁盘进行迁移，我们不会很高兴。
如果您像Leo一样准备讨论如何克服操作，集成或支持方面的困难，那么现在是时候向秋季DevOpsConf会议提交报告了。 我们程序委员会的成员将帮助准备与此相同的鼓舞人心且有用的演示文稿。
我们没有等待征集论文的截止日期，并且已经接受了会议计划的几份报告。 订阅新闻通讯和电报频道，并随时了解有关DevOpsConf 2019筹备工作的最新消息，不要错过新文章和视频。