openstack 创建云主机的8步实操指南与常见问题处理

在企业私有云和实验环境里，openstack 创建云主机几乎是每天都会碰到的操作。界面上看只是点几步，真到交付时，问题往往出在前置资源：镜像不可用、网络没配通、配额不够、安全组没放行，或者实例虽然建出来了，人却登不上去。

把这件事做顺，不能只记住控制台里的“创建实例”按钮。实例能不能正常启动、能不能拿到IP、能不能对外提供服务，取决于镜像、规格、网络、安全组、密钥对和存储是不是配套。少看一项，后面就容易返工。

如果你是刚接触 OpenStack，这篇内容可以当作一套标准流程来用；如果你已经在日常运维里经常建机，也可以拿它对照一下自己的检查项有没有漏。

创建前先看清这4个条件

很多“创建失败”并不是平台故障，而是资源没准备好。建实例前，先把下面几项过一遍，能省掉不少排查时间。

• 项目配额够不够：看清楚 vCPU、内存、实例数量、卷数量、浮动 IP 数量有没有余量。尤其是测试环境，闲置资源多，配额反而经常被占满。
• 镜像能不能用：常见镜像有 Ubuntu、CentOS、Rocky、Windows。别只看名字，状态要是可用，版本也要符合业务要求。
• 网络是不是齐：至少要有实例能接入的私有网络。要对外访问，还得确认路由器和外部网络已经接好，不然浮动 IP 也派不上用场。
• 登录方式有没有提前准备：Linux 一般走密钥对，Windows 更依赖密码或控制台登录。创建前没配好，后面只能绕路处理。

生产环境还要多看几眼命名规范、可用区策略、规格标准和安全组模板。测试环境里临时起名问题不大，生产环境随手创建，后面盘点和迁移都会麻烦。

openstack 创建云主机会用到哪些资源

很多人第一次接触 OpenStack，会把云主机当成一个单独对象。实际上，实例只是结果，启动过程靠多个组件一起配合。哪个环节有短板，最后都会体现在“机器建好了但不好用”。

镜像

镜像决定操作系统和基础环境。镜像做得规范，实例启动后通常能顺利完成初始化；镜像封装有问题，就可能出现启动卡住、拿不到 IP、cloud-init 失败这些情况。建机前只看系统版本不够，镜像质量同样重要。

Flavor 规格

规格定义 vCPU、内存和临时磁盘。像 2 核 4G、4 核 8G 这类配置最常见。规格选小了，业务跑起来会吃紧；选大了，资源占着不用，项目配额也很快见底。测试环境通常可以先从小规格起，确认负载后再调。

网络与子网

实例至少要接一个租户网络。要不要挂浮动 IP，取决于访问方式：如果只是内网应用，固定 IP 够用；如果要从外部直接访问，通常就得绑定浮动 IP，或者通过负载均衡、堡垒机、VPN 这类路径进来。

安全组

安全组就是实例侧的虚拟防火墙。很多人看到实例状态已经是 Active，就以为交付完成，结果 SSH 连不上、网页打不开，最后发现是 22、80、443 根本没放开。安全组不对，实例再正常也等于没交付。

密钥对

Linux 主机更适合用 SSH 密钥对登录，安全性和日常管理都更稳。如果建机时没注入公钥，后面想无密码接入会比较麻烦，只能走控制台修或者重建实例。

openstack 创建云主机的8步标准流程

以一台 Ubuntu 的 Web 测试机为例，这套流程在 Horizon 控制台里基本通用。

1. 登录 Horizon 控制台，确认项目没选错。多租户环境里，这一步很容易被忽略。项目一旦选错，看到的网络、镜像和配额都不是你要用的。
2. 先查配额余量。别等参数都填完才发现实例数、CPU、内存或者卷容量不够，白走一遍流程。
3. 进入“实例”页面创建新实例，按命名规范填写名称，比如 web-test-01。名字最好能看出用途和环境，后面排查比一串随意命名省事得多。
4. 选择镜像，比如 Ubuntu 22.04。这里除了确认镜像状态，还要看版本是不是和应用兼容，别为了图新直接上最新版本。
5. 选择规格，例如 2 vCPU、4GB 内存。测试场景可以先保守一些，但也别小到系统起来后连基础服务都跑得吃力。
6. 选择网络，接入业务私网，例如 net-app-test。业务需要多网卡时，再额外挂接其他网络，别为了“以后可能会用”先全挂上，排障会更复杂。
7. 配置安全组和密钥对。至少确认 SSH 22 端口已放通；如果要部署 Nginx，80 和 443 也要一并开好。密钥对尽量选已有、可确认可用的，不要临时导一个自己也没验证过的公钥。
8. 提交创建并等待调度完成。实例状态变成 Active 只是第一步，后面还要做登录验证、网络测试和服务检查。

