1 I/O 虚拟化要回答什么
订单 API 收到创建订单的请求后，要从网卡接收数据，在数据库里提交记录，再把结果发回客户端。即使程序只占用少量 CPU，用户仍可能等待很久：请求可能排在网卡队列里，数据库写入可能等待块设备，完成通知也可能暂时得不到 CPU。I/O 是输入与输出，I/O 虚拟化要解决的正是虚拟机怎样使用真实设备，以及共享设备时怎样维持隔离、效率与可预测性。
物理服务器上的设备数量有限，虚拟机却可能很多。不能因为每个租户都需要网络和磁盘，就要求每个租户独占整台服务器。虚拟化平台于是向客户机呈现可识别的网卡和块设备，把客户机提交的工作连接到真实设备。客户机是虚拟机内部的操作系统；宿主机是承载虚拟机的物理主机；虚拟机监控器负责建立虚拟机及其资源边界。后面提到的宿主机后端，是承接客户机设备请求的软件部件，不等于业务数据库后端。
这个连接首先必须正确。客户机看到的磁盘地址不能越过自己的卷，网络报文不能任意进入别人的网络，设备写入内存时也不能覆盖其他虚拟机。其次需要足够快：如果每个请求都要求软件反复模拟设备行为，那么即使磁盘和网卡本身很快，处理路径仍可能成为瓶颈。最后还要便于运营：设备故障以后能否恢复，主机维护时能否迁移，谁有权限查看计数器，都会影响服务是否可用。
对订单服务而言，部署配置里的“4 个 vCPU、8 GiB 内存”没有描述完整的运行条件。它没有说明网卡使用什么路径、云盘后端在哪里、设备完成通知由哪个 CPU 处理，也没有说明虚拟机暂停运行时请求会等待多久。vCPU 是平台分配给虚拟机的处理器执行资源；它通常仍要获得宿主机物理 CPU 的运行时间。设备完成工作，不代表客户机已经运行到读取完成结果的时刻。
因此，本课始终围绕 3 个问题展开：请求经过哪些环节，哪些资源会被其他工作争用，以及完成结果如何回到应用。我们用订单 API 的网络接入和数据卷作为例子，但结论同样适用于日志采集、文件服务与消息处理。不要先问“哪种技术最快”，而要先问“哪种路径在当前负载和运维条件下满足目标”。一种路径可以平均延迟更低，同时更难迁移；另一种路径可以共享更方便，同时需要更仔细地控制拥塞。
还要区分云服务承诺与设备实现。平台承诺的带宽、IOPS 和可用性，是用户可依赖的产品边界；某台主机当前使用的驱动名称，是解释行为的技术线索。客户机里看到 virtio，并不能证明云盘数据就在本地主机上；看到某种硬件网卡，也不能证明端到端网络没有共享。读懂路径，是为了更准确地提出问题与收集证据，而不是从设备名称推断整套云架构。
2 virtio、SR-IOV 与设备直通边界
理解常见路径，可以从“客户机与谁约定怎样提交工作”开始。设备模拟让客户机使用某种已有硬件的接口，平台用软件实现相应行为。这样可以兼容已有驱动，但某些操作会带来额外处理。virtio 则是一组面向虚拟环境的设备接口规范：客户机安装理解 virtio 的驱动，通过约定的数据结构提交请求。它通常减少了模仿传统硬件细节的工作，但并不意味着所有处理都消失。
在常见 virtio 路径中，客户机驱动是前端，宿主机中接收请求的实现是后端。后端可以有不同位置与实现方式，部分工作也可能由硬件协助完成。入门阶段只需记住：virtio 描述双方交互的接口，不能仅凭这个名字判断后端的全部实现。它既可以服务于虚拟网卡，也可以服务于虚拟块设备；是否支持某项能力，还要看设备类型、驱动和平台配置。
设备直通通常指把某个真实设备功能分配给特定虚拟机，让客户机驱动较直接地操作它。设备功能是硬件对外呈现的可管理接口，不必总等于整张物理卡。为了允许设备直接访问客户机的内存，同时防止它碰到无权访问的区域，平台通常需要 IOMMU 提供地址转换和访问隔离。IOMMU 可以理解为设备访问内存时经过的受控地址入口，其映射机制与硬件细节留到后续课程。
SR-IOV 是让支持该标准的设备提供多个可分配功能的硬件能力。物理功能称为 PF，虚拟功能称为 VF；PF 通常承担设备管理工作，VF 可以分配给虚拟机承担数据处理。于是多个虚拟机可以各自拥有 VF，却仍共享同一设备上的物理端口、链路和部分内部资源。SR-IOV 并没有凭空复制出多条独立物理链路，VF 数量也不等于有保障的带宽份数。
SR-IOV 与直通不是互斥选项。把 VF 分配给虚拟机，本身就经常使用直通方式；把完整设备功能分配给虚拟机，则可以不依赖 SR-IOV。比较时应写清楚“virtio 网卡与直通的 VF”，或者“virtio 块设备与直通的存储控制器”，不能笼统地把前者当作所有软件、后者当作所有硬件。它们的隔离、功能支持和可观察性也需要分别确认。
直通可能缩短常见数据路径，降低宿主机软件处理开销，但客户机仍有驱动、队列和 CPU 调度，外部交换网络与存储服务也照常存在。热迁移、快照、设备恢复和网络策略能否使用，取决于平台与设备支持，不能默认与普通虚拟设备相同。为订单 API 选择路径时，应同时核对安全组和网络策略如何生效、指标从哪里获得、主机维护如何处理。性能收益只有放进这些边界后，才具有部署价值。
3 块设备、网络与中断路径
先看 1 次块设备写入。应用提交写请求，客户机操作系统把它转换成设备工作项，驱动把描述放入队列，接着通知处理方有新工作。virtio 常用的 virtqueue 可以理解为双方约定的请求与完成信息队列：其中描述需要处理的数据位置与长度，而不是要求每份业务数据都在队列里复制很多遍。后端取走请求，交给实际存储路径处理，再把完成情况交还客户机。
这个过程里至少有 2 种不同的等待。请求提交后可能尚未开始处理，属于排队等待；设备或存储后端真正处理请求，则产生服务时间。后端返回完成以后，客户机还需要获得执行机会，驱动再把结果传给等待的进程。若只计量物理设备的服务时间，就会漏掉前后的排队和通知等待。这也是“磁盘指标正常，应用却慢”的常见原因。
网络发送路径与它类似：应用把数据交给客户机网络栈，驱动提交报文，处理方再把报文交给物理网络。网络接收则从设备收到报文开始，经过队列、通知与客户机协议处理，最终唤醒应用。发送和接收可能使用不同队列，也可能在不同 CPU 上处理。网卡收到了报文，并不意味着 API 进程已经收到它；网卡发出了报文，也不代表远端业务已经成功提交订单。
完成通知通常与中断有关。中断是设备提示 CPU 需要处理某件事的机制，可以类比为工作完成后的提醒。通知次数过多时，CPU 会频繁处理设备事务；通知合并能把多次完成集中处理，节省开销，却可能让部分请求多等一些时间。系统也可能在某些阶段通过轮询主动检查队列。这里不展开具体实现，只保留结论：通知策略同时影响 CPU 消耗与延迟分布。
块设备还多了“完成究竟承诺什么”的问题。普通写入成功、文件同步成功与数据库事务提交成功，并不是可以互换的测量点。操作系统缓存可能先接收写入，持久化还要依赖同步请求、设备缓存约定及后端保障。比较虚拟化路径时，必须让写入与同步语义保持一致；把使用缓存的结果与要求持久化的结果并列，会把语义差异误判成虚拟化效率差异。
网络则要区分包速率与字节速率。同样传输 1 GiB 数据，大量小报文可能比少量大报文需要更多逐包处理、队列操作和通知。订单 API 的小请求未必用满链路带宽，却可能先耗尽处理报文的 CPU。存储也类似：很多 4 KiB 随机访问与少量 1 MiB 顺序访问，对队列和后端的压力不同。因此，描述路径时要附带请求大小与访问方式，不能只画 1 条没有负载条件的箭头。
4 动手：对比一次 virtio 与直通延迟
这次练习的目标，是得到可以解释的延迟对比。建议选择网络作为主实验：准备 1 台被测虚拟机和 1 台固定接收端，分别测试 virtio 网卡与平台提供的直通 VF。两种配置使用相同镜像、vCPU 数量、内存、可用区、协议、MTU 和接收端。若需要更换虚拟机，记录宿主机是否也发生变化；如果平台无法固定物理环境，就把结果称为“这 2 种实例配置的比较”，不要归因为纯粹的网卡差异。
先确认设备类型。Linux 中可用 ip -br link 找到接口，再用 ethtool -i <接口名> 查看驱动信息，使用 lspci -nnk 辅助核对 PCI 设备及其驱动。某些工具需要预先安装，部分信息需要管理员权限。virtio 设备通常可看到相应驱动，直通 VF 的名称则随硬件不同而变化。最终以平台设备分配记录为依据；在客户机内通常无法完整证明宿主机的共享与隔离配置。
在接收端启动经过授权的测试服务。为了贴近订单入口，可提供固定返回 256 B 内容的 /io-check 接口，保持 TLS、连接复用和访问日志策略一致，不访问数据库。先用低负载跑通请求与响应，再按固定到达速率逐档增加压力，例如从每秒 100 次请求开始。客户端记录从计划发起到完成的时间，并单独记录连接失败、超时与实际发起速率。这个接口测量的是网络相关的端到端请求表现，不代表真实订单事务延迟。
每档先预热 30 秒，再采集 180 秒，按 virtio、VF、VF、virtio 的顺序交替测试，并至少完成 3 轮。预热用于减少刚建连接、缓存未就绪等因素，交替顺序用于降低测试先后与主机状态漂移的影响。不要让两种路径同时争用同一接收端。负载发生器与接收端也要采集 CPU 和错误指标，否则接收端已经忙满时，比较只能说明它成为共同瓶颈。
结果表至少记录实际成功速率、平均值、p50、p95、p99、超时率、客户机 CPU、宿主机相关 CPU 和丢包情况。p99 表示按耗时排序后约 99% 的观测不超过该值，它不是最慢请求。只对成功请求计算分位数时，必须把超时另外列出；否则最慢的请求恰好被删掉，结果反而显得更好。低负载测基础开销，接近业务峰值的负载测排队敏感性，两种条件都应保留。
假设教学数据里，每秒 2000 次请求时 virtio 的 p99 为 2.8 ms，VF 为 1.9 ms，成功率均满足要求；再提高负载，两者都突然升到 20 ms。前面的差异提示路径可能影响延迟，后面的共同上升则要求检查接收端、链路和 CPU，不能直接宣称设备失效。这些数值只是演示结果如何解释，不是性能承诺。没有 VF 权限时，可以完成 virtio 基线与观测记录，但应明确直通对比尚未执行，不能用猜测补齐实验结果。
5 多队列、队列深度与 CPU 亲和取舍
队列把暂时处理不了的工作保存起来，也把提交者和处理者连接起来。队列深度描述能够同时在途的请求规模，具体配置项可能指软件队列上限，也可能指设备接受的请求数量，需要按工具定义区分。深度为 1 时，提交者通常要等当前请求完成再继续；深度增大后，可以让设备并行处理更多工作，减少设备因等待新请求而空闲的机会。但设备已经忙满时，继续增加在途请求，首先增加的往往是等待时间。
可以用 1 个粗略关系帮助判断：系统稳定时，平均在途数量约等于完成速率乘平均响应时间。若每秒完成 10000 个请求，平均响应时间为 2 ms，则平均约有 20 个请求在途。这是对观测均值的关系描述，不是把队列深度设置成 20 就能得到该性能的调参公式。并发数、多个队列、应用处理时间和远端服务都会影响真正的在途范围。
多队列则让工作分布到多个提交或接收通道，减少所有请求挤在同一队列和处理点上的机会。对有多个 vCPU 的虚拟机，多个网络队列可能让接收处理分布到多个 CPU，块设备多队列也可能提升并行提交能力。但业务是否提供足够并行度、驱动是否启用对应队列、后端是否仍汇聚到同一处理点，都决定它是否有效。把 1 个队列改成 8 个，不会自动得到 8 倍吞吐。
CPU 亲和性是限制或引导某类工作在哪些 CPU 上执行。例如，把某个队列的完成处理放在指定 CPU 附近，可能减少工作来回切换；为 I/O 处理保留足够运行时间，也可能改善尾延迟。但如果把业务线程、网络接收和存储完成都集中到同一 CPU，就可能制造新的热点。客户机内设置的 vCPU 亲和性，也不能保证对应宿主机物理 CPU 独占，需要平台侧配合确认。
滑块里增加队列深度，会先看到吞吐逐步接近上限，再看到等待与 p99 继续上升。这个模型刻意保持处理能力固定，帮助理解“容纳更多请求”与“处理更快”之间的区别。真实系统可能因为并行度不足、缓存或批处理而出现不同曲线，所以滑块只能解释趋势，不能替代测量。选择配置时，应在可接受尾延迟和错误率内寻找合适吞吐，而不是把所有上限都推到最大。
调整顺序也会影响判断。先记录默认队列数、实际负载和 CPU 分布；再只调整队列数量，观察负载是否更均匀；之后才比较队列深度或通知合并。每次保留修改前后的 p99、成功率与 CPU 数据。如果平台不开放某项设置，就把它写成约束，并通过实例规格、负载分散或服务配额解决。不要把无法控制的硬件细节变成部署方案的隐含前提。
6 常见坑：只看吞吐忽视尾延迟
吞吐回答每段时间完成多少工作，延迟回答每个请求等待多久。这两个指标相关，却不会总朝同一方向改善。把更多请求塞进队列，可能让设备始终有活可做，吞吐因此略有增加；同时，排在后面的订单会等得更久。对于用户提交订单这样的交互服务，达到每秒 5000 次请求但经常超时，未必比稳定完成每秒 4000 次更有价值。选择取决于服务目标，而不是压测榜单上的最大值。
平均值尤其容易遮住问题。假设 1000 次请求里，990 次为 1 ms，10 次为 100 ms，平均约为 1.99 ms。这个平均值看起来温和，却掩盖了 10 次明显停顿；p99 的具体数值还会受到分位数计算方法影响。因此，既要看分位数，也要看超过业务阈值的比例和超时率。样本少时，高分位数容易波动，应增加有效采集时间并保留样本数量，不能对很少的请求过度解读 p99.9。
第 2 个坑是让测试工具自己降低压力。有些工具等上个请求完成才发下个请求，服务越慢，产生的新请求越少，于是它没有完整表现原本持续到达的业务压力。这种遗漏通常称为协调遗漏。固定到达速率测试应记录计划发送、实际发送与完成时间；如果客户端发不动，应明确标注负载发生器受限。闭环并发测试仍然有用，但它回答的是固定并发下的表现，需要与固定速率测试分开解释。
第 3 个坑是把短暂突发平均掉。每分钟平均吞吐可能平稳，期间却出现持续 2 秒的中断密集处理与队列增长。订单 API 的客户端重试又可能放大这段突发：请求超时后继续补发，队列更长，新的请求再次超时。观测应同时保留适合定位的短时间窗口与长期趋势；若指标精度不足，就承认无法定位到更短的时间尺度，不要凭分钟均值断言没有拥塞。
第 4 个坑是比较不同语义与不同负载。使用更大报文、更长连接、更少同步写入，都会改变系统表现。若 virtio 跑小请求、直通跑大文件，再用吞吐推断路径优劣，结论没有共同基准。CPU 百分比也要注明分母：1 个 vCPU 满载与整台主机平均使用率不高可以同时发生。只盯整机平均值，容易漏掉实际承担设备处理的那个 CPU。
排查时，可以把入口请求率、成功率、p99、队列积压、逐 CPU 使用率、软中断处理量和设备丢弃计数对齐到同一时间轴。软中断是 Linux 中处理部分延后工作的一类机制，网络处理常会涉及它，但计数增长并不直接等于故障。需要同时看到资源争用、排队和业务影响，再提出假设。若客户机看不到宿主机数据，就提交精确时间段、实例和接口信息，请平台侧补齐对应证据。
7 案例：中断风暴压垮共享 CPU
某订单服务把 API、日志转发和后台库存同步放在同组虚拟机中。平时网络带宽只使用配额的 30%，CPU 平均使用率也不高。某次活动开始后，API 的 p99 从 8 ms 升到 90 ms，并伴随超时。运维首先怀疑公网带宽，但链路字节速率没有接近上限。这个判断忽略了报文数量：日志转发产生了大量小报文，每个报文都需要相应的设备与网络处理。
对齐时间后发现，某个宿主机 CPU 的设备相关处理量急剧增加，承担 virtio 网络后端与相关通知处理的工作集中在附近，部分客户机 vCPU 获得执行的时间也受到影响。客户机里，网络接收处理出现热点，API 进程等待更多。这里的“中断风暴”是对设备通知及其后续处理异常密集的现象描述，不表示仅凭某个中断计数就能确定根因；还要查清哪些队列、哪些处理任务占用了 CPU。
排查先列出可区分的假设。如果是外部链路拥塞，应寻找对应方向的丢包、重传和链路排队；如果是存储慢，应看到事务等待与卷延迟相吻合；如果是设备处理争用，则应看到逐 CPU 的相关处理增长、队列等待与业务延迟同时变化。团队发现磁盘同步延迟保持稳定，异常却与日志小报文数量上升紧密对应。这个证据把重点转向网络处理，但仍不足以证明是哪项绑定配置造成热点。
接下来在测试环境重现相同小报文负载，并由平台管理员确认队列与 CPU 分配。降低日志发送速率后，相关 CPU 负载与 API 的 p99 同时下降；保持总字节量相近、改用合理批量发送时，报文数量下降，现象也缓解。它们是支持“逐包处理与共享 CPU 争用”解释的证据。为了进一步排除巧合，还需重复实验并观察其他资源，而不能把 1 次恢复当作永久结论。
处理分成临时缓解与配置修正。临时限制日志突发并将任务错峰，优先恢复订单入口；随后核对多队列是否实际工作，调整处理分布，为关键工作提供合适的 CPU 资源。通知合并也可以作为候选调整，但必须复测延迟，因为合并本身会引入等待。若需要迁移或修改亲和性，应在平台允许的流程内执行，保留恢复配置，避免直接在生产主机随意停用中断或重绑设备。
复测并没有只报告“吞吐恢复”，而是同时比较正常峰值和日志突发时的成功率、p99、逐 CPU 负载与丢弃计数。团队还测试了日志限速失效时的告警，确认可以提前看到报文速率和队列异常。这个案例的结论不是直通一定能解决问题：VF 仍有接收处理与客户机 CPU，物理端口也仍被共享。真正要避免的是把关键服务依赖的处理资源，放进没有保障、没有观测的争用点。
8 把 I/O 路径写进虚拟化方案
方案中的设备描述，应从订单请求经过的路径开始：客户端进入受控网络，抵达虚拟机网卡，API 再通过块设备或网络存储完成数据操作。标出客户机驱动、宿主机后端或 VF、物理网络与存储服务。对不知道的部分写“由平台提供，待确认”，并列出需要的平台能力；不要用熟悉的驱动名填补未知路径。路径图的价值，是让部署人员、应用人员和平台人员知道自己负责哪段边界。
然后为目标负载建立可核对的契约。说明请求大小、连接方式、读写比例、同步要求、正常速率与短时峰值，再给出成功率和延迟目标。例如，教学方案可设定订单入口每秒 2000 次请求、峰值持续 180 秒，关注 p99 和超时率；数据库提交另设目标。把网络接口与数据库事务拆开，是为了分别定位，最终验收仍然必须覆盖完整下单流程。
设备选择要附上理由和条件。常规 API 若在 virtio 下已达到目标，而且需要频繁维护和弹性部署，继续使用该路径可能更合适。对确有低延迟需求的组件，可以提出 VF 对照实验，但要同时列出 VF 配额、可用主机范围、镜像驱动兼容性与故障恢复方式。不要把“更接近硬件”当成独立业务收益；只有测得的性能改善和能够承担的运营成本，才支持选择改变。
隔离也必须落到控制点。身份权限决定谁能创建实例、申请特殊设备和修改网络；网络策略决定谁可以连接订单入口和数据服务；设备与内存隔离由平台提供基础保障。若路径变化会影响策略执行位置、流量镜像或指标采集，需要平台给出明确支持范围。用户不能因为选择 VF，就默认绕过原有安全要求，也不能凭普通网卡上的操作经验推断 VF 具有完全相同的管理能力。
可观察性部分写明指标、位置和责任人。应用记录请求分位数、超时与重试；客户机记录接口、逐 CPU 和块设备指标；平台记录宿主机设备处理、队列与物理资源状态。各层使用可关联的时间戳、实例标识和卷标识。对不能开放的宿主机细节，约定由平台在什么时间窗口提供诊断结论，避免发生故障后才发现关键证据已经被覆盖。
最后写清验证与回退。验证包括目标负载、突发负载及依赖服务变慢时的表现；回退包括恢复队列配置、恢复原有实例类型或把流量切回已验证的实例。磁盘路径变化还必须考虑卷挂载与数据一致性，不能把“换回设备”写成毫无前提的按钮操作。方案应记录验收日期、软件版本与测试限制，让后来接手的人知道结论适用于什么环境，也知道何时需要重新测量。
9 从I/O 虚拟化走向OpenStack（C25）
现在已经能解释虚拟机怎样把 I/O 交给设备，但云平台还需要回答另一个问题：用户请求 1 台实例、1 个网络和 1 个数据卷时，谁来把这些资源组合起来？设备路径属于数据实际流动的部分；创建、调度、授权和保存资源状态，则属于控制管理的部分。OpenStack 是下一课用来认识这些协作关系的开源云平台，本课先建立问题，不提前展开安装与内部实现。
想象通过 API 部署订单服务。平台要先确认调用者身份与权限，再寻找满足 CPU、内存和设备要求的主机，连接规定的网络，准备或挂载数据卷，最后向用户返回实例状态。若用户要求 VF，调度就不能只看空闲内存：还要知道哪些主机有可分配的设备功能、剩余数量是否足够，以及请求是否符合租户配额。I/O 路径因此会影响资源放置，也会影响容量规划。
这也解释了为什么“控制面显示创建成功”与“业务运行符合目标”是不同的验收层次。前者说明资源编排达到某种状态，后者还要验证路由、安全策略、卷读写、应用健康与性能。实例存在不代表订单入口可访问，网卡连接成功也不代表峰值下没有 CPU 争用。下一课遇到云平台的计算、网络与块存储服务时，应持续问：哪个组件建立关系，哪个组件实际搬运数据，哪个组件提供故障证据。
资源回收同样重要。删除实例后，平台要按策略释放设备、网络连接和相关配额，持久数据卷则可能需要保留。VF 等有限资源如果没有正确回收，会让新实例即使有足够 CPU 也无法放置；卷若错误删除，则会影响订单数据。用户可见的生命周期与底层设备生命周期需要协调，但两者不必完全一致。理解这种差别，比提前记忆大量组件名称更能帮助读懂云平台。
带着本课结论进入 C25，可以把关注点从单台主机扩展到整个资源池。virtio、VF 和直通是实现路径的选项；身份、网络、存储与观测构成让这些选项能够被安全使用的服务条件。需要迁移的工作负载要核对迁移能力，需要低延迟的工作负载要附上测量证据，需要共享资源的服务要明确争用边界。平台的价值，是把这些约束变成可申请、可管理、可恢复的资源，而不是让设备限制自动消失。
放进方案里
本方案为订单 API 选择 virtio 网卡与平台块存储，先用默认队列配置建立基线。部署使用统一镜像，记录客户机驱动、实例规格、卷类型和网络设置。对宿主机后端及物理存储中不可见的环节，由平台提供能力说明与故障协查入口。身份权限限制特殊设备申请与网络修改，订单入口和数据服务分别配置访问策略。
验收以每秒 2000 次请求、持续 180 秒作为教学峰值，预热 30 秒，至少重复 3 轮。固定请求大小、连接复用和同步语义，同时记录成功率、p50、p95、p99 与超时率。网络探测和数据库提交分别测量，再执行完整订单流程；延迟目标由业务确认，实际成功速率不足时不得仅凭已完成请求的分位数通过验收。
观测覆盖应用请求、客户机逐 CPU 使用率、接口报文速率、丢弃计数和卷延迟。平台负责关联宿主机队列、设备处理与共享资源争用。告警同时关注尾延迟和错误率，日志突发时保留短时间窗口。队列数量、队列深度和亲和性分别调整，每次只改变可解释的因素，并保留修改前后的证据。
只有基线不能满足目标、且对照实验支持收益时，才为关键组件申请直通 VF。启用前确认网络策略、指标采集、设备配额、维护与恢复能力，测试客户端与接收端也必须有足够余量。普通实例资源充足但 VF 不足，应视为独立容量约束。
故障时先限制非关键小报文突发，再依据时间对齐的指标定位争用点。回退采用已验证的实例与流量切换流程，涉及数据卷时核对挂载和一致性要求。交付记录包括测试条件、配置版本、已知限制及平台责任边界，主机类型或驱动变化后重新验收。
10 小结：下一步OpenStack（C25）
I/O 虚拟化把客户机请求连接到真实设备，同时安排共享、隔离和完成通知。virtio 提供虚拟设备交互接口，SR-IOV 提供可分配的设备功能，直通描述设备功能交给虚拟机使用的方式。选择需要比较完整路径，以及迁移、策略、观测与恢复能力。
离开本课前，试着解释 3 件事：为什么带宽未满仍可能排队？为什么更多队列不保证更低 p99？为什么直通 VF 仍会受到共享资源影响？如果能用请求、队列、CPU 与通知的关系回答，就已经具备进入 C25 的基础。下一课将把这些主机内的机制接到 OpenStack 的资源申请、调度与生命周期管理上。