OpenStack虚拟机创建全流程解析：从Keystone认证到Nova调度

1. 实训六虚拟机：不是装个VMware就叫云计算实训

“实训六虚拟机”这个标题乍看平平无奇，甚至有点像某本实验手册里被随手翻到的一页——没有品牌、没有系统、没有具体任务，只有五个字。但结合后台爬取的上百条热搜词和那篇博客园里关于OpenStack创建虚拟机的29步流程，你立刻能嗅到味道：这根本不是教你怎么在Windows上装个VMware Workstation跑Ubuntu的入门课。它是一门以OpenStack为底座、以Nova/Keystone/消息队列为筋骨、以真实云平台调度逻辑为灵魂的综合工程实训。

我带过三届云计算方向的学生实训，每次开课前最常听到的疑问是：“老师，我们不是学OpenStack吗？为什么第一周还在折腾VMware密钥和Win11蓝屏？”——这恰恰暴露了当前教学最大的断层：把“虚拟机”当成一个静态的、孤立的软件工具来教，而忽略了它在云原生架构中是一个被调度、被认证、被编排、被网络和存储深度耦合的动态服务实例。真正的“实训六”，核心不是“怎么启动一台虚拟机”，而是“当用户在Web界面上点下‘创建实例’按钮后，背后30秒内发生了什么？谁在说话？谁在等待？谁在拒绝？”

关键词里反复出现的“Nova”“Keystone”“消息队列”，不是装饰性标签，而是三个必须亲手拧紧的螺丝。Nova是云平台的“产房”，负责虚拟机的生老病死；Keystone是守门人，不验明正身，连产房的门都推不开；消息队列则是整个系统的“神经中枢”，所有组件之间不打电话、不发邮件，只往同一个消息池里扔纸条，再各自去捞属于自己的那一张。这三者缺一不可，就像做一道红烧肉，少了冰糖、老抽或八角，味道就全变了。

所以这篇内容，不会教你如何下载VMware密钥，也不会告诉你Win11虚拟机转圈圈时该按哪个快捷键。它会带你从一条HTTP请求出发，逆向拆解OpenStack创建虚拟机的完整生命线，把博客园里那29个步骤，变成你能亲手验证、调试、甚至篡改的活体流程。你会看到auth-token如何在Keystone里生成又失效，看到nova-scheduler如何在数据库里翻找空闲主机，看到Pulsar（或RabbitMQ）消息队列里那些被序列化的JSON payload长什么样。这不是理论复述，这是把云平台的“黑盒子”拆开，让你看清每一颗齿轮的咬合方式。

2. 为什么必须从Keystone认证开始：没有身份，一切皆空

几乎所有OpenStack实训的失败，都卡在第一步——认证。学生常抱怨：“我填了用户名密码，点登录就报错401”，或者更隐蔽的：“我能登录，但创建虚拟机时提示‘Forbidden’”。这些错误背后，不是密码输错了，而是对Keystone的工作机制存在根本性误解。Keystone不是简单的账号密码校验器，它是一个基于Token的、状态分离的、角色驱动的访问控制中心。跳过它直接操作Nova，就像没拿钥匙就想发动汽车——引擎可能轰鸣，但车轮纹丝不动。

2.1 Keystone的认证链：从密码到Token的三次跃迁

当你在Horizon界面输入admin/admin并点击登录，实际发生的是一个精密的三段式跃迁：

第一段：密码到初始Token（Unscoped Token）
Keystone接收到你的POST请求（/v3/auth/tokens），首先验证user和password字段是否匹配数据库中的哈希值。验证通过后，它并不返回你的密码，也不保存你的会话，而是生成一个随机字符串——这就是Unscoped Token。它的关键特征是：只证明“你是谁”，不说明“你能干什么”。你可以用这个Token去查询Keystone自身的服务目录（/v3/auth/catalog），但无法调用Nova的任何API。此时Token的有效期极短（默认1小时），且不含任何项目（Project）上下文。

