有人问我，一天之内能不能把云平台搭起来，还能在上面顺利开出第一台虚拟机？我的回答是：能，但有明确的前提。你要是奔着生产环境那种多节点、高可用、带存储和网络虚拟化全家桶去的，那我劝你直接放弃这个念头；但如果你只是想在一台机器上，把云平台的核心链路完整跑通，然后用浏览器或命令行创建出属于自己的云主机，那这件事完全可以在一个工作日内完成。这篇文章不是概念科普，也不是PPT式的流程图，而是一份可以直接照着做的实操记录，适合刚开始接触云计算的运维、开发，以及想给自己团队搭一套轻量私有云做测试的人。
1. 一天搭出云平台，先搞清楚你搭的是哪种“云”
1.1 演示级云平台与生产级云平台的差距
很多人一听到“搭云平台”，脑子里立刻浮现出OpenStack那套庞大的架构：控制节点、计算节点、网络节点、存储节点，光服务名就能把人绕晕。事实确实如此，一套生产级的OpenStack集群，规划网络、配置高可用、调存储性能，没个两三周根本下不来，更别提后续的监控、日志、容器集成。但“一天搭出来的云平台”显然不是这个量级——它是单机、all-in-one、纯演示和测试用途的环境。
这个环境能做什么？它能让你直观体验到IaaS平台的核心流程：上传镜像、定义规格、创建网络、分配浮动IP、启动实例、SSH登录。你看到的操作路径和生产环境基本一致，API也是同一套，但复杂度被极度压缩。换句话说，它是一台“教学飞机”，不能载客，但能让你把起飞和降落整套动作练熟。
所以先降低心理预期：本文说的“1 Day搭建”，目标不是生产可用的云平台，而是一条能看到虚拟机真实跑起来的完整IaaS链路。搞清楚这个边界，后面每一步都不会纠结为什么有些功能不完整。
1.2 为什么选择DevStack这条路线
市面上的云平台搭建方案不少。ZStack这类商用开源产品，安装确实快，但部分高级能力跟商业版绑定；Proxmox VE本质是虚拟化集群管理平台，虚拟机管理做得很好，但缺少OpenStack那种完整的多租户、计量、API生态；OpenNebula也挺优秀，但社区资料相对少。
选DevStack的核心原因是：它本身就是OpenStack官方提供的开发测试部署工具，用一套shell脚本把一个最小可用OpenStack环境拉起来，背后是社区大量开发者每天都在用的路径。你通过DevStack搭出来的环境，今天可以用来学虚拟机创建，明天可以继续学Neutron网络，后天可以接Heat编排，功能边界很清晰，不会学歪。
另外，网上关于“openstack云平台搭建”的教程虽然多，但大部分版本老旧，或者直接拿生产部署工具（比如Kolla-Ansible）去跑单机，配置复杂度高，出了问题新手根本无从下手。DevStack的命令输出非常直白，日志全部落在/opt/stack/logs目录下，排查问题比大多数工具都容易，这一点对一天内完成搭建至关重要。
1.3 一天时间怎么分配
我说的“一天”是按8小时有效工作时间算的，不是随便点两下就完事。给你一份我实测过的时间参考：
| 时间段 | 任务 | 预估耗时 |
|---|---|---|
| 上午 8:30-10:00 | 硬件检查、宿主机操作系统安装、基础网络配置 | 1.5小时 |
| 上午 10:00-10:30 | 下载DevStack代码、准备local.conf配置文件 | 0.5小时 |
| 上午 10:30-11:30 | 执行stack.sh安装脚本 | 40-60分钟 |
| 上午 11:30-12:00 | 查看安装日志、确认服务状态、登录Dashboard | 0.5小时 |
| 下午 14:00-15:00 | 上传镜像、创建网络和路由、配置安全组 | 1小时 |
| 下午 15:00-16:00 | 创建云主机、绑定浮动IP、SSH登录验证 | 1小时 |
| 下午 16:00-17:00 | 排错、清理、记录踩坑点 | 1小时 |
如果上午安装顺利，下午的时间会非常充裕；如果中间卡在环境问题上，下午排错时间至少要预留两小时。所以我把最费时间的安装放在了上午，前端出了问题，后面还有回旋余地，这是最稳妥的节奏。
2. 搭建前的硬件检查与环境准备
2.1 宿主机配置要求：16G内存是舒适线
DevStack虽然只有一个脚本，但它拉起来的服务非常多：Keystone认证、Nova计算、Neutron网络、Glance镜像、Horizon面板，再加上底层数据库、消息队列，十几个进程同时跑，对内存的消耗远超你的想象。
我的实测经验：8G内存勉强能跑，但创建云主机时大概率会因为内存不足出现各种莫名其妙的故障，比如nova-compute服务直接死掉，或者VM创建后一直卡在BUILD状态。如果条件允许，请直接上16G内存，这会让你省掉至少一个小时的排错时间。
CPU方面，4核是底线，8核更稳。磁盘建议预留至少50GB空间，镜像、云主机磁盘、系统日志都会占用空间。推荐用SSD，虽然机械硬盘也能跑，但创建云主机时的写入速度差距非常明显。
系统版本我建议用Ubuntu Server 22.04 LTS。之所以不用更新的24.04，是因为DevStack对各组件版本有依赖矩阵，22.04是被验证过最稳定的宿主机系统之一；当然你在Ubuntu 24.04上装最新版DevStack通常也能成功，但一旦遇到兼容性报错，网上能搜到的解决方案会比较少。
2.2 在虚拟机里跑OpenStack：先解决嵌套虚拟化
很多人会想，我没独立服务器，能不能在VMware或VirtualBox虚拟机里再搭一个云平台？可以，但有一个前置条件：必须开启嵌套虚拟化。
如果你用的是VMware Workstation，先在虚拟机设置里找到“处理器”选项卡，勾选“虚拟化Intel VT-x/EPT或AMD-V/RVI”，这个选项意味着允许在虚拟机内部继续使用CPU硬件虚拟化指令。VirtualBox里也有类似选项，在“系统-加速”里勾选“启用嵌套VT-x/AMD-V”。
怎么确认到底有没有生效？进入Ubuntu系统后执行：
egrep -c '(vmx|svm)' /proc/cpuinfo如果返回的数字大于0，说明CPU硬件虚拟化已经对系统可见。也可以装一个更直观的工具：
sudo apt install cpu-checker -y sudo kvm-ok输出KVM acceleration can be used，才是真正的“能用了”。这一步没确认好，后面云主机创建时大概率会报LibvirtError: internal error: process exited while connecting to monitor，到时候你连问题出在哪都不知道，所以我建议你在安装系统之后第一时间就检查这个。
2.3 操作系统安装与基础配置
宿主机系统装好后，第一件事是换软件源。国内网络环境下载OpenStack组件包时，默认源会很慢，建议换成阿里云或清华镜像源。这里以Ubuntu 22.04为例，使用清华源：
sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo apt update然后安装基础工具：
sudo apt install git net-tools openssh-server vim -y配置hostname和网络。DevStack的安装过程会绑定IP，这个IP建议设置成静态IP，不要在虚拟机里用DHCP自动获取。假设你的宿主机IP是192.168.1.100，那后面local.conf里的HOST_IP就填这个地址。
还有一点容易忽略：关掉系统自带的防火墙。DevStack在安装过程中要动态修改iptables规则，如果ufw处于开启状态，很多网络操作会被拦掉，表现为创建了浮动IP但外部就是ping不通：
sudo ufw disable最后创建一个专门的stack用户，因为DevStack不允许用root用户直接安装：
sudo useradd -s /bin/bash -d /opt/stack -m stack sudo chmod +x /opt/stack echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack sudo su - stack到这一步，环境的准备工作就齐了。
3. 用DevStack跑通云平台：核心安装步骤
3.1 下载DevStack并创建stack用户
切换到stack用户后，先拉取DevStack代码。OpenStack的代码托管在opendev.org上，直接git clone即可：
sudo su - stack git clone https://opendev.org/openstack/devstack如果git clone速度很慢，可以尝试把opendev.org替换成镜像地址github.com/openstack/devstack（GitHub上有官方镜像仓库）。下载完成后进入目录：
cd devstackDevStack目录里有个samples文件夹，里面放着官方推荐的local.conf示例。我们需要创建一个自己的配置文件，这是整个搭建过程中最关键的一步，单独拿出来说。
3.2 编写local.conf：最关键的文件
DevStack的行为几乎完全由local.conf控制。这个文件定义了管理员密码、服务密码、宿主机IP、默认网络类型等。直接创建并编辑：
vim local.conf一个最简但可用的配置如下：
[[local|localrc]] # 管理员密码，登录Dashboard时用 ADMIN_PASSWORD=admin # 数据库密码，各服务共享 DATABASE_PASSWORD=admin # 消息队列密码 RABBIT_PASSWORD=admin # 服务组件间调用的密码 SERVICE_PASSWORD=admin # 宿主机IP，必须改成你自己的静态IP HOST_IP=192.168.1.100 # 默认平面网络所在物理网卡，通常填宿主机上网卡名 FLAT_INTERFACE=eth0 # 日志级别，方便排错 LOGFILE=/opt/stack/logs/stack.sh.log这几个密码在测试环境里全设成一样没有关系，生产环境当然不能这么干，但你要清楚它们分别对应什么服务：ADMIN_PASSWORD是登录Horizon和OpenStack CLI的管理员密码；DATABASE_PASSWORD对应MySQL；RABBIT_PASSWORD对应RabbitMQ；SERVICE_PASSWORD是各组件之间互相认证时用的。
FLAT_INTERFACE的意思是：DevStack会创建一个外部网络（public），这个网络的流量要桥接到你的物理网卡上。如果你的网卡名不是eth0，可以通过ip a命令先确认一下。
这个文件还有一个隐藏价值：你可以通过往里面追加服务配置来控制安装哪些组件。比如默认不装Heat编排服务，但你以后想学模板化创建虚拟机，可以加上enable_service h-eng h-api h-api-cfn h-api-cw。不过第一次搭建建议保持最简，别加东西。
3.3 执行安装脚本与日志观察
配置文件准备好后，直接运行：
./stack.sh然后就是漫长的等待。根据网络和机器性能，整个过程大约持续40到60分钟。脚本输出会实时显示当前安装到哪个服务，期间如果出现红色ERROR，不要慌，先看日志：
tail -n 100 /opt/stack/logs/stack.sh.logDevStack的安装日志几乎会记录所有关键步骤，大多数问题都能从这里找到根因。常见的失败原因包括：内存不够导致进程起不来、某个apt包下载超时、HOST_IP和实际网卡不匹配等。
安装成功的标志是脚本最后输出类似这样的内容：
This is your host IP address: 192.168.1.100 This is your cloud credentials: Horizon: http://192.168.1.100/dashboard Keystone: http://192.168.1.100/identity/同时提示你环境变量文件已经生成。接下来我们激活管理员身份并验证服务状态。
3.4 安装完成后的服务状态核对
安装完成后，当前目录下会有一个openrc或openrc.admin文件，里面记录了访问OpenStack API的环境变量。执行：
source openrc admin admin然后列出所有计算服务节点状态：
openstack compute service list正常情况下，你应该看到nova-compute、nova-scheduler、nova-conductor等服务的State都是up，Status都是enabled。如果某个服务显示down，说明对应进程死了，后面排查再看。
接着看网络服务：
openstack network agent list重点看dhcp agent和l3 agent是不是alive状态。这两个agent负责给虚拟机分配IP和做路由转发，后面创建云主机能不能拿到地址、能不能外网通信，全靠它们。
最后打开浏览器，访问http://192.168.1.100/dashboard，用admin/admin登录。看到Horizon面板的瞬间，你的云平台就已经跑起来了。
4. 在云平台上安装第一台虚拟机：从镜像到SSH登录
4.1 准备系统镜像
云平台本身不带操作系统，需要先上传一个镜像到Glance服务。测试阶段我强烈推荐用Cirros（一个专门为云平台测试设计的微型Linux系统），它只有几十MB，启动速度极快，而且内置了cloud-init支持，非常适合验证链路。
下载并上传镜像：
cd ~ wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img source ~/devstack/openrc admin admin openstack image create "cirros" \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public上传后确认一下镜像状态：
openstack image list看到状态是active就说明Glance正常工作了。如果你想在云主机里跑Ubuntu，也可以后面去下载ubuntu cloud image，但第一次实验先别用，大镜像上传和启动都慢，出了问题还不好定位是镜像的问题还是平台的问题。
4.2 创建规格、网络与安全组
镜像类似安装光盘，规格类似虚拟机硬件配置。用命令行创建一个最小规格：
openstack flavor create m1.tiny \ --id 1 \ --ram 512 \ --disk 1 \ --vcpus 1这里512MB内存、1G磁盘、1核CPU，足够让Cirros跑起来。
然后是网络。DevStack默认会创建好一个外部网络public，但内部网络通常需要自己建。所谓内部网络，就是你的云主机所在的私有网段，虚拟机之间通信、以及通过浮动IP对外通信，都依赖这个网络。
依次执行：
# 创建内部网络 openstack network create demo-net # 创建子网 openstack subnet create demo-subnet \ --network demo-net \ --subnet-range 192.168.100.0/24 \ --dns-nameserver 8.8.8.8 # 创建路由器 openstack router create demo-router # 设置路由器网关为外部网络 openstack router set demo-router --external-gateway public # 把内部子网接入路由器 openstack router add subnet demo-router demo-subnet这段操作的逻辑是：云主机加入demo-net这个私有网络，路由器demo-router把私有网络和外部网络连通，这样才能在外面访问到云主机。
安全组是很多人忽略但影响很大的环节。安全组相当于云主机的防火墙，默认规则会拒绝所有入站流量。先查看默认安全组：
openstack security group list找到default安全组的ID，然后添加允许ICMP和SSH的规则：
openstack security group rule create --proto icmp --ingress default openstack security group rule create --proto tcp --dst-port 22 default不放开这两条规则，云主机创建后既ping不通，也SSH不进去。
4.3 创建实例并绑定浮动IP
网络和安全组准备好后，创建密钥对：
ssh-keygen -q -N "" -f ~/.ssh/id_rsa openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey最后创建云主机：
openstack server create \ --flavor m1.tiny \ --image cirros \ --network demo-net \ --key-name mykey \ test-vm几秒钟后查看状态：
openstack server list看到状态从BUILD变成ACTIVE，说明云主机已经创建成功。但这还不够，你还需要给它一个可以从外部访问的IP，也就是浮动IP：
openstack floating ip create public openstack server add floating ip test-vm 192.168.200.X上面192.168.200.X替换成实际分配的IP地址。
4.4 命令行验证虚拟机可登录
到这一步，理论上你可以从宿主机SSH登录到云主机了：
ssh cirros@192.168.200.XCirros默认密码是gocubsgo，密钥方式也可以登录。第一次登录看到系统提示符，说明你从镜像上传到网络配置再到安全组放行，整条IaaS链路已经完全打通。
如果不想敲命令行，Horizon面板里也可以完成全部操作：Compute -> Instances -> Launch Instance，表单里选择镜像、规格、网络、密钥对，创建后在实例右侧下拉菜单里选择“绑定浮动IP”。对于追求效率的人，命令行确实比网页操作直观得多。
5. 搭建过程中最常踩的坑和排查思路
5.1 内存不足导致的服务崩溃
如果你用8G内存的机器搭建，最容易遇到的现象是：安装过程看着一切正常，但创建云主机一直卡在BUILD状态，或者nova-compute服务莫名其妙挂掉。
排查顺序通常是：
# 看nova服务状态 openstack compute service list # 看nova-compute进程状态 systemctl status devstack@nova-compute如果nova-compute反复重启，多半是内存不够。确认方法很简单：
free -h当可用内存只剩几百兆时，所有服务都在争抢内存，云主机的QEMU进程根本起不来。这时候最省心的方案是给宿主机加内存，但临时测试的话，可以先把不必要的服务停掉，比如Horizon对内存的消耗就不小：
sudo systemctl stop apache2这算应急，长期还是建议16G内存起跑。
5.2 虚拟机起不来：嵌套虚拟化没开全
在VMware虚拟机里搭OpenStack，最经典的问题就是云主机创建后状态直接变成ERROR。打开/var/log/nova/nova-compute.log，通常能看到KVM not available或者LibvirtError: internal error。
这种情况极大概率是嵌套虚拟化没开。回到宿主机上重新检查：
kvm-ok如果显示不支持KVM，你需要在VMware的虚拟机设置里勾选“虚拟化Intel VT-x/EPT或AMD-V/RVI”。注意，如果宿主机的CPU本身较老，或者VMware版本过低，这个选项可能根本不显示。另外，Nested Virtualization在VMware里默认可能是关闭的，需要开机进BIOS确认Intel VT-x已开启，一环接一环，少一个都起不来。
5.3 虚拟机拿不到IP与外部网络不通
云主机能起来、但拿不到IP，这是Neutron网络最经典的问题。先看DHCP agent状态：
openstack network agent list如果dhcp agent不是alive，重启一下：
sudo systemctl restart devstack@q-dhcp如果agent正常，但云主机还是拿不到IP，检查路由器是否正确连接内外网：
openstack router show demo-router重点看external_gateway_info字段有没有值，interfaces_info里有没有包含内部子网。还有安全组规则，有些朋友只放了ICMP和SSH，但如果云主机用DHCP获取IP，还需要放行UDP 67和68端口的入站流量。
另一个常见坑是：浮动IP分配出去了，但SSH连接超时。这通常是因为FLAT_INTERFACE配置了错误的物理网卡，导致外部流量无法正确路由。验证方法是查看网络命名空间：
sudo ip netns list sudo ip netns exec qrouter-XXXX ping 192.168.100.1如果路由器命名空间能ping通云主机的私网IP，说明内部网络没问题，问题出在外网桥接上。
5.4 安装中途失败后如何清理重来
DevStack最大的好处是可重入性高，但它也有闹脾气的时候。如果stack.sh执行到一半失败，且修改过配置文件，正确的清理姿势是：
cd ~/devstack ./unstack.sh ./clean.shunstack.sh停掉所有服务，clean.sh清理安装过程中生成的数据目录。清理完再改local.conf重新执行./stack.sh。如果连clean.sh都跑不完，那就粗暴一点，直接删除/opt/stack目录重新开始，但前提是你要接受之前的配置全部丢失。
我自己遇到过一次非常诡异的问题：重装后数据库密码始终不匹配，后来发现是之前的MySQL数据目录没清理干净。遇到这种“配置明明一样但就是起不来”的情况，果断重装系统反而是最快的。
6. 一天之后：这套环境还能怎么用
6.1 用Heat模板批量创建虚拟机
如果你已经能手动创建云主机，下一个值得玩的是Heat编排服务。DevStack默认不装Heat，但在local.conf里加一行再重装：
enable_service h-eng h-api h-api-cfn h-api-cw重启stack.sh后，你可以用一份YAML模板批量创建多台云主机：
heat_template_version: 2016-10-14 resources: test_instance: type: OS::Nova::Server properties: image: cirros flavor: m1.tiny key_name: mykey networks: - network: demo-net执行openstack stack create -t template.yaml my-stack，平台会自动帮你完成网络、磁盘、实例的创建流程。这个能力在写测试环境、做自动化实验时非常实用。
6.2 保存快照与扩展资源
你创建好的云主机，可以做成快照：
openstack server image create --name cirros-with-tools test-vm以后想再开一台一模一样的系统，直接从快照镜像创建即可。这一点对测试非常有用，相当于给你提供了一个可以随时回滚的“存档点”。
资源扩展方面，local.conf里可以直接控制neutron的子网网段和浮动IP池范围。修改后重新跑一次stack.sh，就能获得更丰富的地段。还可以创建不同flavor规格，给不同项目配置不同配额，体会一下多租户环境下的资源隔离是怎么运作的。
6.3 升级成高可用集群的路径
单机DevStack跑熟了之后，你会发现它的很多设计都是牺牲高可用换便捷性：数据库没有主从，消息队列没有集群，控制节点挂了就全挂。真要往生产方向走，可以沿着这几条路径升级：
一是改用Kolla-Ansible，把OpenStack全部容器化，通过Docker容器实现多节点部署，升级和维护体验比DevStack好很多；二是引入Ceph作为后端存储，把云主机的磁盘落到分布式存储上，才能实现热迁移；三是部署负载均衡和集群代理，把API、数据库、消息队列都做成多副本。
但这些都是“之后”的事。第一天的目标，就是沿着DevStack这条路把IaaS的每个环节亲手摸一遍。我自己的体会是，单机DevStack的价值不在于它能扛多少并发，而在于它把“云平台”这个抽象概念变成了一个你能随手操作的真实系统。你把镜像、规格、网络、安全组、浮动IP逐一手动配一遍后，再去读任何云计算文档或面试题，都会觉得轻省得多。那个拿着网页面板点来点去的下午，对建立整体认知的帮助，确实比看一个月架构图管用。
