移动云操作系统改造技术实践分享
近年来，linux 操作系统在技术、社区和商业化方案均取得了快速发展，移动云先后发布了新一代天元操作系统和易行迁移工具，保障了移动云全场景业务高效迁移。在移动云 centos 迁移实践过程中，跨操作系统虚机迁移是改造中的一个重要环节，现网环境错综复杂，如何保证客户业务在虚机迁移过程不中断，确保迁移后的虚机在 linux 操作系统上平稳运行，在底层虚拟化侧面临诸多技术挑战。
关键挑战
虚拟化组件同源异构
新的虚拟化组件需要在多款 linux 操作系统上稳定运行，在不同操作系统和 cpu 架构上共用同一份源码，因此首先需要解决同源异构难题。
os 兼容适配
计算、存储、sdn 等核心业务需要在 os 之上相互兼容，在新的平台上需要在中间层即虚拟化层解决一些业务兼容适配问题。
跨 os 不停服热迁移
跨操作系统、跨虚拟化组件大版本的迁移，可能因虚机 cpu 能力、内存布局、设备结构体等差异，导致迁移失败影响业务连续性，这是虚机跨操作系统迁移过程中的一大难题。
虚拟化组件同源异构
同源异构可以屏蔽不同系统、不同架构的差异，收缩现网版本，减小代码维护的压力。实现“一份代码，一次编译，处处运行”。
在同源异构改造过程中我们解决了诸多问题，如：不同系统、不同架构其编译安装依赖包会有差异，需要在 spec 文件中根据不同系统、架构指定相应的依赖。新旧虚拟化组件软件包安装时存在冲突，需利用 rpm 的 obsoletes 机制删除对应安装包，实现组件的平滑升级。另外由于新旧虚拟化组件差异大，导致旧版补丁回合后函数调用失败，需要根据代码差异重新设计实现部分功能。
os 兼容适配
为了保证虚机能在 os 上平稳运行，需要解决一些计算、存储、sdn 同虚拟化组件在平台上适配存在的问题，并做一些优化。
python2 版本的兼容
随着 python2 的生命周期结束，libvirt-python 自 6.0.0 就停止了对 python2 的支持，但由于部分产品改造周期长，需要暂时维持使用 python2 环境作为过渡，虚拟化作为底层组件，需要构建一个基于 python2 的 libvirt-python 组件包。 我们从 python3 和 python2 间语法差异、接口改变、模块变化等方面入手，对适配 os 上的 libvirt-python 代码做了修改，包括：
针对数据类型、类的定义等语法差异上做了对应修改。
针对异常捕获、输入输出、迭代器等 api 使用差异部分做了对应修改。
针对 python3 和 python2 间名称变化或废弃的模块做了对应修改。
在修改了 50 多个文件，上千行代码后，最终得到了一个基于 python2 的稳定可靠的 libvirt-python。
ovs-dpdk 与 qemu 的适配
sdn 的稳定性和可靠性直接影响到用户虚机的网络服务质量，为了保证 sdn 能在新平台上平稳运行，我们积极推动各 sdn 厂商在 os 上的适配工作，解决了多个适配问题。
sdn 适配时发现当 qemu 作为 server 时，重启 ovs，虚机可能会 crash。查看 qemu 的 coredump 文件,定位到如下代码触发了 crash。
当 qemu 作为 server 端时，一旦 ovs 重启，按照上面代码逻辑 qemu 会主动尝试进行 reconnect，过程中会改变网卡设备 tcp 状态字为 tcp_chardev_state_disconnected，此时会造成处理逻辑 bug，使得 qemu 发生 crash（实际上 qemu 作为 server 端时，不应进行 reconnect 操作，而是由作为 client 端的 ovs 进行 reconnect）。具体触发 crash 的流程如下：
解决方案是只有当 qemu 作为 client，重启 ovs,qemu 才做 reconnect，问题得到修复。 除上述问题外，我们还解决了一些其他问题，包括 ovs 热升级后 windows 虚机网络不通、海光平台执行 testpmd 测试程序虚机卡住等多个问题。
卷迁移操作的效率优化
分布式存储为云平台提供基础存储服务，在使用中往往伴随着一些卷迁移和容量查询的操作，但这些操作实际执行效率并不高，需要做一些优化。
在 qemu 原生版本实现 ceph 卷迁移功能时，迁移前将 bitmap 每位都置脏，首轮迁移时会将源盘所有数据迁往目的盘(未写入数据的部分以 0 写入)，导致迁移数据量增多，时间变长。 我们对 ceph 卷迁移做了优化，减少了首轮迁移的数据量，效率得到大幅提升（尤其是源盘空间较大数据量较少时），具体步骤：
修改 qemu 组件的 rbd 驱动，增加获取后端集群 ceph 卷已使用空间分布的接口。
迁移开始时，利用接口初始化卷迁移的 dirty bitmap。
迁移过程中，如果虚机新增 io，将对应 dirty bitmap 置脏。不断迭代清理 dirty bitmap，只对有数据的存储块进行迁移拷贝，无数据的块直接跳过。
当 dirty bitmap 全部清理时卷热迁移完成。
此外还有一些其他优化：
优化 ceph 卷容量查询，调用新的接口，其查询效率提升 30%+。
qemu 支持 ceph 卷 snapshot 迁移功能，迁移后依然保有源卷的快照信息。
跨 os 不停服热迁移
解决了同其他核心产品适配的各种问题后，我们工作重点转向了跨 os 的迁移适配上来。我们与 openeuler 社区的 virt sig 成员进行了深度协同联创，解决了跨 os 迁移需要考虑 guest 的 cpu 能力、设备状态等多个方面的问题。
目的端主板类型不兼容迁移失败
从 bc-linux7 系列系统往 bc-linux for euler 系列系统迁移时会有“unsupported machine type”的报错，对比两个操作系统 qemu 组件支持的 machine type，发现 bc-linux7 的虚拟化组件裁剪了 qemu 社区原生的 machine type，完全自定义了私有的主板类型，无法正常热迁移到 openeuler 上。
由于 machine type 在迁移时不能被改变，要想迁移成功，就必须在 bc-linux for euler 系统上的高版本 qemu 兼容低版本的 machine type。为此，我们梳理低版本 qemu 中每种 machine type 支持的设备，并在高版本 qemu 上移植相应的 machine type，这样迁移时便不会出现主板类型不支持的问题。
设备结构体差异引起迁移失败
qemu 使用 vmstatedescription（vmsd）数据结构来对设备状态进行描述和管理，迁移时 vmsd 的 fields 和 subsections 会被发送到目的端。 要想虚机迁移成功，如果源端设备结构体字段多于目的端，则目的端 vmstate_load_state 加载设备状态时，需要将多出来的字段 disable 掉，反之则需将缺少的字段跳过加载。
测试时我们发下虚机从 bc-linux for euler 系列系统往 bc-linux7 系列系统回迁时，对端无法成功接收键盘的设备状态。对比键盘的 vmsd，高版 qemu 增加了 kbd_extended_state 字段的发送，目的端因缺失该字段导致迁移失败。
kbd_extended_state_needed 是判断是否将 kbd_extended_state 字段发送的函数（默认 true)。为了保证虚机不会因为 kbd_extended_state 而导致回迁失败，回迁时须将多出的 kbd_extended_state 字段不发送。
此外我们还比较了其他设备，尤其是 virtio 和 vhost_user 设备的 vmsd 在高低 qemu 版本间的差异，对有差异的地方做了修改。
cpu feature 不兼容热迁移失败
虚机 cpu 有 3 种模式：custom（指令集最少但热迁移兼容性最好）、host-passthrough（指令集最多但热迁移兼容性最差）和 host-model（介于两者之间），但虚机 cpu features 不仅和虚拟化配置有关，还与宿主机的 cpu 型号、操作系统内核等有关。即使是在 custom 或 host-model 模式下，我们也遇到一些因目的端缺失 cpu features 而导致的迁移失败的问题。
case1：目的端缺失 arch-facilities 特性
由于高版本 libvirt 将同一 cpu feature 名称由 arch-facilities 变为了 arch-capabilities，目的端不识别 arch-facilities，导致热迁移失败。需要在源端的 cpu_map.xml 中将其修改为 arch-capabilities 才能通过 cpu feature 兼容性检查。
case2：目的端缺失 spec_ctrl 特性
bc-linux7 系列系统上使用的 3.10 内核需要使能 spec_ctrl 来避免“幽灵漏洞”，但 bc-linux for euler 系列系统使用的 4.19 内核通过其他方式避免了该漏洞，关闭了 spec_ctrl，需要更新微码才能在目的端使能 spec_ctrl 特性。
case3：目的端缺失 hle/rtm 特性
配置 host-model 的模式虚机因目的端缺失 hle/rtm 特性导致热迁移失败。需要在目的节点的内核的启动参数增加“tsx=on”来使能相关指令集。
总结
我们做了虚拟化组件的同源异构、对 os 兼容适配，并与 openeuler 社区进行深度联创，实现跨 os 不停服热迁移优化，从原理和实践两个方面，保障了 centos 的迁移改造任务得以高效进行。 然而移动云现网有海量的节点需要做迁移，这对迁移的效率与成功率有了更高的要求，在下期的分享中，我们将带来对热迁移性能提升优化做的技术分享，敬请期待！
思科和EMC不惜反目成仇 意欲为何?
Imagination和Intercede展示Trust Continuum确保IoT安全性的强大功能
电动推杆和电缸的区别是什么？
适合自制的小巧天线
充电板生产厂家
移动云操作系统改造技术实践分享
Stealth发布防水迷你PC，售价3195美元
电脑主板不取消电池的原因
模拟技术对数字化设备创造的重要必不可少因素
电容电感对EMC的影响
超时逻辑在OpenHarmony中的实现
iPhone 15和iPhone 14有什么不同?
如何构建通用安全MCU的硬件防护力
蜂鸟视图JS SDK v3.0：五大亮点，打造更小更快的可视化地图应用
硝酸浓度对硅晶片腐蚀速率的影响实验报告
云+端 极致视讯”2018亿联新品巡回发布在广州、成都同时拉开帷幕
LCD 显示驱动厂商：新相微电子（上海）有限公司简介
IBM宣布芯片实现重大突破 可建百万万亿次电脑
Redmi Note 8发布会，卢伟冰经典语录解读
奇异摩尔以互联解决方案，共建可持续、开放的芯粒生态
关键挑战
虚拟化组件同源异构
新的虚拟化组件需要在多款 linux 操作系统上稳定运行，在不同操作系统和 cpu 架构上共用同一份源码，因此首先需要解决同源异构难题。
os 兼容适配
计算、存储、sdn 等核心业务需要在 os 之上相互兼容，在新的平台上需要在中间层即虚拟化层解决一些业务兼容适配问题。
跨 os 不停服热迁移
跨操作系统、跨虚拟化组件大版本的迁移，可能因虚机 cpu 能力、内存布局、设备结构体等差异，导致迁移失败影响业务连续性，这是虚机跨操作系统迁移过程中的一大难题。
虚拟化组件同源异构
同源异构可以屏蔽不同系统、不同架构的差异，收缩现网版本，减小代码维护的压力。实现“一份代码，一次编译，处处运行”。
在同源异构改造过程中我们解决了诸多问题，如：不同系统、不同架构其编译安装依赖包会有差异，需要在 spec 文件中根据不同系统、架构指定相应的依赖。新旧虚拟化组件软件包安装时存在冲突，需利用 rpm 的 obsoletes 机制删除对应安装包，实现组件的平滑升级。另外由于新旧虚拟化组件差异大，导致旧版补丁回合后函数调用失败，需要根据代码差异重新设计实现部分功能。
os 兼容适配
为了保证虚机能在 os 上平稳运行，需要解决一些计算、存储、sdn 同虚拟化组件在平台上适配存在的问题，并做一些优化。
python2 版本的兼容
随着 python2 的生命周期结束，libvirt-python 自 6.0.0 就停止了对 python2 的支持，但由于部分产品改造周期长，需要暂时维持使用 python2 环境作为过渡，虚拟化作为底层组件，需要构建一个基于 python2 的 libvirt-python 组件包。 我们从 python3 和 python2 间语法差异、接口改变、模块变化等方面入手，对适配 os 上的 libvirt-python 代码做了修改，包括：
针对数据类型、类的定义等语法差异上做了对应修改。
针对异常捕获、输入输出、迭代器等 api 使用差异部分做了对应修改。
针对 python3 和 python2 间名称变化或废弃的模块做了对应修改。
在修改了 50 多个文件，上千行代码后，最终得到了一个基于 python2 的稳定可靠的 libvirt-python。
ovs-dpdk 与 qemu 的适配
sdn 的稳定性和可靠性直接影响到用户虚机的网络服务质量，为了保证 sdn 能在新平台上平稳运行，我们积极推动各 sdn 厂商在 os 上的适配工作，解决了多个适配问题。
sdn 适配时发现当 qemu 作为 server 时，重启 ovs，虚机可能会 crash。查看 qemu 的 coredump 文件,定位到如下代码触发了 crash。
当 qemu 作为 server 端时，一旦 ovs 重启，按照上面代码逻辑 qemu 会主动尝试进行 reconnect，过程中会改变网卡设备 tcp 状态字为 tcp_chardev_state_disconnected，此时会造成处理逻辑 bug，使得 qemu 发生 crash（实际上 qemu 作为 server 端时，不应进行 reconnect 操作，而是由作为 client 端的 ovs 进行 reconnect）。具体触发 crash 的流程如下：
解决方案是只有当 qemu 作为 client，重启 ovs,qemu 才做 reconnect，问题得到修复。 除上述问题外，我们还解决了一些其他问题，包括 ovs 热升级后 windows 虚机网络不通、海光平台执行 testpmd 测试程序虚机卡住等多个问题。
卷迁移操作的效率优化
分布式存储为云平台提供基础存储服务，在使用中往往伴随着一些卷迁移和容量查询的操作，但这些操作实际执行效率并不高，需要做一些优化。
在 qemu 原生版本实现 ceph 卷迁移功能时，迁移前将 bitmap 每位都置脏，首轮迁移时会将源盘所有数据迁往目的盘(未写入数据的部分以 0 写入)，导致迁移数据量增多，时间变长。 我们对 ceph 卷迁移做了优化，减少了首轮迁移的数据量，效率得到大幅提升（尤其是源盘空间较大数据量较少时），具体步骤：
修改 qemu 组件的 rbd 驱动，增加获取后端集群 ceph 卷已使用空间分布的接口。
迁移开始时，利用接口初始化卷迁移的 dirty bitmap。
迁移过程中，如果虚机新增 io，将对应 dirty bitmap 置脏。不断迭代清理 dirty bitmap，只对有数据的存储块进行迁移拷贝，无数据的块直接跳过。
当 dirty bitmap 全部清理时卷热迁移完成。
此外还有一些其他优化：
优化 ceph 卷容量查询，调用新的接口，其查询效率提升 30%+。
qemu 支持 ceph 卷 snapshot 迁移功能，迁移后依然保有源卷的快照信息。
跨 os 不停服热迁移
解决了同其他核心产品适配的各种问题后，我们工作重点转向了跨 os 的迁移适配上来。我们与 openeuler 社区的 virt sig 成员进行了深度协同联创，解决了跨 os 迁移需要考虑 guest 的 cpu 能力、设备状态等多个方面的问题。
目的端主板类型不兼容迁移失败
从 bc-linux7 系列系统往 bc-linux for euler 系列系统迁移时会有“unsupported machine type”的报错，对比两个操作系统 qemu 组件支持的 machine type，发现 bc-linux7 的虚拟化组件裁剪了 qemu 社区原生的 machine type，完全自定义了私有的主板类型，无法正常热迁移到 openeuler 上。
由于 machine type 在迁移时不能被改变，要想迁移成功，就必须在 bc-linux for euler 系统上的高版本 qemu 兼容低版本的 machine type。为此，我们梳理低版本 qemu 中每种 machine type 支持的设备，并在高版本 qemu 上移植相应的 machine type，这样迁移时便不会出现主板类型不支持的问题。
设备结构体差异引起迁移失败
qemu 使用 vmstatedescription（vmsd）数据结构来对设备状态进行描述和管理，迁移时 vmsd 的 fields 和 subsections 会被发送到目的端。 要想虚机迁移成功，如果源端设备结构体字段多于目的端，则目的端 vmstate_load_state 加载设备状态时，需要将多出来的字段 disable 掉，反之则需将缺少的字段跳过加载。
测试时我们发下虚机从 bc-linux for euler 系列系统往 bc-linux7 系列系统回迁时，对端无法成功接收键盘的设备状态。对比键盘的 vmsd，高版 qemu 增加了 kbd_extended_state 字段的发送，目的端因缺失该字段导致迁移失败。
kbd_extended_state_needed 是判断是否将 kbd_extended_state 字段发送的函数（默认 true)。为了保证虚机不会因为 kbd_extended_state 而导致回迁失败，回迁时须将多出的 kbd_extended_state 字段不发送。
此外我们还比较了其他设备，尤其是 virtio 和 vhost_user 设备的 vmsd 在高低 qemu 版本间的差异，对有差异的地方做了修改。
cpu feature 不兼容热迁移失败
虚机 cpu 有 3 种模式：custom（指令集最少但热迁移兼容性最好）、host-passthrough（指令集最多但热迁移兼容性最差）和 host-model（介于两者之间），但虚机 cpu features 不仅和虚拟化配置有关，还与宿主机的 cpu 型号、操作系统内核等有关。即使是在 custom 或 host-model 模式下，我们也遇到一些因目的端缺失 cpu features 而导致的迁移失败的问题。
case1：目的端缺失 arch-facilities 特性
由于高版本 libvirt 将同一 cpu feature 名称由 arch-facilities 变为了 arch-capabilities，目的端不识别 arch-facilities，导致热迁移失败。需要在源端的 cpu_map.xml 中将其修改为 arch-capabilities 才能通过 cpu feature 兼容性检查。
case2：目的端缺失 spec_ctrl 特性
bc-linux7 系列系统上使用的 3.10 内核需要使能 spec_ctrl 来避免“幽灵漏洞”，但 bc-linux for euler 系列系统使用的 4.19 内核通过其他方式避免了该漏洞，关闭了 spec_ctrl，需要更新微码才能在目的端使能 spec_ctrl 特性。
case3：目的端缺失 hle/rtm 特性
配置 host-model 的模式虚机因目的端缺失 hle/rtm 特性导致热迁移失败。需要在目的节点的内核的启动参数增加“tsx=on”来使能相关指令集。
总结
我们做了虚拟化组件的同源异构、对 os 兼容适配，并与 openeuler 社区进行深度联创，实现跨 os 不停服热迁移优化，从原理和实践两个方面，保障了 centos 的迁移改造任务得以高效进行。 然而移动云现网有海量的节点需要做迁移，这对迁移的效率与成功率有了更高的要求，在下期的分享中，我们将带来对热迁移性能提升优化做的技术分享，敬请期待！
思科和EMC不惜反目成仇 意欲为何?
Imagination和Intercede展示Trust Continuum确保IoT安全性的强大功能
电动推杆和电缸的区别是什么？
适合自制的小巧天线
充电板生产厂家
移动云操作系统改造技术实践分享
Stealth发布防水迷你PC，售价3195美元
电脑主板不取消电池的原因
模拟技术对数字化设备创造的重要必不可少因素
电容电感对EMC的影响
超时逻辑在OpenHarmony中的实现
iPhone 15和iPhone 14有什么不同?
如何构建通用安全MCU的硬件防护力
蜂鸟视图JS SDK v3.0：五大亮点，打造更小更快的可视化地图应用
硝酸浓度对硅晶片腐蚀速率的影响实验报告
云+端 极致视讯”2018亿联新品巡回发布在广州、成都同时拉开帷幕
LCD 显示驱动厂商：新相微电子（上海）有限公司简介
IBM宣布芯片实现重大突破 可建百万万亿次电脑
Redmi Note 8发布会，卢伟冰经典语录解读
奇异摩尔以互联解决方案，共建可持续、开放的芯粒生态