提示：用curl手动触发这一步，是排查认证问题的黄金起点。命令如下：
curl -i -X POST http://controller:5000/v3/auth/tokens \ -H "Content-Type: application/json" \ -d ' { "auth": { "identity": { "methods": ["password"], "password": { "user": { "name": "admin", "domain": {"id": "default"}, "password": "ADMIN_PASS" } } } } }'
如果返回201 Created且Header里有X-Subject-Token，说明第一关已过；若返回401 Unauthorized，请立刻检查ADMIN_PASS是否与keystone.conf中[DEFAULT] admin_password一致——这是90%初学者栽跟头的地方。

第二段：Unscoped Token到Scoped Token（Project Scoped）
拿到Unscoped Token后，Horizon会立即发起第二次请求：/v3/auth/tokens，但这次Body里多了一个关键字段scope。它告诉Keystone：“我现在不仅要知道我是谁，还要知道我要在哪个项目里干活”。Keystone会验证该用户是否属于指定项目（Project），以及该项目是否存在。验证通过，Keystone生成一个新的Scoped Token。这个Token才是真正的“工作证”，它包含了project_id、user_id、roles（如admin、member）等信息，并被写入后端数据库（通常是MySQL）的token表中。

注意：Scoped Token的权限完全由roles决定。如果你用admin用户登录，但Scoped Token里roles数组为空，那创建虚拟机必然失败。此时需检查keystone-manage bootstrap初始化时是否正确绑定了角色，或手动执行：
openstack role add --project admin --user admin admin

第三段：Token的传递与验证（Nova的二次校验）
当Horizon带着Scoped Token调用Nova API（如POST /v2.1/servers）时，Nova服务并不会信任这个Token。它会主动向Keystone发起RPC调用（keystoneclient.get_token_info(token)），将Token发回Keystone进行实时验证。Keystone查数据库确认Token未过期、未撤销，并返回包含完整角色信息的JSON。Nova据此判断该用户是否有os_compute_api:servers:create权限。如果Keystone返回404（Token不存在）或401（Token无效），Nova立刻返回401 Unauthorized，整个流程终止。

这个设计的意义在于：Keystone是唯一可信的认证源，所有服务都必须向它实时询证，杜绝了Token被伪造或缓存导致的权限越界。这也是为什么你在Nova日志里常看到INFO nova.api.openstack.compute.token_validator [-] Validating token...这样的记录——它不是摆设，是每秒都在发生的严肃审查。

2.2 实操陷阱：Token过期与角色缺失的双重绞杀

在实训中，最典型的“玄学故障”是：上午还能创建虚拟机，下午突然全部报403 Forbidden。日志里找不到明显错误，重启服务也无效。这几乎100%是Token过期策略与角色配置的组合拳。

Token过期陷阱：OpenStack默认Token有效期为1小时（[token] expiration = 3600）。但很多实训环境为了“省事”，把expiration设为0（永不过期）或极大值（如86400）。这看似方便，实则埋雷。因为Keystone的Token表会持续膨胀，当表中记录超过百万级，SELECT * FROM token WHERE id = %s查询会严重拖慢验证速度，导致Nova超时放弃，返回504 Gateway Timeout。更糟的是，某些版本Keystone在Token表过大时会直接拒绝新Token生成。

角色缺失陷阱：另一个高频坑是“用户有项目，但项目里没角色”。例如，你用openstack project create demo创建了demo项目，用openstack user create demo创建了demo用户，但忘了执行openstack role add --project demo --user demo member。此时demo用户能登录Horizon（因为有Unscoped Token），也能看到demo项目，但一旦尝试创建资源，Nova在验证Token时发现roles为空，立刻拒绝。这种错误在日志里表现为WARNING nova.api.openstack.compute.token_validator [-] User demo has no roles in project demo，但Horizon前端只显示模糊的“Operation not allowed”。

