不太完整，后续待补充
1. Nova关键参数调优：
#建议值是预留前几个物理 CPU，把后面的所有 CPU 分配给虚拟机使用
vcpu_pin_set
#cat /proc/cpuinfo里面的逻辑核数，再x16就是你能够分配给虚拟机的。内存也是类似
cat /proc/cpuinfo | grep "cpu cores" | uniq
#物理 CPU 超售比例，默认是 16 倍，超线程也算作一个物理 CPU，需要根据具体负载和物理 CPU 能力进行综合判断后确定具体的配置
cpu_allocation_ratio = 4.0
#内存分配超售比例，默认是 1.5 倍，生产环境不建议开启超售。
ram_allocation_ratio = 1.0
#内存预留量，这部分内存不能被虚拟机使用
reserved_host_memory_mb = 4096
#磁盘预留空间，这部分空间不能被虚拟机使用
reserved_host_disk_mb = 10240
#服务下线时间阈值，默认60，如果一个节点上的 nova 服务超过这个时间没有上报心跳到数据库，api 服务会认为该服务已经下线，如果配置过短或过长，都会导致误判。
service_down_time = 120
#调用超时时间，由于 Python 的单进程不能真正的并发，所以 RPC 请求可能不能及时响应，尤其是目标节点在执行耗时较长的定时任务时，所以需要综合考虑超时时间和等待容忍时间。
rpc_response_timeout = 300 RPC
2. keystone关键参数调优：
主要是用来来存储 token，一般是 SQL 数据库，也可以是 memcache。sql 可以持久化存储，而 memcache 则速度更快，尤其是当用户要更新密码的时候，需要删除所有过期的 token，这种情况下 SQL 的速度与 memcache 相差很大很大。
3. glance关键参数调优：
glance-api.conf
#与nova配置中的osapi_max_limit意义相同;最大返回数据长度限制，如果设置过短,会导致部分响应数据被截断。
api_limit_max = 1000
#一个响应中最大返回项数，可以在请求参数中指定，默认是 25，如果设置过短，可能导致响应数据被截断。
limit_param_default = 1000
4. openstack底层依赖软件版本、配置以及调优
1.虚拟化技术选型
我们选用的是 Linux 内核兼容最好的 KVM 虚拟化技术。相对于 Xen 虚拟化技术，KVM 虚拟化技术与 Linux 内核联系更为紧密，更容易维护。选择 KVM 虚拟化技术后，虚拟化管理驱动采用了 OpenStack 社区为 KVM 配置的计算驱动 libvirt，这也是一套使用非常广泛，社区活跃度很高的一套开源虚拟化管理软件，支持 KVM 在内的各种虚拟化管理。
2.CPU配置优化
CPU0 由于处理中断请求，本身负荷就较重，不宜再用于云主机。因此，综合上面的因素考虑以及多轮的测试验证，最终是要将 0-3 号 CPU 预留出来，然后让云主机在剩余的 CPU 资源中由宿主机内核去调度。
3.内存配置优化
echo 0 > /sys/kernel/mm/ksm/pages_shared
echo 0 > /sys/kernel/mm/ksm/pages_sharing
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
4.IO配置优化
磁盘IO调优KVM 的 disk cache 方式：借鉴 IBM 的分析，采用 none 这种 cache 方式
5.网络IO调优
我们主要是开启了 vhost_net 模式，来减少网络延时和增加吞吐量
5. 使用卷创建实例报错的故障
did not finish being created even after we waited 241 seconds or 61 attempts. A its status is downloading.
即使等待了241秒或61次尝试，仍无法完成创建。 其状态为下载中。
OpenStack创建实例提示失败的具体原因如下：
解决办法
在计算节点上的nova.conf中有一个控制卷设备重试的参数：block_device_allocate_retries，可以通过修改此参数延长等待时间。
该参数默认值为60，这个对应了之前实例创建失败消息里的61 attempts。我们可以将此参数设置的大一点,例如：180。这样Nova组件就不会等待卷创建超时，也即解决了此问题。
然后重启计算节点服务
openstack-config --set /etc/nova/nova.conf DEFAULT block_device_allocate_retries 180
systemctl restart libvirtd.service openstack-nova-compute.service
6. 虚拟机初始放置策略
Packing： 虚拟机尽量放置在含有虚拟机数量最多的主机上
Stripping: 虚拟机尽量放置在含有虚拟机数量最少的主机上
CPU load balance：虚拟机尽量放在可用core最多的主机上
Memory load balance：虚拟机尽量放在可用memory 最多的主机上
Affinity : 多个虚拟机需要放置在相同的主机上
AntiAffinity: 多个虚拟机需要放在在不同的主机上
CPU Utilization load balance：虚拟机尽量放在CPU利用率最低的主机上
6. 监控和优化策略
https://www.sohu.com/a/101312934_116235
7. openstack虚拟机发放速度优化
https://blog.csdn.net/halcyonbaby/article/details/59800925
8. 虚拟机删除后停在deleting无法正常删除的方法
https://www.cnblogs.com/nakky/p/7427560.html
9. cinder卷和ceph块设备无法删除
OpenStack常见的22个问题汇总
https://blog.csdn.net/caiyqn/article/details/107642771
#删除无法删除的卷，用命令改变卷的状态，然后删除
cinder reset-state <volume> --state available
cinder delete <volume>
#删除僵尸卷的方法
查看当前存在的卷
[root@controller ~]# openstack volume list
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
| 4776c96c-df64-4c40-85e8-28f96f878d8c | | in-use | 1 | Attached to ade2352c-6e91-4a5c-b481-6776a04e0eae on /dev/vdb |
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
登陆数据库
use cinder;
select找到出错的数据
select id, status, display_name from volumes where id='4776c96c-df64-4c40-85e8-28f96f878d8c';
修改数据库记录状体
update volumes set deleted=1 where id='4776c96c-df64-4c40-85e8-28f96f878d8c';