Glance的glance_store段必须显式列出所有启用的store并设default_store，否则启动报错；多后端上传需指定--store参数，否则默认走default_store。
glance_store 配置段必须启用多个 store 并设 default_store
Glance 支持同时配置多个后端（如 file、s3、rbd、swift），但前提是 glance_store 段中明确列出所有可用 store，并用逗号分隔；default_store 必须设为其中一个，否则启动 glance-api 会报错 ValueError: No store configured for scheme 'xxx'。
常见错误是只在配置里加了 s3_store_* 参数却没把 s3 加进 stores 列表，导致上传镜像时返回 400 Bad Request: Unsupported store type: s3。
正确写法示例：
[glance_store] stores = file,s3,rbd default_store = rbd filesystem_store_datadir = /var/lib/glance/images/ # 其他 store 的参数按需展开...
s3 后端需显式启用并校验签名版本与 endpoint
使用 MinIO 或 AWS S3 作为后端时，glance-api 默认不加载 s3 store，必须确保：glance_store 段含 s3，且 s3_store_* 参数完整。关键参数包括：
-
s3_store_host：必须是可解析的域名或 IP + 端口（如minio.example.com:9000），不能带http:// -
s3_store_access_key和s3_store_secret_key：需与 MinIO 创建的用户权限匹配（建议readwrite策略） -
s3_store_region：即使 MinIO 是单 region，也必须设值（如us-east-1），否则初始化失败 -
s3_store_signature_version：MinIO v2022+ 强制要求v4；旧版 Glance（如 Ocata）可能默认用v2，需显式覆盖
漏配 s3_store_signature_version=v4 是最常导致 SignatureDoesNotMatch 错误的原因。
rbd（Ceph）后端要验证 keyring 权限与 pool 存在性
当用 Ceph RBD 作主存储时，glance-api 进程必须能读取 /etc/ceph/ceph.client.glance.keyring，且该 keyring 对应的用户至少有 rwx 权限到 images pool。容易踩的坑包括：
- keyring 文件属主不是
glance:glance，systemd 启动时被拒绝读取 - Ceph pool 名称拼写错误（如配了
image却实际建的是images），上传镜像时报PoolNotFound - 未执行
rbd pool init images（某些 Ceph 版本要求显式初始化 pool） -
rbd_store_chunk_size设得过大（如 8MB），在小内存节点上触发 OOM killer
验证方式：手动用 rbd -p images ls 和 ceph auth get client.glance 在 glance 节点运行，确认无权限或连接问题。
多后端上传时必须指定 --store 参数，否则走 default_store
OpenStack CLI 默认将镜像上传到 default_store，即使其他后端已配置好。要强制存到特定后端（比如把大 ISO 放 S3、QCOW2 放 Ceph），上传命令必须加 --store：
openstack image create \ --file ubuntu-22.04.qcow2 \ --disk-format qcow2 \ --container-format bare \ --store rbd \ ubuntu-22.04-rbd
遗漏 --store rbd 就会静默存到 file 或别的 default，后续扩容或迁移时才发现数据不在预期位置。更隐蔽的问题是：某些 Dashboard 或自动化脚本硬编码了 store 类型，却不检查配置一致性。
真正复杂的地方在于，不同 store 对镜像属性有隐含约束——比如 s3 不支持直接修改镜像状态为 active（需等 multipart upload 完成），而 rbd 支持秒级激活；这些行为差异不会报错，但会影响实例启动链路的稳定性。