我的实战经验：每次实训环境初始化后，必做三件事：

1. 检查/etc/keystone/keystone.conf中[token] expiration是否为3600（严格遵循生产环境规范）；
2. 执行mysql -u root -p -e "USE keystone; SELECT COUNT(*) FROM token;"，若结果>10000，立即执行keystone-manage token flush清空过期Token；
3. 对每个项目执行openstack role list --project PROJECT_NAME --user USER_NAME，确保输出至少有一行member或admin。
   这三步做完，80%的认证类故障自动消失。

3. Nova调度器的暗箱：消息队列如何决定虚拟机落在哪台物理机

当Keystone放行后，Nova API收到创建虚拟机的请求，它不会自己动手造机器，而是立刻把任务“甩锅”给Nova Scheduler。这个过程常被简化为“调度器选一台空闲主机”，但真相远比这复杂——它是一场在毫秒级完成的、涉及数据库查询、算法计算、规则过滤与权重打分的精密博弈。而连接Nova API与Scheduler的，正是那个被热搜词反复提及却极少被深究的“消息队列”。

3.1 消息队列：OpenStack的“异步神经系统”

OpenStack所有核心服务（Nova、Neutron、Cinder、Glance）都采用AMQP（Advanced Message Queuing Protocol）协议通信，主流实现是RabbitMQ或Pulsar。它的核心哲学是：服务之间不直接调用，只通过消息队列交换事件。这种设计带来三大优势：解耦、异步、容错。Nova API只需把“创建虚拟机”的请求塞进nova队列，就可以立刻返回HTTP 202 Accepted，不用等虚拟机真正启动；Scheduler可以随时上线或下线，只要它监听nova队列，就能捡到任务。

但这也带来了调试难点：问题不出现在代码里，而出现在消息的传递与消费过程中。你可能在Nova API日志里看到INFO nova.api.openstack.compute.servers [-] Triggering async build...，但在Scheduler日志里却找不到任何响应。这时，问题一定出在消息队列的连通性或权限上。

验证消息队列连通性的终极命令（以RabbitMQ为例）：
sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged
正常情况下，nova队列的messages_ready应为0（任务被及时消费），messages_unacknowledged也应为0（无消息卡住）。如果messages_ready > 0且持续增长，说明Scheduler进程挂了或配置错误；如果messages_unacknowledged > 0，说明Scheduler消费了消息但没来得及发送ACK确认，可能是处理超时或崩溃。

3.2 调度算法的四重过滤：从“能运行”到“最优选”

Nova Scheduler不是随机选主机，它执行一套严格的四阶段过滤链（Filter Scheduler），每一步都像一道安检门：

第一道门：ComputeFilter（计算能力过滤）
检查主机CPU、内存、磁盘是否满足虚拟机规格（Flavor）。例如，你申请一个m1.small（1 vCPU, 2GB RAM, 20GB Disk）的虚拟机，Scheduler会查询nova.services表中binary='nova-compute'且status='up'的主机，再查nova.compute_nodes表中对应主机的free_ram_mb >= 2048、free_disk_gb >= 20、vcpus_used < vcpus。注意：这里的free_ram_mb是Nova计算节点上报的值，不是Linuxfree -m的输出！它可能因hypervisor（KVM/QEMU）的内存overcommit策略而不同。

第二道门：AvailabilityZoneFilter（可用区过滤）
检查主机是否在用户指定的可用区（Availability Zone）内。例如，用户在Horizon里选择了nova可用区，Scheduler会过滤nova.services表中availability_zone='nova'的主机。如果所有主机都配置为internal（默认），而用户选了nova，则无主机匹配，直接报错No valid host was found。