从界面操作看，openstack 创建云主机确实不复杂。难点不在按钮，而在资源之间能不能对得上：镜像支不支持 cloud-init，DHCP 有没有正常分配地址，安全组规则是不是匹配访问需求，这些细节才决定实例能不能落地可用。

案例：15分钟交付一台测试 Web 云主机

有个很常见的场景：测试团队临时要上一套页面，要求半小时内给出可访问环境。这种时候，速度靠的不是手快，而是前面的标准化工作做得够不够。

• 实例名称：web-demo-01
• 镜像：Ubuntu 22.04 基础镜像
• 规格：2核4G
• 系统盘：40GB 云硬盘
• 网络：test-net
• 安全组：放通 22、80、443
• 登录方式：绑定已有密钥对

实例创建完成后，先看固定 IP 有没有正常拿到，再绑定浮动 IP。接着通过 SSH 登录，安装并启动 Nginx，最后用浏览器直接访问浮动 IP 检查页面。整套流程下来，大约 15 分钟能交付。

这个场景里，快的原因不是“点得熟”，而是镜像模板、网络规划、安全组和密钥体系都已经提前准备好了。每次都临时决定规格、临时开规则、临时找登录方式，时间基本都耗在返工上。

实例创建完成后，至少做这5项验证

实例状态到了 Active，不代表业务可用。交付前最好按顺序检查，不然后面很容易出现“云主机已经给了，但服务用不了”的情况。

1. 控制台能不能登录。先确认系统不是卡在引导阶段，尤其是新镜像或自定义镜像，控制台信息很有参考价值。
2. 固定 IP 是否获取正常。如果没拿到 IP，重点看子网 DHCP、端口状态和网络绑定，不要一上来就怀疑系统本身。
3. 安全组规则是否生效。从实际端口去测，22、80、443 这些常用端口最容易漏。
4. 浮动 IP 能不能访问。有公网访问需求时，要一起确认路由和 NAT 链路，不是绑定了浮动 IP 就一定能通。
5. 业务进程是否正常。Web、数据库、Agent 装完后要确认服务已启动，必要时设为开机自启，避免实例重启后服务消失。

很多团队的问题不在创建，而在交付前没验证。机器建好就甩给使用方，等对方反馈连不上、访问不了、服务没起，排查链路会更长。把这几项固定成清单，能挡住不少低级问题。

openstack 创建云主机时最常见的6类问题

实例一直停留在 Build

常见原因有计算节点资源不足、调度失败、镜像拉取异常。遇到这种情况，别反复删了重建，先看 Nova 调度日志和计算节点状态，能更快判断卡在哪一层。

创建后无法登录

优先检查密钥对有没有正确注入，安全组有没有放行 22 端口，再看实例内部 SSH 服务是不是正常。有时控制台能进、SSH 进不去，问题多半就在这几个点。

云主机拿不到 IP

这类问题通常和网络资源有关，像子网 DHCP、端口绑定、虚拟交换配置都可能有影响。只在实例里排查意义不大，Neutron 侧也要一起看。

实例能创建，但访问不了公网

一般是没绑浮动 IP、路由器没接外部网络，或者安全组和出口策略没放行。很多时候固定 IP 正常、内网也通，唯独公网不通，就是这条链路中间断了。

提示配额不足

这是最常见也最容易被忽略的问题。先看项目里有没有闲置实例、没用的卷、占着不放的浮动 IP，能清理的先清理；确实不够，再找管理员调配额。

磁盘空间或性能不符合预期

系统盘太小，前期看不出问题，业务一跑日志一写，很快就会告警。对有数据落盘需求的应用，别把所有内容都压在系统盘上，云硬盘该单独规划就单独规划。

想把创建效率提上来，可以这样做

• 把模板先收敛好：镜像、规格、安全组、命名规则统一下来，建机时少做临场判断，错误率会低很多。
• 批量场景尽量走自动化：如果经常要一次建多台，可以用 OpenStack CLI、Heat 或 Terraform。手工点一两台没问题，数量一上去就容易漏配置。
• 创建后的检查不要省：网络、登录、端口、服务这几项做完再交付，能避免“建成不可用”的尴尬。

openstack 创建云主机说到底不是单一动作，而是一套交付流程。单台测试机也好，批量业务节点也好，只要前置资源清楚、创建步骤规范、验证动作到位，交付就会稳很多。对初学者来说，先把单台实例的标准流程跑熟，再去碰命令行、模板化编排和故障排查，会更顺手。