1. 这不是 Laravel Nova是 OpenStack Nova——实训课里最常被搞混的“双胞胎”刚看到标题“实训6 Nova 的手动安装与配置”我下意识点开就准备写 Laravel Nova 的 Composer 安装流程——结果翻到热词列表里赫然出现“vmware虚拟机安装教程”“ubuntu22.04安装教程”“docker安装”“mysql安装配置教程”再结合“实训6”这个典型高校云计算/虚拟化课程编号立刻反应过来这根本不是 PHP 后台管理面板 Laravel Nova而是 OpenStack 项目中负责计算服务的核心组件——OpenStack Nova。这个混淆太普遍了。我在三所高校带过 OpenStack 实训课每届都有至少三分之一的学生在第一次实验时把 Nova 当成 Laravel Nova 去composer require laravel/nova然后卡死在许可证密钥验证环节最后发现连 Ubuntu 系统都没装好。为什么因为名字撞车但技术栈天差地别Laravel Nova 是个基于 PHPVue 的 Web 管理界面而 OpenStack Nova 是一套运行在 Linux 服务器上的、由 Python 编写的分布式计算服务集群它要调度 KVM 虚拟机、对接 MySQL 数据库、依赖 RabbitMQ 消息队列、调用 Glance 镜像服务、向 Neutron 请求网络资源……它根本不需要 Composer也不认.env文件里的NOVA_LICENSE_KEY。所以先划重点本实训中的Nova OpenStack Compute Service它的安装不是“下载一个包、执行一条命令”而是一整套基础设施的协同部署。你手头的实训手册里如果写着“在控制节点上安装 nova-api、nova-scheduler”那它指的就是 OpenStack Nova如果写着“运行php artisan nova:install”那才是 Laravel Nova——但后者根本不会出现在“云计算实训”这种课程里。这也解释了为什么热搜词里全是系统级工具mysql安装配置教程对应 Nova 的数据库后端rabbitmq安装虽未明写但必用对应消息总线keystone安装OpenStack 认证服务是 Nova 的身份守门人glance安装提供镜像支撑。它们不是可选插件而是 Nova 能跑起来的氧气和血液。跳过其中任何一个Nova 就是具无法呼吸的躯壳——API 服务启动了但一创建虚拟机就报No valid host was foundscheduler 进程活着但日志里全是Failed to get project info from keystone。我带过的最典型翻车案例学生按某份过时博客在单台 Ubuntu 20.04 上用apt install nova-api nova-scheduler一键装完以为大功告成。结果访问http://localhost:8774/v2.1/返回 503查日志发现ERROR nova.service Unable to connect to database——他压根没装 MySQL也没建 nova 数据库更没执行nova-manage db sync。这就是把“安装软件包”和“部署服务”画等号的后果。真正的手动安装90% 的时间花在配置文件校验、服务依赖梳理、防火墙端口放开、SELinux 策略调整上而不是敲apt install的那三秒钟。所以这篇实训复盘不讲“怎么点下一步”而是带你回到实验室现场从 VMware 里新建一台 Ubuntu 22.04 虚拟机开始一步步亲手拧紧每一颗螺丝让 Nova 真正成为你掌控的计算引擎而不是一个黑盒报错的摆设。2. 实训环境重建为什么必须用 Ubuntu 22.04 而不是随便找个镜像实训课最坑人的地方往往藏在第一步——环境准备。很多学生直接拿自己电脑上现成的 Windows Subsystem for LinuxWSL2或 Docker Desktop 里的 Ubuntu 镜像开干结果卡在modprobe kvm_intel报错或者virsh list显示error: failed to connect to the hypervisor。这不是你操作错了是底层环境根本不支持。OpenStack Nova 的核心能力是调度和管理 KVM 虚拟机这意味着它对宿主机有硬性要求CPU 必须支持硬件虚拟化Intel VT-x 或 AMD-V且 BIOS 中已开启内核必须加载kvm和kvm_intel或kvm_amd模块libvirt服务必须能正常连接到qemu:///system管道/dev/kvm设备节点必须存在且权限正确。而 WSL2 的内核是微软定制的它把 KVM 功能完全剥离只保留用户态模拟Docker Desktop 的 LinuxKit 内核同样阉割了 KVM 支持。你在这上面装再多遍nova-compute它也永远无法创建出一台真正的虚拟机——它连“生孩子”的产房都没有。所以实训第一步必须是在物理机或 VMware Workstation/Pro 中创建一台原生 Linux 虚拟机。我强烈推荐 VMware 而非 VirtualBox原因很实在VMware 对嵌套虚拟化的支持更稳定vmx文件里一行vhv.enable TRUE就能打开 Intel VT-x 嵌套而 VirtualBox 的嵌套虚拟化经常抽风导致nova-compute启动后疯狂报libvirtError: internal error: process exited while connecting to monitor。至于发行版为什么锁定 Ubuntu 22.04看官方文档就知道OpenStack 2023.2Antelope版本明确将 Ubuntu 22.04 列为首选生产环境其 APT 仓库里预编译的nova-*包已针对该系统内核5.15和 Python 版本3.10做过深度适配。你用 Ubuntu 20.04 会遇到python3-neutronclient依赖冲突用 CentOS Stream 9 则要自己编译libvirt光./configure就能卡半小时。我试过用 Ubuntu 24.04结果nova-scheduler死活连不上 RabbitMQ查了一晚上才发现是erlang版本不兼容——22.04 的erlang-24和 OpenStack Antelope 是经过千次 CI 测试的黄金组合。具体配置建议这是我在实验室真实跑通的最低配置CPU2 颗 vCPU必须勾选“虚拟化 Intel VT-x/EPT”内存4GBNova 控制节点最低要求少于 3GB 会导致nova-apiOOM 被 kill硬盘40GB系统盘不要用 LVM实训阶段越简单越好网络NAT 模式用于访问外网下载包再加一块仅主机模式网卡用于后续 Neutron 内部通信实训初期可暂不启用安装系统时务必选择OpenSSH server否则你连不上虚拟机并取消勾选Download updates while installing Ubuntu避免安装过程因网络问题中断。装完第一件事不是装 Nova而是执行这三行命令sudo apt update sudo apt upgrade -y sudo apt install -y net-tools curl wget vim sudo reboot别小看net-tools——ifconfig在排查网络问题时比ip a直观十倍curl和wget是后续下载配置脚本的命脉vim是修改/etc/nova/nova.conf的刚需。我见过太多学生卡在nano里找不到保存键最后CtrlX退出却忘了按Y改了一小时配置全白费。提示如果你的物理机是 WindowsVMware Workstation Player 是免费的足够应付实训如果是 macOSParallels Desktop 学生认证后免费性能比 VirtualBox 好太多。千万别用国产虚拟机它们对嵌套虚拟化的支持文档几乎为零出了问题连报错都看不懂。3. 手动安装的本质不是执行命令而是理解服务间的握手协议“手动安装 Nova” 这个说法极具误导性。它听起来像在应用商店点“安装”但实际是一场精密的多服务协同仪式。Nova 不是一个独立程序而是一组相互依赖的守护进程daemon每个进程都扮演特定角色并通过标准化协议与其他服务“握手”。忽略这个本质就等于在不懂交通规则的情况下开车上路——车能发动但随时可能撞墙。我们来拆解 Nova 的核心服务及其握手对象Nova 服务启动命令核心职责必须握手的服务握手失败典型报错nova-apisudo systemctl start nova-api接收 REST API 请求如创建虚拟机MySQL, RabbitMQ, KeystoneERROR nova.service Unable to connect to database/Failed to connect to AMQP servernova-schedulersudo systemctl start nova-scheduler决定把虚拟机调度到哪台计算节点MySQL, RabbitMQ, KeystoneNo valid host was found找不到可用计算节点nova-conductorsudo systemctl start nova-conductor作为nova-compute和数据库的中间人避免计算节点直连 DBMySQL, RabbitMQERROR nova.conductor.manager Database connection failednova-computesudo systemctl start nova-compute真正创建、管理 KVM 虚拟机的进程libvirt, RabbitMQ, Glance, NeutronlibvirtError: internal error: process exited while connecting to monitor看到没MySQL 和 RabbitMQ 是所有 Nova 服务的公共基石。没有它们nova-api连数据库都连不上nova-scheduler就算算出最优节点也发不出指令。所以手动安装的第一步永远不是apt install nova-api而是3.1 先立地基MySQL 与 RabbitMQ 的精准配置很多实训手册一笔带过“安装 MySQL”但实际配置中字符集和远程访问权限是两大雷区。Nova 的数据库表名含下划线字段名含连字符若 MySQL 默认字符集是latin1nova-manage db sync会直接报Specified key was too long错误。解决方案是修改/etc/mysql/mysql.conf.d/mysqld.cnf[mysqld] # 必须添加这两行否则 Nova 表创建失败 collation-server utf8mb4_unicode_ci init-connectSET NAMES utf8mb4 character-set-server utf8mb4 # 开启远程访问实训环境允许生产环境严禁 bind-address 0.0.0.0重启 MySQL 后创建 Nova 数据库和用户CREATE DATABASE nova_api CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE DATABASE nova_cell0 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_api.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_cell0.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_cell0.* TO nova% IDENTIFIED BY NOVA_DBPASS; FLUSH PRIVILEGES;注意nova_cell0数据库——这是 OpenStack 的细胞cell架构必需的用于未来水平扩展计算节点实训阶段虽不启用但数据库必须存在否则nova-manage api_db sync会失败。RabbitMQ 同样关键。Nova 用它传递“创建虚拟机”“迁移虚拟机”等异步任务。Ubuntu 22.04 的 APT 仓库默认安装的是rabbitmq-server3.9.x它需要手动启用rabbitmq_management插件才能用 Web 界面监控队列sudo rabbitmq-plugins enable rabbitmq_management sudo systemctl restart rabbitmq-server然后创建 Nova 用户并设置权限sudo rabbitmqctl add_user openstack RABBIT_PASS sudo rabbitmqctl set_permissions openstack .* .* .* sudo rabbitmqctl set_user_tags openstack administrator这里RABBIT_PASS是你自定义的密码必须和后续nova.conf里transport_url字段的密码一致。我见过学生在这里输错一个字母结果nova-scheduler日志里全是AMQP server closed the connection查了两小时才发现是密码不匹配。3.2 第二步Keystone 认证服务——Nova 的“身份证查验员”Nova 绝不信任任何未经 Keystone 认证的请求。当你执行openstack server create时CLI 工具先向 Keystone 索要一个临时 Token再把这个 Token 放在Authorization: Bearer token头里发给nova-api。nova-api收到请求后第一件事就是拿着这个 Token 去问 Keystone“这玩意儿真有效吗有效期到几点用户属于哪个项目”所以没有 KeystoneNova 就是聋子和哑巴。实训中常有人跳过 Keystone 直接装 Nova结果openstack server list返回The request you have made requires authentication.。解决方法不是重装 Nova而是补上 Keystone。Keystone 安装本身不复杂但配置文件/etc/keystone/keystone.conf里的[database]和[token]段落必须精准[database] connection mysqlpymysql://keystone:KEYSTONE_DBPASScontroller/keystone [token] provider fernetfernet是 OpenStack 推荐的轻量级 Token 加密方式比 UUID 更安全。初始化 Fernet 密钥sudo keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone sudo keystone-manage credential_setup --keystone-user keystone --keystone-group keystone最关键的一步是引导 Keystonesudo keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne这里ADMIN_PASS是你设定的管理员密码controller是你的主机名必须在/etc/hosts里解析到本机 IP。漏掉--bootstrap-region-id RegionOne后续 Nova 会报RegionOne is not a valid region。做完这些nova-api才能通过auth_url http://controller:5000/v3找到 Keystone用admin用户和ADMIN_PASS密码完成服务注册。这个注册动作是手动安装 Nova 的临门一脚openstack service create --name nova --description OpenStack Compute compute openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute internal http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute admin http://controller:8774/v2.1没有这四条命令nova-api进程虽然在跑但 Keystone 根本不知道它的存在所有 API 请求都会被拒绝。这就是为什么手动安装不是“执行命令”而是确保每个服务都拿到它需要的“钥匙”数据库密码、RabbitMQ 密码、Keystone Token并把自己的“门牌号”endpoint挂到服务目录里。4. 配置文件深挖nova.conf里那些决定成败的 7 个关键段落/etc/nova/nova.conf是 Nova 的心脏起搏器。它不像.env文件那样只有几行而是一个超过 2000 行的庞然大物但真正决定实训能否成功的往往只是其中 7 个段落section里的十几行配置。我把它称为“Nova 生存七要素”漏掉任何一个服务就无法启动或功能残缺。4.1[DEFAULT]段落全局开关与基础路径这是所有配置的起点必须最先检查[DEFAULT] # 必须设置否则 nova-scheduler 找不到计算节点 transport_url rabbit://openstack:RABBIT_PASScontroller # API 绑定地址实训环境用 0.0.0.0 允许外部访问 my_ip 10.0.0.11 # 替换为你虚拟机的 IP # 启用元数据服务虚拟机内部获取 SSH 密钥、用户数据的关键 use_neutron true # 禁用防火墙驱动实训简化生产环境需配置 firewall_driver nova.virt.firewall.NoopFirewallDrivermy_ip是最大陷阱。很多学生直接抄手册写127.0.0.1结果nova-compute启动后日志里全是Unable to connect to http://127.0.0.1:9292——因为它试图用127.0.0.1去连 Glance但 Glance 服务实际监听在0.0.0.0:9292而127.0.0.1只能访问本机回环无法穿透。正确做法是ip a查出你的网卡 IP通常是ens33或eth0填进去。4.2[api_database]与[database]双数据库的分工逻辑Nova 使用两个数据库nova_api存 API 相关元数据如请求记录、配额nova存核心数据如虚拟机状态、实例信息。配置必须严格对应[api_database] connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api [database] connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova注意nova_api和nova是两个不同的数据库名密码NOVA_DBPASS必须和 MySQL 创建时一致。执行同步命令时顺序不能错# 先同步 API 数据库 sudo nova-manage api_db sync # 再同步主数据库 sudo nova-manage db sync # 最后注册 cell0必须做否则 nova-compute 启动失败 sudo nova-manage cell_v2 map_cell0 sudo nova-manage cell_v2 create_cell --namecell1 --verbosemap_cell0命令会生成一个 UUID把它记下来后面create_cell会用到。漏掉map_cell0nova-compute日志里会出现Cell0 database is not mapped。4.3[keystone_authtoken]Nova 与 Keystone 的“暗号”这是 Nova 证明自己身份的凭证配置错误会导致401 Unauthorized[keystone_authtoken] www_authenticate_uri http://controller:5000/ auth_url http://controller:5000/ memcached_servers controller:11211 auth_type password project_domain_name Default user_domain_name Default project_name service username nova password NOVA_PASS # 必须关闭否则和 Keystone V3 协议冲突 delay_auth_decision falseproject_name service和username nova是 Keystone 里创建的服务用户密码NOVA_PASS必须和openstack user create --password时设置的一致。delay_auth_decision false是关键OpenStack Antelope 版本强制要求关闭此选项否则nova-api启动即崩溃。4.4[oslo_concurrency]锁机制的生死线Nova 用文件锁防止并发冲突如同时创建两台同名虚拟机。配置错误会导致nova-scheduler卡死[oslo_concurrency] lock_path /var/lib/nova/tmp/var/lib/nova/tmp目录必须存在且nova用户有读写权限sudo mkdir -p /var/lib/nova/tmp sudo chown -R nova:nova /var/lib/nova/tmp4.5[glance]镜像服务的“粮仓”对接Nova 自己不存镜像全靠 Glance。配置指向错误创建虚拟机会报Image 12345678-... could not be found[glance] api_servers http://controller:9292http://controller:9292必须和 Glance 的bind_host和bind_port一致。Glance 默认监听0.0.0.0:9292所以这里写controller即可。4.6[neutron]网络服务的“血管”连接即使实训只做单机也要配置 Neutron否则虚拟机无法分配 IP[neutron] url http://controller:9696 auth_url http://controller:5000 project_domain_name Default user_domain_name Default region_name RegionOne project_name service username neutron password NEUTRON_PASS service_metadata_proxy true metadata_proxy_shared_secret METADATA_SECRETservice_metadata_proxy true启用元数据代理让虚拟机内部能通过http://169.254.169.254获取 SSH 密钥metadata_proxy_shared_secret是 Nova 和 Neutron 元数据代理之间的共享密钥必须两边一致。4.7[libvirt]KVM 虚拟化的“引擎盖”这是nova-compute的核心配置错误直接导致虚拟机无法启动[libvirt] # 指定虚拟化类型KVM 是标准 virt_type kvm # 关闭对 CPU 特性的严格检查实训环境兼容性优先 cpu_mode none # 启用 QEMU/KVM 的嵌套虚拟化方便后续实验 hw_disk_bus virtio # 指定镜像存储位置避免默认的 /var/lib/nova/instances 占满根分区 instances_path /var/lib/nova/instancescpu_mode none是关键。如果你的 CPU 不支持某些新特性如 AVX-512cpu_mode host-passthrough会导致nova-compute启动失败报libvirtError: unsupported configuration: CPU mode host-passthrough for x86_64。设为none让 KVM 自动适配。配置完所有段落终极校验命令是sudo nova-manage config check它会逐行扫描nova.conf输出所有错误和警告。只有当它静默返回无输出时才代表配置语法正确。别急着systemctl start先过这一关。5. 启动与排错从systemctl status到日志深潜的完整链路配置文件写完systemctl start nova-api却显示failed别慌这是实训中最常态的场景。手动安装的价值恰恰在于逼你学会像医生一样诊断服务——不是重启了事而是顺着症状一层层剥开日志找到病灶。5.1 第一层筛查systemctl status的隐藏信息很多人只看Active: inactive (dead)就放弃其实systemctl status输出里藏着关键线索。以nova-api为例sudo systemctl status nova-api重点看三处Loaded:行末尾的enabled; vendor preset: enabled表示服务已启用Main PID:后的数字是进程 ID若为?说明进程根本没起来最下方的journalctl -u nova-api -n 50 -f是日志查看命令必须执行它。但journalctl默认只显示最近 1000 行而 Nova 启动失败的日志往往在更早位置。所以正确姿势是# 查看全部日志从最早开始 sudo journalctl -u nova-api --no-pager | head -n 50 # 或者实时跟踪最新日志启动服务时运行 sudo journalctl -u nova-api -f5.2 第二层深潜/var/log/nova/下的四大日志文件Nova 把日志分门别类放在/var/log/nova/每种日志对应不同故障域日志文件主要记录内容典型错误关键词nova-api.logAPI 接收、路由、认证失败事件401 Unauthorized,Connection refused to keystonenova-scheduler.log调度决策过程、主机过滤、权重计算No valid host was found,Filter ComputeFilter returned 0 hostsnova-conductor.log数据库操作、RPC 调用、跨服务协调Database connection failed,Timeout waiting for RPC responsenova-compute.logKVM 虚拟机创建、libvirt 调用、网络配置libvirtError,Failed to create domain,No network named default举个实战案例学生执行openstack server create后虚拟机状态一直是BUILD查nova-scheduler.log发现INFO nova.filters [req-abc123...] Filter ComputeFilter returned 0 hosts这说明nova-scheduler找不到可用的计算节点。原因是什么继续查nova-compute.log发现ERROR nova.compute.manager [req-def456...] Failed to get compute node record再查nova-conductor.log看到ERROR nova.conductor.manager [req-ghi789...] Database connection failed于是真相大白nova-conductor连不上数据库导致nova-compute无法注册到服务目录nova-scheduler自然找不到它。根源在nova.conf的[database]段落密码错误。5.3 第三层定位用ps和netstat验证进程与端口有时日志里没报错但服务就是不工作。这时要用系统级工具验证ps aux | grep nova确认进程是否真的在运行。nova-api应该有多个nova-api进程worker 进程若只有一行grep说明没起来。sudo ss -tlnp | grep :8774检查nova-api是否监听在 8774 端口。若无输出说明服务没绑定端口大概率是nova.conf的[DEFAULT]段落my_ip配置错误或防火墙拦截。sudo virsh list --all验证nova-compute是否能连接 libvirt。若报error: failed to connect to the hypervisor说明libvirtd服务没启动或当前用户不在libvirt组。修复libvirtd问题的命令sudo systemctl enable libvirtd sudo systemctl start libvirtd sudo usermod -a -G libvirt $USER # 重新登录或重启虚拟机使组生效5.4 终极武器nova-manage的诊断命令OpenStack 提供了强大的内置诊断工具比瞎猜高效十倍# 检查所有服务是否在数据库中注册 sudo nova-manage service list # 输出类似 # Binary Host Zone Status State Updated_At # nova-consoleauth controller internal enabled :-) 2024-06-15 10:20:30 # nova-scheduler controller internal enabled :-) 2024-06-15 10:20:32 # nova-conductor controller internal enabled :-) 2024-06-15 10:20:31 # 检查 cell 架构是否就绪 sudo nova-manage cell_v2 list_cells # 检查数据库 schema 是否匹配 sudo nova-manage db versionnova-manage service list是黄金命令。如果nova-compute显示XXX叉号而非:-)笑脸说明它没成功注册到数据库此时不用看日志直接去查nova-compute.log里关于cell_v2的报错。我总结的排错心法是从上到下从外到内。先看nova-api对外接口是否响应再看nova-scheduler大脑是否决策接着查nova-conductor神经中枢是否通畅最后盯nova-compute手脚是否执行。每一步都用对应的日志和命令交叉验证形成闭环。这样哪怕面对一个全新的报错你也能在 15 分钟内定位到根因而不是在百度里翻三天。6. 实训验证用一条openstack命令走通 Nova 全链路配置和启动都完成了怎么证明 Nova 真的活了不是看systemctl status显示active (running)而是用一条命令触发 Nova 的完整工作流从接收 API 请求到调度决策再到创建虚拟机。这条命令就是openstack server create --flavor m1.tiny --image cirros-0.6.2-x86_64-disk --nic net-idNETWORK_ID --security-group default --key-name mykey test-instance但直接执行会失败——因为你还没准备好“弹药”。完整的验证链路需要 5 个前置步骤缺一不可6.1 步骤一准备 Cirros 镜像最小化测试镜像Cirros 是专为云环境设计的超轻量 Linux 镜像 20MB启动快、依赖少是 Nova 测试的黄金标准。下载并上传到 Glancewget https://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img openstack image create cirros-0.6.2-x86_64-disk \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 --container-format bare \ --public--public参数让所有项目都能使用此镜像。执行后openstack image list应看到cirros-0.6.2-x86_64-disk状态为active。6.2 步骤二创建网络Neutron 的“高速公路”Nova 需要网络才能给虚拟机分配 IP。创建一个提供 DHCP 的私有网络# 创建网络 openstack network create --share --provider-network-type flat --provider-physical-network provider provider-net # 创建子网假设你的物理网卡是 ens33IP 段为 10.0.0.0/24 openstack subnet create --network provider-net --subnet-range 10.0.0.0/24 --gateway 10.0.0.1 --dhcp --dns-nameserver 8.8.8.8 provider-subnet--share让所有项目共享此网络--dhcp启用 DHCP 服务虚拟机启动后自动获取 IP。6.3 步骤三创建安全组虚拟防火墙默认的default安全组只放行 ICMPping和 SSH需手动添加openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default6.4 步骤四创建密钥对SSH 登录凭证ssh-keygen -t rsa -N -f ~/.ssh/id_rsa openstack keypair create --public-key ~/.ssh/id_rsa.pub mykeymykey是密钥对名称后续创建虚拟机时指定它Nova 会自动把公钥注入虚拟机的~/.ssh/authorized_keys。6.5 步骤五执行创建命令并全程追踪现在执行最终验证命令替换NETWORK_ID为openstack network list输出的 IDopenstack server create --flavor m1.tiny --image cirros-0.6.2-x86_64-disk --nic net-idNETWORK_ID --security-group default --key-name mykey test-instance成功后立即执行# 查看虚拟机状态应从 BUILD 变为 ACTIVE openstack server list # 查看详细信息重点关注 networks 字段应有 IP 地址 openstack server show test-instance # 实时查看 nova-compute 日志见证 KVM 启动全过程 sudo tail -f /var/log/nova/nova-compute.log在nova-compute.log里你会看到清晰的 KVM 启动日志INFO nova.virt.libvirt.driver [req-...] Creating instance with XML: domain typekvm... INFO nova.virt.libvirt.driver [req-...] Instance spawned successfully. INFO nova.compute.manager [req-...] Got network info: [{address: 10.0.0.3, ...}]