第三道门：RamFilter（内存隔离过滤）
这是最容易被忽略的“隐形杀手”。当启用内存超分配（[DEFAULT] ram_allocation_ratio = 1.5）时，Nova允许物理内存被超额分配。但RamFilter会强制检查：即使超分配，单台主机上所有虚拟机的总内存也不能超过physical_ram * ram_allocation_ratio。如果一台主机物理内存16GB，ram_allocation_ratio=1.5，则最大可分配24GB。若已有20GB虚拟机在运行，再申请一个8GB的，就会被此过滤器拒绝。

第四道门：LeastUsedFilter（最少使用率过滤）
这才是真正的“智能选择”。它不看绝对空闲值，而看使用率百分比。计算公式为：host_weight = (free_ram_mb / total_ram_mb) + (free_disk_gb / total_disk_gb)。值越大，说明主机越空闲，权重越高。Scheduler最终会选择权重最高的主机。但注意：这个权重只影响“同条件下的排序”，不改变过滤结果。如果只有两台主机通过前三道门，它才在这两者间比权重；如果只有一台通过，它就直接选这一台，不管权重多低。

实训中一个经典案例：学生创建虚拟机总是失败，日志显示NoValidHost: No valid host was found。排查发现，所有计算节点的nova-compute服务状态都是up，但nova.service-list显示它们的State列为down。原因在于：nova-compute进程虽然在运行，但未能成功向数据库注册心跳（nova.compute_nodes表无更新）。这通常是因为计算节点的nova.conf中[DEFAULT] my_ip配置错误（指向了内网IP而非管理网络IP），导致心跳包发不到Controller节点。解决方案：修正my_ip，重启nova-compute，然后执行nova service-cleanup清理僵尸服务。

3.3 调度结果的落地：数据库里的“宿主绑定”

当Scheduler选定主机（如compute01）后，它做的第一件事不是通知nova-compute，而是立刻更新数据库。它会执行SQL：UPDATE instances SET host='compute01', node='compute01' WHERE uuid='INSTANCE_UUID'。这一步至关重要——它把虚拟机的“归属权”在数据库层面锁定。如果后续nova-compute在compute01上创建失败，Nova会根据这个host字段，将错误状态同步回数据库，并标记实例为ERROR。

为什么这步不能省略？因为OpenStack是分布式系统，nova-api、nova-scheduler、nova-compute可能部署在不同物理机上。如果只靠消息队列传递，一旦nova-compute崩溃，nova-api无法知道虚拟机该归谁管。数据库的host字段是唯一的、强一致的“事实来源”。这也是为什么你在nova list里看到虚拟机状态是BUILD（正在构建），但nova show INSTANCE_ID里OS-EXT-SRV-ATTR:host字段已经显示compute01——数据库更新发生在构建开始前，而非构建完成后。

4. 从消息到实例：nova-compute如何把一行JSON变成一台活的虚拟机

当Scheduler把“在compute01上创建虚拟机”的指令通过消息队列发给nova-compute进程后，真正的魔法才开始。nova-compute不是一个黑盒，它是一套精密的“虚拟机装配流水线”，每一步都依赖外部服务的协同，并将结果实时写入数据库。理解这条流水线，是打通“实训六”任督二脉的关键。

4.1 流水线第一站：Conductor——虚拟机数据的中央厨房

nova-compute收到消息后，第一反应不是调用KVM，而是向nova-conductor发起RPC调用（conductor.instance_get_by_uuid）。这看起来很反直觉：计算节点自己不存数据，为什么要问别人？答案是安全与解耦。nova-compute直接访问数据库会带来两大风险：1）计算节点被攻破，攻击者可直接读写所有虚拟机数据；2）数据库连接数爆炸（每台计算节点都维持长连接）。因此，OpenStack强制所有数据库操作经由nova-conductor代理。

nova-conductor接到请求后，从数据库instances表中拉取该虚拟机的完整元数据：flavor_id（规格）、image_ref（镜像ID）、networks（网络配置）、security_groups（安全组）等。它把这些数据打包成一个Python对象（Instance），再通过消息队列发回给nova-compute。此时，nova-compute才真正拥有了“施工图纸”。

