简介本资源是一份面向OpenStack初学者与运维工程师的实用命令速查手册聚焦网络计算场景下的核心服务操作帮助用户快速掌握平台日常管理与故障排查所需的关键CLI指令。文档以Word格式.docx单文件呈现体积精简仅20KB内容结构清晰覆盖主机基础命令、Keystone认证、Glance镜像、Nova计算、Neutron网络、Cinder块存储及虚拟机全生命周期管理七大模块每类均按查询/编辑/删除更新分项列出典型命令及语法示例含Apache服务状态检查、域与项目创建、镜像上传、虚拟机启停等高频操作。目录层级完整含详细注解与实操样例便于随用随查、即学即用。目前已有411人学习下载适合作为OpenStack部署调试阶段的桌面参考工具或培训辅助材料。1. 这不是“命令速查表”而是一份能让你在 OpenStack 生产环境里少敲错三次openstack、少重启两次neutron-server、少翻一次日志的实战手册你刚接手一个跑着 NovaNeutronCinder 的 OpenStack 环境控制节点上openstack endpoint list返回一堆regionOne和http://10.0.0.10:xxx但openstack server list却报HTTP 401 Unauthorized你照着文档改完/etc/nova/nova.confsystemctl restart openstack-nova-api后服务状态是active (exited)——它根本没起来你上传了 cirros 镜像openstack image show cirros显示status: queued等十分钟还是queued没人告诉你glance-api和glance-registry必须同时 running且registry默认监听127.0.0.1:9191而api默认连http://localhost:9191一旦你把registry绑定到0.0.0.0api就连不上了。这不是玄学是 OpenStack 命令链路上每个环节都卡着权限、端口、服务依赖、配置同步四道关。这份.docx手册表面是“命令罗列”实则是把openstackCLI、systemctl、vim三类命令拧成一条可验证、可回溯、可定位失败点的操作流——它不教你“什么是域”而是告诉你openstack domain create成功后必须立刻openstack endpoint list --service image看 public/internal/admin 三个 endpoint 是否全存在它不讲“ML2 是什么”而是明确写出ml2_conf.ini里type_drivers flat,vlan,vxlan和tenant_network_types vxlan必须匹配否则neutron net-create会静默失败。适合正在搭建基于 PackStack 或手动部署的 OpenStack 云平台的运维工程师、私有云交付工程师以及被nova-status upgrade check报出十几条FAIL吓得不敢动生产环境的中级实施人员。2. 主机与认证服务从系统层打通 OpenStack 的身份信任链OpenStack 不是独立运行的黑匣子它的所有服务keystone,glance,nova都依赖底层 Linux 主机的网络可达性、服务进程存活性、以及最关键的—— Keystone 认证服务的可用性。很多初学者卡在openstack project list报错Connection refused第一反应是 Keystone 挂了其实八成是httpd没启、防火墙拦了 5000/35357 端口、或/etc/hosts里controller解析错了 IP。本章带你用最短路径建立“主机 → Apache → Keystone”的信任链让openstackCLI 能真正说话。2.1 主机网络与主机名CLI 命令能执行的前提是 DNS 和路由通OpenStack CLI 工具openstack,nova,neutron默认通过环境变量OS_AUTH_URL如http://controller:5000/v3连接 Keystone。这个 URL 能否解析、能否连通完全取决于主机层面的网络配置。提示不要直接ping controller要nslookup controller或dig controller因为ping可能走/etc/hosts缓存而openstackCLI 用的是 glibc 的 resolver行为更严格。# 查看主机名是否与 /etc/hosts 中定义一致这是 OpenStack 服务间通信的基础 cat /etc/hostname # 输出应为 controller 或 compute01 等不能是 localhost.localdomain # 查看 /etc/hosts 是否正确定义了所有节点的 IP 和主机名映射 cat /etc/hosts # 正确示例 # 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 # 10.0.0.11 controller # 10.0.0.31 compute01 # 10.0.0.32 compute02逻辑说明openstackCLI 在发起 HTTP 请求前会调用getaddrinfo()查询controller的 IP。如果/etc/hosts里没有controller条目它会走 DNS若 DNS 不可用或返回错误 IP请求直接失败。cat /etc/hostname输出必须与/etc/hosts中该行的主机名完全一致区分大小写否则httpd的虚拟主机配置可能不生效。参数说明/etc/hosts文件中每行格式为IP地址 主机名 [别名...]。OpenStack 官方文档强烈建议使用静态 hosts 映射而非 DNS因为 DNS 故障会导致整个云平台不可用。2.2 Apache httpd 服务Keystone 的 HTTP 入口挂了就等于整个认证体系瘫痪Keystone v3 服务由httpdApache托管其配置文件/etc/httpd/conf.d/wsgi-keystone.conf定义了 WSGI 应用路径。systemctl status httpd.service不仅检查 Apache 进程更关键的是确认httpd能成功加载 Keystone 的 WSGI 模块。# 检查 httpd 服务状态注意active (running) 是必要条件但非充分条件 systemctl status httpd.service # 若显示 active (exited)说明 Apache 启动失败需立即查日志 # 查看最近 50 行错误日志核心排查点 tail -50 /var/log/httpd/error_log # 关键错误示例 # [wsgi:error] ModuleNotFoundError: No module named keystone # [core:error] AH00526: Syntax error on line 12 of /etc/httpd/conf.d/wsgi-keystone.conf: Invalid command WSGIScriptAlias, perhaps misspelled or defined by a module not included in the server configuration逻辑说明httpd启动失败最常见的原因是 Python 环境问题如python3-keystone未安装、WSGI 模块未启用LoadModule wsgi_module modules/mod_wsgi.so缺失、或wsgi-keystone.conf中路径错误如WSGIScriptAlias / /usr/bin/keystone-wsgi-public应指向实际可执行文件。tail -50 /var/log/httpd/error_log是比systemctl status更精准的诊断入口。参数说明/var/log/httpd/error_log是 Apache 的错误日志主文件记录模块加载、语法错误、权限拒绝等致命问题。/var/log/httpd/keystone_access.log记录 HTTP 请求用于分析认证流量但不解决启动问题。2.3 Keystone 域与项目openstack domain list成功 ≠ Keystone 可用必须验证 endpointopenstack domain list返回结果只代表 Keystone API 接口响应了不代表后端数据库连接正常、不代表httpd下的 WSGI 应用能访问数据库、更不代表openstackCLI 使用的认证 token 有效。真正的验证是openstack endpoint list—— 它要求 Keystone 不仅要响应还要能查询自身服务目录Service Catalog。# 第一步确保环境变量已正确设置这是所有 openstack 命令的前提 source /root/admin-openrc.sh # 该文件应包含export OS_AUTH_URLhttp://controller:5000/v3 # export OS_PROJECT_NAMEadmin # export OS_USER_DOMAIN_NAMEDefault # export OS_PROJECT_DOMAIN_NAMEDefault # export OS_USERNAMEadmin # export OS_PASSWORDADMIN_PASS # export OS_IDENTITY_API_VERSION3 # export OS_IMAGE_API_VERSION2 # 第二步查询域列表基础可用性 openstack domain list # 正常输出应含 default 域EnabledTrue # 第三步查询 endpoint 列表关键验证 openstack endpoint list --service identity # 正确输出应有 3 行Interface 分别为 public, internal, adminURL 均指向 controller:5000/v3 # 若只返回 0 行或报错 No endpoints found说明 Keystone 的 service catalog 为空或损坏逻辑说明openstack endpoint list --service identity强制 Keystone 查询service表和endpoint表的关联。如果keystone-manage bootstrap未执行或keystone-manage db_sync失败endpoint表就是空的此时openstack domain list仍能工作因为它只查domain表但所有其他服务glance,nova都无法注册 endpoint整个云平台无法初始化。参数说明--service identity过滤只显示 Keystone 服务的 endpoint。publicendpoint 供外部用户访问internal供 OpenStack 内部服务间调用如nova调keystoneadmin供管理员操作。三者 URL 必须全部存在且可连通用curl -I http://controller:5000/v3验证。2.4 创建域、项目、用户openstack命令背后是数据库事务失败时必须查keystone-manage日志openstack domain create看似一条命令实则触发 Keystone 的完整 CRUD 流程校验参数 → 生成 UUID → 插入domain表 → 触发通知 → 更新缓存。任何一环失败命令就静默退出或报模糊错误。# 创建新域带描述符合生产环境规范 openstack domain create --description Production Environment Domain prod # 创建项目绑定到 prod 域 openstack project create --domain prod --description Core Compute Project compute-prod # 创建用户交互式输密码避免明文出现在 bash history openstack user create --domain prod --password-prompt compute-user # 提示输入密码两次安全且不留痕 # 将用户加入项目并赋予 admin 角色这是授权的关键一步 openstack role add --project compute-prod --user compute-user admin逻辑说明--password-prompt是最佳实践避免密码明文出现在命令行历史history和进程列表ps aux。openstack role add命令本质是向assignment表插入一条记录将user_id,project_id,role_id关联起来。如果openstack role list能看到admin角色但openstack role add报错Role not found说明--role admin中的admin是角色名而数据库里存储的是角色 ID需先openstack role show admin获取 ID 再用--role id。参数说明--domain prod指定域--project compute-prod指定项目--user compute-user指定用户。三者必须已存在否则命令失败。openstackCLI 本身不校验依赖关系失败时只报NotFound需人工确认上游资源是否存在。2.5 避坑认证服务常见问题排查现象→原因→解决现象openstack domain list返回HTTP 401 Unauthorized原因环境变量OS_AUTH_URL,OS_USERNAME,OS_PASSWORD未正确设置或admin-openrc.sh中OS_AUTH_URL指向http://localhost:5000/v3localhost 在 compute 节点解析为 127.0.0.1但 Keystone 只监听 controller IP解决在所有节点执行source /root/admin-openrc.sh确认OS_AUTH_URLhttp://controller:5000/v3且controller在/etc/hosts中解析为控制节点真实 IP。现象openstack endpoint list返回空但openstack domain list正常原因Keystone 数据库未初始化keystone-manage db_sync未执行或keystone-manage bootstrap未运行导致 service catalog 为空解决登录 controller 节点执行su -s /bin/sh -c keystone-manage db_sync keystone再执行keystone-manage bootstrap --bootstrap-password ADMIN_PASS。现象openstack user create成功但openstack user list --projectcompute-prod查不到该用户原因用户创建后未通过openstack role add将其分配到项目user list --project只显示有角色绑定的用户解决执行openstack role add --project compute-prod --user compute-user membermember 是标准角色再查。现象systemctl status httpd.service显示active (running)但curl http://controller:5000/v3返回Connection refused原因httpd进程运行但wsgi-keystone.conf中Listen 5000被注释或防火墙firewalld拦截了 5000 端口解决检查/etc/httpd/conf.d/wsgi-keystone.conf确认Listen 5000未注释执行firewall-cmd --list-ports | grep 5000若无输出则firewall-cmd --add-port5000/tcp --permanent firewall-cmd --reload。现象openstack project create报错Conflict: Duplicate entry原因项目名已存在OpenStack 项目名在 domain 内唯一但openstack project list未显示因--domain参数未指定列表默认查default域解决用openstack project list --domain prod查指定域下的项目或改用唯一项目名。3. 镜像与计算服务从glance image-create到nova boot的完整链路验证镜像服务Glance和计算服务Nova是 OpenStack 最核心的两个服务它们的协作流程是用户上传镜像 → Glance 存储镜像元数据和文件 → Nova 通过 Glance API 获取镜像信息 → Nova Scheduler 选择宿主机 → Nova Compute 创建虚拟机实例。这条链路上任何一个环节断开openstack server create就会卡在BUILD状态或直接失败。本章聚焦于如何用命令验证 Glance-Nova 链路是否真正打通而不是只看服务进程是否 running。3.1 Glance 服务状态systemctl status只是起点openstack image list才是终点Glance 由两个核心服务组成openstack-glance-api处理 REST 请求和openstack-glance-registry管理元数据新版已弃用但 PackStack 部署仍保留。systemctl status只能证明进程存在openstack image list才能证明 API 可用、数据库可读、存储后端可访问。# 检查两个 Glance 服务状态必须都是 active (running) systemctl status openstack-glance-api.service openstack-glance-registry.service # 查看 Glance 服务日志快速定位问题 journalctl -u openstack-glance-api.service -n 50 --no-pager journalctl -u openstack-glance-registry.service -n 50 --no-pager # 查询镜像列表这是 Glance 可用的黄金标准 openstack image list # 正常输出应有至少一个镜像Statusactive # 若报错 Connection to glance failed说明 openstack-cli 无法连 Glance API # 若返回空列表但无错说明 Glance API 正常但数据库无镜像逻辑说明openstack image list命令会向OS_IMAGE_API_VERSION2指定的 Glance APIhttp://controller:9292/v2发送 GET/v2/images请求。成功返回意味着1)openstack-glance-api进程在监听 9292 端口2)openstack-glance-api能连接数据库查images表3)openstack-glance-api能访问后端存储如 file、swift、rbd4)openstackCLI 的OS_AUTH_URL和 token 能被 Glance 验证。四个条件缺一不可。参数说明openstack image list默认只显示Name,ID,Status。加--long可显示Visibility,Protected,Owner等字段对调试权限问题至关重要。3.2 上传 Cirros 镜像openstack image create的四个必填参数与存储后端强相关Cirros 是 OpenStack 官方推荐的最小化测试镜像但上传时参数稍有差池镜像就会卡在queued状态永远变不成active。这是因为 Glance 的disk-format和container-format必须与镜像文件物理格式严格匹配且--public参数决定镜像可见范围。# 下载 Cirros 镜像确保文件完整 wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img # 校验 MD5官方提供避免下载损坏 echo b252e1a0f1b5b1e1a0f1b5b1e1a0f1b5 cirros-0.6.2-x86_64-disk.img | md5sum -c # 上传镜像关键参数详解 openstack image create \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public \ cirros-0.6.2逻辑说明--disk-format qcow2告诉 Glance 镜像文件是 qcow2 格式Cirros 官方镜像就是 qcow2--container-format bare表示镜像不包含容器封装如 OVA、AKI是裸磁盘镜像--public使镜像对所有项目可见否则只有上传者所在项目能用。--file必须是本地路径Glance 不支持 URL 直传。参数说明qcow2是 QEMU 的常用格式支持快照和压缩raw是原始二进制格式性能最好但体积大vmdk是 VMware 格式。bare是最常用的 container-formatami用于 Amazon EC2 镜像ovf用于 OVF 包。选错会导致 Glance 无法解析镜像头状态卡queued。3.3 Nova 服务状态systemctl statusopenstack compute service list双重验证Nova 服务组件多api, scheduler, conductor, compute, novncproxysystemctl status只能看单个进程而openstack compute service list能反映整个 Nova 服务网格的健康状况特别是Stateup/down和Statusenabled/disabled字段。# 检查所有 Nova 相关服务进程必须全部 active systemctl status \ openstack-nova-api.service \ openstack-nova-scheduler.service \ openstack-nova-conductor.service \ openstack-nova-novncproxy.service \ openstack-nova-compute.service \ libvirtd.service # 查询 Nova 服务列表核心验证看所有组件是否注册且状态为 up openstack compute service list # 正常输出中Binary 列应有 nova-api, nova-scheduler, nova-conductor, nova-compute, nova-consoleauth, nova-novncproxy # Host 列应显示 controller, compute01 等节点名 # State 列应全为 up # Status 列应全为 enabled若为 disabled需 openstack compute service set --disable xxx逻辑说明openstack compute service list查询nova-api的os-servicesAPI返回services表数据。Stateup表示该服务进程向nova-conductor发送的心跳正常默认 60 秒Statusenabled表示该服务被允许接收任务。nova-compute在 compute 节点上nova-api在 controller 上两者必须都up且enabledopenstack server create才能调度成功。参数说明openstack compute service list不显示libvirtd状态但nova-compute严重依赖libvirtd。若nova-compute显示up但虚拟机创建失败必查systemctl status libvirtd和virsh list --all。3.4 Nova 组件升级检查nova-status upgrade check是生产环境上线前的“后悔药”nova-status upgrade check是 Nova 自带的健康检查工具它扫描数据库 schema、配置文件一致性、服务版本兼容性。在升级 OpenStack 版本或修改nova.conf后此命令能提前发现可能导致虚拟机无法创建的深层问题。# 运行升级检查在 controller 节点执行 nova-status upgrade check # 正常输出以 Checking upgrade readiness... 开头最后是 Upgrade check complete. # 若有 FAIL 条目必须修复后才能继续 # 示例常见 FAIL 及修复 # FAIL: CellV2 is not ready (cell0 not mapped) # 解决执行 nova-manage cell_v2 discover_hosts --verbose # FAIL: Database schema versions do not match # 解决执行 nova-manage db sync # FAIL: Configuration option transport_url not set in [DEFAULT] # 解决在 /etc/nova/nova.conf 的 [DEFAULT] 段添加 transport_url rabbit://openstack:RABBIT_PASScontroller逻辑说明nova-status upgrade check不是简单的配置校验它会连接数据库执行 SQL 查询如SELECT * FROM migrate_version检查消息队列连接性并验证nova.conf中关键选项如transport_url,my_ip,use_neutron是否设置。每个FAIL都对应一个真实故障点忽略它上线后虚拟机创建大概率失败。参数说明nova-status upgrade check无参数但依赖nova.conf中[database]和[DEFAULT]配置正确。执行前确保nova用户对数据库有读写权限。3.5 避坑镜像与计算服务常见问题排查现象→原因→解决现象openstack image list返回空但systemctl status openstack-glance-api显示 active原因Glance 配置文件/etc/glance/glance-api.conf中sql_connection指向错误数据库或default_store file但/var/lib/glance/images/目录不存在或权限不对解决检查glance-api.conf的[database]和[glance_store]段执行ls -ld /var/lib/glance/images/确认属主为glance:glance权限755。现象openstack image create后openstack image show cirros-0.6.2显示status: queued数分钟不变成active原因openstack-glance-registry.service未运行或glance-api.conf中registry_host 127.0.0.1但glance-registry绑定到0.0.0.0:9191导致 API 无法注册镜像解决systemctl start openstack-glance-registry检查glance-api.conf的[paste_deploy]段flavor keystone是否正确重启openstack-glance-api。现象openstack compute service list中nova-compute显示down但systemctl status openstack-nova-compute是active原因nova-compute进程运行但未向nova-conductor发送心跳通常因transport_url配置错误或 RabbitMQ 不可用解决检查/etc/nova/nova.conf的[DEFAULT] transport_url rabbit://...执行rabbitmqctl list_queues看nova相关队列是否存在。现象openstack server create后虚拟机状态长期BUILDnova list显示ERROR原因nova-compute无法访问 Glance 镜像常见于glance_api_servers配置为http://localhost:9292在 compute 节点 localhost 是自己不是 controller解决在/etc/nova/nova.conf的[glance]段设置glance_api_servers http://controller:9292重启openstack-nova-compute。现象nova-status upgrade check报FAIL: CellV2 is not ready原因Nova Cell V2 架构未初始化nova-manage cell_v2 list_cells返回空解决执行nova-manage cell_v2 map_cell0再nova-manage cell_v2 create_cell --namecell1 --transport-urlrabbit://openstack:RABBIT_PASScontroller --database-connectionmysqlpymysql://nova:NOVA_DBPASScontroller/nova_cell1最后nova-manage cell_v2 discover_hosts。4. 网络与块存储服务neutron net-create和cinder create的底层依赖验证网络服务Neutron和块存储服务Cinder是 OpenStack 中最易出问题的两个服务因为它们深度耦合 Linux 内核网络栈bridge, ovs, iptables和存储驱动LVM, NFS, Ceph。openstack network list成功不代表neutron-server能创建网络cinder service-list显示up也不代表cinder-volume能创建卷。本章教你绕过 CLI 表象直击 Neutron Agent 和 Cinder Volume 的真实工作状态。4.1 Neutron 服务状态systemctl statusopenstack network agent list双保险Neutron 架构复杂neutron-server是中心 API但真正干活的是各类 Agentlinuxbridge-agent处理 L2 网络、dhcp-agent提供 DHCP、metadata-agent传递 metadata。systemctl status只能看进程openstack network agent list才能看 Agent 是否注册、是否alive、是否admin_state_up。# 检查所有 Neutron 服务进程controller 节点 systemctl status \ neutron-server.service \ neutron-linuxbridge-agent.service \ neutron-dhcp-agent.service \ neutron-metadata-agent.service # 查询 Neutron Agent 列表关键验证看所有 Agent 是否在线 openstack network agent list # 正常输出中Agent Type 应有 Linux bridge agent, DHCP agent, Metadata agent # Host 列应显示 controller, compute01 等 # Alive 列应全为 :-)笑脸表示 alive # Admin State Up 列应全为 True # Binary 列应为 neutron-linuxbridge-agent 等逻辑说明openstack network agent list查询neutron-server的agentsAPI返回agents表数据。Alive:-)表示该 Agent 进程向neutron-server发送的心跳正常默认 60 秒Admin State UpTrue表示管理员未手动禁用该 Agent。neutron-linuxbridge-agent在 compute 节点上负责创建 br-int、br-eth0 等网桥并将虚拟机 tap 设备接入若它Alive为XXX虚拟机网络必然不通。参数说明openstack network agent list的Binary字段显示 Agent 类型Host字段显示运行节点。neutron-server本身不显示在此列表中它是中心服务。4.2 ML2 配置解析ml2_conf.ini中type_drivers与tenant_network_types的隐式依赖ML2Modular Layer 2是 Neutron 的核心插件ml2_conf.ini是其配置心脏。type_drivers定义支持的网络类型flat, vlan, vxlantenant_network_types定义租户网络默认类型。二者不匹配neutron net-create会静默失败或创建出无法使用的网络。# 查看 ml2 配置关键段 grep -E ^(type_drivers|tenant_network_types|mechanism_drivers) /etc/neutron/plugins/ml2/ml2_conf.ini # 正常输出示例 # type_drivers flat,vlan,vxlan # tenant_network_types vxlan # mechanism_drivers linuxbridge,l2population # 验证 linuxbridge_agent 配置必须与 ml2_conf.ini 一致 grep -E ^(physical_interface_mappings|enable_security_group) /etc/neutron/plugins/ml2/linuxbridge_agent.ini # 正常输出示例 # physical_interface_mappings provider:ens160 # enable_security_group True逻辑说明type_drivers flat,vlan,vxlan表示 ML2 支持这三种网络类型tenant_network_types vxlan表示租户网络默认用 vxlan。若tenant_network_types vlan但physical_interface_mappings中没有vlan:ens160neutron net-create --provider:network_type vlan就会失败。mechanism_drivers linuxbridge表示用 Linux Bridge 实现 L2必须与linuxbridge_agent.ini中的physical_interface_mappings对应。参数说明physical_interface_mappings provider:ens160将物理网卡ens160映射为 provider 网络外部网络provider是自定义名字可在neutron net-create时通过--provider:physical_network provider引用。4.3 Cinder 服务状态systemctl statuscinder service-listtargetcli三层验证Cinder 服务包括cinder-api,cinder-scheduler,cinder-volume。cinder-volume是核心它通过 LVM、NFS 或 Ceph 驱动创建卷。systemctl status看进程cinder service-list看注册状态targetcli看 iSCSI target 是否真正导出。# 检查 Cinder 服务进程controller 和 storage 节点 systemctl status \ openstack-cinder-api.service \ openstack-cinder-scheduler.service \ openstack-cinder-volume.service \ target.service # 查询 Cinder 服务列表看 volume 服务是否 up cinder service-list # 正常输出中Binary 列应有 cinder-volumeHost 列应为 storage-nodeState 应为 upStatus 应为 enabled # 验证 iSCSI targetLVM 后端必备 targetcli ls # 正常输出应显示 /backstores/block 和 /iscsi 下的 target如 # o- iscsi ..................................................................... [...] # o- targets ................................................................... [...] # o- iqn.2010-10.org.openstack:volume-xxxxxxxxxxxx ......................... [...]逻辑说明cinder-volume服务启动时会调用targetcli创建 iSCSI target 并导出 LVM 逻辑卷。target.service是targetcli的 systemd 服务必须 running。targetcli ls直接查看内核 target framework 状态比cinder service-list更底层。若cinder service-list显示up但targetcli ls无输出说明cinder-volume未成功创建 target常见于 LVM VG 不存在或cinder.conf中volume_group cinder-volumes错误。参数说明targetcli是 Linux 内核 target framework 的命令行工具ls命令列出所有 iSCSI target。iqn.2010-10.org.openstack:volume-xxx是 Cinder 自动生成的 target 名。4.4 创建 provider 网络neutron net-create的三个强制参数与物理网卡绑定Provider 网络是 OpenStack 外部网络如公司办公网它直接映射到物理网卡。创建时必须指定--provider:physical_network与linuxbridge_agent.ini中physical_interface_mappings的 key 一致、--provider:network_typeflat/vlan、--provider:segmentation_idvlan idflat 类型无需。# 创建 flat 类型 provider 网络最简单用于测试 neutron net-create \ --provider:physical_network provider \ --provider:network_type flat \ --shared \ provider-flat # 创建 vlan 类型 provider 网络生产常用 neutron net-create \ --provider: p a hrefhttps://download.csdn.net/download/Lincon/64870409 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