关键细节：nova-conductor返回的Instance对象里，image_ref只是一个UUID（如a1b2c3d4...），不是镜像文件路径。nova-compute需要拿着这个UUID，再去问Glance要真正的镜像URL。这就是为什么Glance服务必须正常——否则nova-compute会卡在“获取镜像”这一步，日志里出现ERROR nova.virt.libvirt.driver [-] Cannot find image a1b2c3d4...。

4.2 流水线第二站：Glance——镜像的“云上仓库”

nova-compute拿到image_ref后，会构造一个HTTP GET请求发给Glance API（http://glance:9292/v2/images/IMAGE_UUID）。这个请求必须携带有效的auth-token（从Keystone获得），否则Glance会返回401。Glance验证Token后，返回镜像的详细信息，其中最关键的是locations字段，它指明了镜像文件的实际存储位置，例如：
"locations": [ { "url": "file:///var/lib/glance/images/a1b2c3d4...", "metadata": {} } ]

对于本地文件存储（Filesystem Store），nova-compute会直接读取这个路径下的qcow2文件；对于对象存储（如Swift、Ceph），它会通过对应的driver下载镜像到本地缓存目录（/var/lib/nova/instances/_base/）。这里有个隐藏性能点：如果镜像很大（如10GB），首次下载会非常慢，且所有计算节点都要重复下载。生产环境通常用Ceph RBD作为后端，镜像以块设备形式存在，nova-compute直接attach，无需下载。

实训避坑：学生常遇到nova-compute日志报Image a1b2c3d4... not found。除了检查Glance服务状态，更要检查/etc/nova/nova.conf中[glance] api_servers是否指向正确的Glance地址（如http://controller:9292），以及[DEFAULT] use_neutron是否为True（影响网络驱动加载）。

4.3 流水线第三站：Neutron——网络的“即插即用”

在下载镜像的同时，nova-compute并行地向Neutron Server发起请求，获取虚拟机所需的网络信息。它会调用GET /v2.0/ports?device_id=INSTANCE_UUID，查询所有绑定到该虚拟机的端口（Port）。每个Port代表一个虚拟网卡，包含mac_address（MAC地址）、fixed_ips（IP地址）、network_id（网络ID）等信息。

Neutron Server收到请求后，会查询其数据库，找到对应的Port记录，再根据network_id查出网络类型（Flat、VLAN、VXLAN）、子网（Subnet）网关、DNS服务器等。最终，它返回一个完整的Port对象给nova-compute。nova-compute拿到后，会调用libvirt的API，为虚拟机创建一个<interface type='bridge'>的XML配置，并将mac_address和fixed_ips注入其中。

网络故障的典型表现：虚拟机创建成功（nova list显示ACTIVE），但无法ping通网关。此时检查neutron port-list --device-id INSTANCE_UUID，如果输出为空，说明Neutron没有为该实例创建Port——常见原因是nova.conf中[neutron] url配置错误，或Neutron Server的ml2_conf.ini中mechanism_drivers未启用openvswitch。

4.4 流水线终点：Libvirt——KVM的“最后一公里”

当镜像、网络、存储（如果用了Cinder）全部就绪，nova-compute终于调用libvirt API，执行最后的创建动作。它会生成一个XML定义文件，核心片段如下：

<domain type='kvm'> <name>instance-00000001</name> <memory unit='MB'>2048</memory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc-i440fx-bionic'>hvm</type> <boot dev='hd'/> </os> <devices> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/nova/instances/.../disk'/> <target dev='vda' bus='virtio'/> </disk> <interface type='bridge'> <mac address='fa:16:3e:xx:xx:xx'/> <source bridge='br-int'/> <model type='virtio'/> </interface> </devices> </domain>

然后执行virsh define和virsh start命令。此时，KVM内核模块被激活，一个真正的Linux进程（qemu-system-x86_64）被创建，它模拟出CPU、内存、硬盘、网卡等硬件，并加载qcow2镜像作为根文件系统。

最后的验证：登录到compute01，执行virsh list --all，你应该看到instance-00000001状态为running；执行ps aux | grep qemu，能看到对应的进程；执行ip netns exec qdhcp-<NETWORK_ID> ip a，能看到DHCP namespace里的IP分配情况。这三步全部成功，才意味着“实训六”的虚拟机，真正从一行代码，变成了一台活的、可交互的云上服务器。

5. 故障诊断全景图：从HTTP 500到qemu进程的逐层穿透

在“实训六虚拟机”的实操中，90%的问题不是功能不会用，而是故障不会诊。学生看到nova list里虚拟机状态卡在BUILD，或直接变成ERROR，第一反应是重启服务、重装系统。这就像医生不看CT片就开刀。真正的高手，懂得沿着OpenStack的请求链路，一层层向下穿透，直到定位到那个具体的、可修复的故障点。

5.1 第一层：Horizon与Nova API的HTTP对话

所有问题始于浏览器。当你在Horizon点击“Launch Instance”，浏览器开发者工具（F12）的Network标签页会捕获到一个POST /dashboard/project/instances/请求。查看它的Response，如果是500 Internal Server Error，说明Horizon后端（Django）调用Nova API失败；如果是400 Bad Request，说明表单填写有误（如镜像不存在）；如果是401 Unauthorized，回到第2节检查Keystone。

快速定位法：在Controller节点，实时监控Nova API日志：
sudo tail -f /var/log/nova/nova-api.log | grep -E "(ERROR|WARNING)"
当你点击创建按钮，如果日志里立刻出现ERROR nova.api.openstack.compute.servers [-] Failed to create instance，说明问题在API层；如果日志静默，说明请求根本没到达Nova API——此时检查Apache/Nginx是否在监听5000端口（sudo ss -tlnp | grep :5000）。

5.2 第二层：Nova服务间的RPC与消息流

如果API日志显示INFO ... Triggering async build...，说明请求已进入异步流程。下一步要看Scheduler和Compute的日志。

Scheduler日志诊断：
sudo tail -f /var/log/nova/nova-scheduler.log | grep -E "(ERROR|WARNING|INFO.*Filter)"

• 如果看到INFO ... Filtered [compute01, compute02]，说明过滤成功；
• 如果看到WARNING ... No hosts passed the filters，说明四重过滤全失败，回到第3节检查主机资源、可用区、内存超配；
• 如果日志完全空白，说明Scheduler没收到消息——检查RabbitMQ队列（sudo rabbitmqctl list_queues）和nova.conf中[DEFAULT] transport_url是否指向正确RabbitMQ地址。

Compute日志诊断：
sudo tail -f /var/log/nova/nova-compute.log | grep -E "(ERROR|WARNING|INFO.*spawn)"

• 如果看到INFO ... Starting instance...，说明已收到调度指令；
• 如果看到ERROR ... Cannot find image，检查Glance；
• 如果看到ERROR ... Failed to get network info，检查Neutron；
• 如果看到ERROR ... libvirtError: internal error: process exited while connecting to monitor，说明KVM/QEMU环境有问题（如CPU不支持虚拟化，/proc/cpuinfo | grep vmx为空）。

5.3 第三层：底层服务与系统状态的交叉验证

当日志指向某个具体服务（如Glance），不要只看它的日志，要进行交叉验证。

Glance验证三板斧：

1. openstack image list—— 能否列出镜像？若报错，检查openstack endpoint list | grep glance，确认endpoint URL正确；
2. curl -H "X-Auth-Token: $TOKEN" http://controller:9292/v2/images—— 直接调用API，绕过CLI；
3. ls -l /var/lib/glance/images/—— 镜像文件是否存在？权限是否为glance:glance？

Neutron验证三板斧：

1. neutron net-list—— 能否列出网络？若报错，检查neutron-server进程是否在运行（sudo systemctl status neutron-server）；
2. ovs-vsctl show—— Open vSwitch桥接是否建立？br-int、br-ex是否存在？
3. ip link show—— 物理网卡（如eth0）是否UP？ovs-system网桥是否绑定到它？

5.4 第四层：KVM与QEMU的终极现场

当nova-compute日志显示Starting instance，但virsh list里没有虚拟机，问题一定在KVM层。

KVM环境检查清单：

• egrep -c "(vmx|svm)" /proc/cpuinfo—— 返回0？说明CPU不支持硬件虚拟化，需在BIOS中开启Intel VT-x或AMD-V；
• lsmod | grep kvm—— 应输出kvm_intel或kvm_amd及kvm；
• dmesg | grep -i kvm—— 查看内核日志，是否有KVM: disabled by BIOS等错误；
• qemu-system-x86_64 --version—— QEMU版本是否兼容？OpenStack Wallaby要求QEMU >= 5.2。

QEMU进程调试：
如果virsh list有虚拟机但状态为paused，执行virsh resume INSTANCE_NAME；如果状态为shut off，执行virsh start INSTANCE_NAME。若报错error: failed to get domain 'instance-00000001'，说明libvirt未加载该域定义，执行virsh define /etc/libvirt/qemu/instance-00000001.xml。

我的压箱底技巧：当所有日志都沉默，用strace抓nova-compute的系统调用。命令：
sudo strace -p $(pgrep -f "nova-compute") -e trace=open,connect,sendto,recvfrom -s 1024 -o /tmp/nova-strace.log
然后创建虚拟机，查看/tmp/nova-strace.log。你会看到它试图connect到127.0.0.1:9292（Glance）却失败，或open("/dev/kvm")返回-1 EPERM（权限不足）。这是最原始、最可靠的故障定位法，比读一百行日志都管用。

6. 实训六的延伸价值：从虚拟机到云原生的思维跃迁

做完“实训六虚拟机”，如果只是记住openstack server create这条命令，那不过是把课本翻到了第六页。真正的价值，在于它为你打开了一扇门，一扇通往云原生世界底层逻辑的门。OpenStack的Nova/Keystone/消息队列，不是过时的技术，而是云基础设施的“汇编语言”。今天你看到的Kubernetes Pod调度、Service Mesh的流量治理、Serverless的函数冷启动，其内核思想，都能在Nova的29步流程里找到原型。

比如，Kubernetes的Scheduler和Nova Scheduler，本质都是“资源匹配器”：前者匹配Pod的requests/limits与Node的allocatable，后者匹配Flavor与Compute Node的free_*；Kubernetes的etcd和Keystone的数据库，都是“单一事实来源”，所有组件必须向它询证；Istio的Sidecar注入，和nova-compute为虚拟机注入网络配置，都是在运行时动态编织基础设施能力。

所以，别把“实训六”当成一个孤立的实验。把它当作一次云基础设施的考古挖掘——你亲手挖出了认证的基石（Keystone）、调度的引擎（Nova Scheduler）、通信的神经（消息队列）、执行的肌肉（nova-compute/libvirt）。下次看到“K8s Pod Pending”，你会本能地去查kubectl describe pod里的Events，就像现在你会查nova-compute.log；看到“Service Mesh流量异常”，你会想到Neutron的Port Binding和OVS流表，就像现在你会查ovs-ofctl dump-flows br-int。

这，才是“实训六虚拟机”最不该被忽略的结尾。它不教你如何应付考试，而是给你一把解剖刀，让你未来面对任何云技术，都有能力切开表皮，看清血管与神经的走向。毕竟，所有炫目的云服务，都不过是这套古老而坚实的逻辑，在更高维度上的优雅复现。