经过多次测试。。。建议安装4.13.0版本.系统模板选择4.11.3。。。
http://download.cloudstack.org/centos/7/4.12/
http://download.cloudstack.org/systemvm/4.11/systemvmtemplate-4.11.2-kvm.qcow2.bz2
一、 sshd 端口是 5555 而不是 22 可能是22 端口开放不安全。。。
但是CloudStack在添加主机时，管理节点要通过 ssh 连接到计算节点进行基本设置。而使用的端口就是22.。。。 未找到如何更改CloudStack连接端口 的设置。。只能从计算节点入手。可以使用端口转发。
22-5555 。。。这似乎一样不安全。不太懂，设置一下
一般不要更改 SSHD的端口。cloudstack需要使用ssh 切默认连接使用的22端口。如果使用防火墙firewalld设置端口转发。大概率 添加主机时会报错 SSL。。。并不是防火墙端口问题。
方式一。 防火墙firewalld 设置端口转发。
先允许防火墙 伪装IP
firewall-cmd --add-masquerade --permanent
firewall-cmd --reload
设置端口转发
firewall-cmd --add-forward-port=port=22:proto=tcp:toport=5555 --permanent
firewall-cmd --reload
查看端口转发
firewall-cmd --list-forward
这时 就又可以通过22端口使用 ssh 连接了。。。
问题是，使用虚拟机部署时一点问题都没有，但是真实环境部署时，可能是打开的防火墙的关系。。。一直有错误
2020-04-20 21:54:13,159 ERROR [o.a.c.c.p.RootCACustomTrustManager] (pool-32-thread-1:null) (logid:) Certificate ownership verification failed for client: 10.21.43.253
2020-04-20 21:54:13,160 ERROR [c.c.u.n.Link] (AgentManager-SSLHandshakeHandler-2:null) (logid:) SSL error caught during wrap data: General SSLEngine problem, for local address=/10.21.143.253:8250, remote address=/10.21.43.253:43130.
方式二。使用rinetd 软件
一个n年前的端口转发软件。不过还可以使用。。。不用防火墙。
设置安装源
vim /etc/yum.repos.d/nux-misc.repo
[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el7/x86_64/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro
安装
yum -y install rinetd --disablerepo="*" --enablerepo=nux-misc
安装完成后可查看安装信息
rpm -ql rinetd
配置 文件 是/etc/rinetd.conf
有注释，大概看得懂 我们只需末尾加两行 其实加第一行就够了 第二行是表示注释的位置
192.168.199.65 22 192.168.199.65 5555
logfile /var/log/rinetd.log
第一行的意思是 将 192.168.199.65的22端口转发到 192.168.199.65的5555端口。。。
然后设置 rinetd 开机自启 和 启动rinetd
systemctl enable rinetd
systemctl start rinetd
查看 rinetd 端口转发情况
netstat -apn | grep 'rinetd'
似乎并不能实现，依然是虚拟机上运行正常，一到真正机器上就不行了。。。
二，真实环境下网络问题
本机使用虚拟机安装 虚拟机和主机之间是桥接或者 NAT。
真实环境下 使用 基本网络设置 选择 默认网络设置后。。。很可能发现二级存储系统VM之类都很正常，但是个人创建的虚拟机外部无法访问。只能宿主机访问。 个人感觉测试时未出现这种情况原因是 虚拟机和主机就是一个电脑。。。CloudStack的安全组完全不会阻塞
如果没有指定入口规则，那么流量会被禁止，除了已经允许通过一个出口规则响应任何流量 。
如果出口规则没有说明，所以的流量都被允许出去一旦进行了说明，则以下流量可以允许出去：在出口规则中进行说明的，查询DNS和DHCP服务器的，响应来自入口规则允许进入的流量的
所以出口规则一般不要设置。。。
真实环境下安装 要设置 安全组。。。
查看网络 基本网络设置的 默认网络
选择视图 安全组
添加入口规则
当然 出口规则应该也是要添加的 暂时不明白如何添加。。。
三， CentOS7 虚拟主机IP无法访问。
使用cloudstack4.11.0 时，安装部署完成后。再创建虚拟机时可能会出现问题。。。基础网络设置下。
CentOS6设置ONBOOT=yes 后 可以正常启动，然后局域网可以访问到该主机。。。
但是CentOS7安装后 设置network一直无法正常启动 如果设置静态IP会导致。只有宿主机可以访问该网络。。。该问题无法解决。。。
直到卸载了 cloudstack4.11.0 安装了 cloudstack4.11.3
然后就正常了。。。
个人遇到的不正常问题。可能并不是这个原因引发的。。。
不正常 cloudstack安装完成后先添加资源域之后在全局设置 secstorage 0.0.0.0/0 我先设置后再添加资源域 主机一直添加失败。。可能并不是这个原因。。。。真正原因未知
安装后不要着急。。。要耐心等待
四，CPU型号显示问题。。。
默认情况下。。默认情况下，KVM实例的CPU模型可能是QEMU虚拟CPU版本x.x.x，其CPU特性暴露最少。
比如 CentOS6 虚拟机 下查看 CPU型号
cat /proc/cpuinfo
[root@CentOS6Test1 ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version 1.5.3
stepping : 3
microcode : 1
cpu MHz : 2793.048
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good unfair_spinlock pni cx16 hypervisor lahf_lm pti retpoline
bogomips : 5586.09
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
model name : QEMU Virtual CPU version 1.5.3 这个型号。。。
又如 Window下的CPU型号
按cloudstack官方文档来说 CPU特性暴露最少。。。但是有时候希望显示正常的CPU尤其是windows下
官方文档有几个方式可以指定CPU模型： 这里备注一下，按个人理解，不知道是不是一个宿主机下所有虚拟机的CPU型号都是一样的。。应该是吧。毕竟都使用了宿主机的CPU。。。
有三个方式 设置cpu
添加主机前设置计算节点文件
vim /etc/cloudstack/agent/agent.properties
- custom 指定CPU型号
guest.cpu.mode=custom
guest.cpu.model=SandyBridge
guest.cpu.model = 指定的CPU型号。。。需要是kvm支持的。。。具体支持哪些，可以查看/usr/share/libvirt/cpu_map.xml 文件
或者 查看命令
/usr/libexec/qemu-kvm -cpu ?
这个方式。。怎么说呢，一般指定的CPU型号 最好是和宿主机的CPU型号类似的，不然 系统虚拟机都有可能启动失败 别提 创建新的虚拟主机了。。。
2. host-model 根据宿主机的 CPU 自动在/usr/share/libvirt/cpu_map.xml 需再选择一个和宿主机CPU最接近的 模型。
guest.cpu.mode=host-model
个人 认为 一般设置成这样就行了。。。
3.host-passthrough 虚拟机使用的CPU型号和宿主机的每个细节都是匹配的。。。一般没必要那么精准。。。使用该方式的话虚拟主机迁移时只能迁移到具有完全相同型号CPU 的主机上
guest.cpu.mode=host-passthrough
guest.cpu.features=vmx
个人感觉 使用 2 就好了。。。 方式2设置CPU型号后。。创建完成的虚拟主机 查看CPU型号
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel Core i7 9xx (Nehalem Class Core i7)
stepping : 3
microcode : 1
cpu MHz : 2793.048
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up rep_good unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm pti retpoline
bogomips : 5586.09
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
没有用windows做实验。。感觉应该差不太多。。。
http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html
另，cloudstack似乎是无法为每个虚拟机指定 不同CPU模型的。只能每个宿主机的所有虚拟主机使用同一个CPU型号设置。。。尽管使用的kvm，好像单纯使用kvm创建虚拟机 可以 为每个虚拟主机设置mode吧。。。不清楚，但是cloudstack使用kvm应该是不行的
补，最后又使用新的机器安装了WindowsServer2012R2 。。。查看CPU型号
使用方式三 测试一下。。。
宿主机CPU 信息
[root@agent ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
stepping : 5
microcode : 0x5
cpu MHz : 2793.049
cache size : 8192 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf eagerfpu pni vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm tpr_shadow vnmi ept vpid tsc_adjust dtherm ida
bogomips : 5586.09
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
计算节点 也就是宿主机 的 /etc/cloudstack/agent/agent.properties 最终文件
[root@agent ~]# cat /etc/cloudstack/agent/agent.properties
#Storage
#Wed May 06 14:26:07 CST 2020
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
guest.network.device=cloudbr0
local.storage.uuid=1c731a2a-ca54-4e09-b24b-c998cfb886ad
port=8250
guest.cpu.features=vmx
host=192.168.199.91
pod=1
guid=e2aa0a07-271e-3e5e-8246-bddf881c1dd0
LibvirtComputingResource.id=1
cluster=1
public.network.device=cloudbr0
private.network.device=cloudbr0
zone=1
domr.scripts.dir=scripts/network/domr/kvm
keystore.passphrase=XrSUv9VTpzp9GTk5
guest.cpu.mode=host-passthrough
workers=5
hypervisor.type=kvm
可以看到 两行
guest.cpu.mode=host-passthrough
guest.cpu.features=vmx
最终安装在此宿主机上的 虚拟实例CPU信息
[root@CentOS6Test ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
stepping : 5
microcode : 1
cpu MHz : 2793.048
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon rep_good unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm pti retpoline
bogomips : 5586.09
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
真的几乎一模一样 除了大小。。。不过一般不建议使用 这个模式。迁移问题挺麻烦的。。。
一般使用 guest.cpu.mode=host-model 就足够了。。。如果没有要求。。个人感觉不设置 也是很正常的啊
没想到 还有要求宿主机上的每个虚拟机 设置不同型号的CPU的 要求
看文档 查看支持的 CPU型号 qemu-kvm … 问题是这个命令都没有 怎么指定。。。
难道安装CloudStack之前安装 qemu* libvirtd*
CloudStack环境下似乎并不能使用qemu 为单独的虚拟实例设置独特的 CPU型号。只能是所有在一个宿主机下的虚拟实例使用相同的CPU模型。
https://blog.csdn.net/dandanfengyun/article/details/106046666
设置完毕需要 重启计算节点 重启管理节点
systemctl restart cloudstack-agent
systemctl restart cloudstack-management
宿主机为这台计算节点的主机应该 关闭后再启动，CPU型号才会改变
五，WindowsServer2008R2 IP分配问题。。。
这个 也是蛮神奇的。。。具体哪里出错了也不清楚。
cloudstack设置的来宾IP为 XX.XX.100.20 —— XX.XX.100.219
结果 安装完 WindowsServer 2008之后 ipconfig
这个 101.108 哪里冒出来的。。。只能手动设置 cloudstack分配的IP
点击如下属性即可设置 IPV4 信息
然后分配正常的IP 注 该IP地址一定要是 CloudStack为该虚拟机分配的。。。
似乎WindowsServer2008R2 还有一些其它网络设置。。。要开启网络中心共享之类的才能与外界互联。。不过先不管那些，这时候 至少 网络图标是正常的了。。。
六、虚拟实例无法停止。
不只是在真实环境下，4.11.3版本的cloudstack在尝试停止虚拟机都会报错。。。
Command failed due to Internal Server Error
4.11.0版本的就没这个问题。我一度怀疑是版本问题。。。但是4.11.0真实环境下来宾网络又有问题。。。唉。郁闷。。。该问题未解决
无法停止虚拟实例 也就意味着无法使用虚拟实例创建模板。。。 每次添加实例都是使用ISO新建一个。
还是版本问题 4.11.2 可以正常停止虚拟实例，真实环境下 来宾网络也是正常的。。。
七、根据停止的实例创建的模板。再根据该模板创建新的虚拟机后，虚拟实例网络有问题。
感觉一般 CentOS6 会遇到该问题。。。一般是因为克隆引起的。HWADDR 对不上。且DEVICE由eth0变为了eth1 只要手动修改 ifcfg-eth0 文件。改成正确的HWADDR和DEVICE即可。
模板可以下载下来。重新安装cloudstack后可以当做模板上传。不要从本地添加。。。从本地添加会 noupload.且模板似乎无法删除？ 从URL 添加可正常添加 模板也能正常删除。。有正在使用的除外 不过也可以强制删除。
模板从数据库删除
CloudStack中对模板的信息，会分别存放在5个表中：vm_template，template_host_ref，template_zone_ref，template_spool_ref，template_swift_ref。
依次将表中对应模板数据删除即可。有外键关系。所以要按顺序。。。
a foreign key constraint fails (`cloud`.`template_store_ref`, CONSTRAINT `fk_template_store_ref__template_id` FOREIGN KEY (`template_id`) REFERENCES `vm_template` (`id`))
由于此次删除的是本地上传未成功的模板，所以其他三个表没数据需要删。。。
先删除template_store_ref 表
delete from template_store_ref where template_id in (select id from vm_template where state='NotUploaded');
再删除vm_template表
delete from vm_template where state='NotUploaded';
八、添加主存储和二级存储
添加新的主存储时，一般来说，不管使用什么协议。。。提供程序需要选择DefaultPrimary而不是SolidFire。。。。。。。
主存储删除要先启用维护模式 后才能删除
二级存储似乎并不能使用ceph。。。
九、cpu或者内存资源不够用。。。
这个会导致创建虚拟实例失败。资源不足什么的。
VPS开机就占了CPU和内存，不是动态使用，这样无法把资源充分利用
应该 做到虚拟机真正运行任务时才占用 实际CPU和内存。
我觉得没有这样的设置吧。。。因为虚拟机运行时，查看宿主机的内存和CPU使用率，也并没有真的就是虚拟机的内存使用加起来那么多，但是UI显示上 占用的CPU和内存是不会变的。本来就是虚拟机运行任务时才会占用内存和cpu。CPU和内存超载就是考虑到这个问题，所以才允许设置的。
不够用的话。可以设置超载。一般来说，CPU超载可以设置3-4倍，内存的话，根据实际运行情况，如果平时虚拟实例空闲运行状态比较多。自行考虑设置倍数
设置步骤。
一，现在测试用的Cloudstack资源如下
CPU 11.17GHz 内存3G。内存当然是十分小的，很容易就不够用。可以设置一下内存超配。
CPU全局配置
cluster.cpu.allocated.capacity.disablethreshold 表示占用CPU达到可用CPU的多少占比时，提示错误。 这个值一般不改。
cluster.cpu.allocated.capacity.notificationthreshold 表示达到多少占比时，发出警告。要小于cluster.cpu.allocated.capacity.disablethreshold 的值。
cpu.overprovisioning.factor CPU超配倍数。。可用CPU = 实际CPU * 超配倍数
内存 mem全局配置
和CPU 情况差不多
cluster.memory.allocated.capacity.disablethreshold 内存占比超过该值报错。
cluster.memory.allocated.capacity.notificationthreshold 内存占比超过该值发出警告。
mem.overprovisioning.factor 内存超配 倍数。。。
二，UI修改全局配置。重启cloudstack-management
我们修改 CPU超配为 4.0 内存超配为2.0 然后 重启 cloudstack-managemenet
内存超配
CPU超配 4倍
重启cloudstack-management
systemctl restart cloudstack-management
完成后再次查看全局资源
emmmm，尽管全局参数设置了，但是可用的CPU和内存显示并没有增大。。。
三、修改数据库 相应配置才能生效
超额配置再全局设置中修改似乎不生效。。。只能通过数据库修改
进入 数据库，使用 cloud 库。 cloudsatck创建的库中基本常用的就这一个库。
mysql -u root -p
use cloud;
select * from cluster_details;
可以看到 两个值都是 1.0 证明UI全局设置无效。修改数据库值
update cluster_details set value=2.0 where id=1;
update cluster_details set value=4.0 where id=2;
重启 cloudstack-management
systemctl restart cloudstack-management
再次查看 全局资源
可以看到可用内存变为了 6 G CPU为 44.69.超配修改成功。。。这里全局资源设置感觉更像是一个显示作用，告诉管理员现在内存超配多少，不过这个显示作用还要靠自己修改。。。不然就是没用。因为修改数据库中数据，这两个显示并不会随之改变。。。
最后发现。全局设置超额配置并不是不能生效。而是要在添加资源域之前修改，在添加资源域集群之后修改就不能生效。如果已经添加过集群，那么想要修改超配必须修改数据库相应数据
另外 似乎4.11版本有问题，即使在数据库设置了修改，然后重启了cloudstack-management。超配显示也正常。但是，在添加新的虚拟机时时可能还是会报资源不足的错误，计算值似乎还是设置超配之前的原资源数。。。4.12 版本没有该问题。另为什么不安装最新版呢，我也不太清楚。。。尽管说最新版可能有一些未知BUG，但是这种开源的应该是最新版比其他版本稳定才对。
目前最新版本4.14 没用过。根据4.12 4.13都没有相应的系统模板来看。。。4.14应该是一个长期维护版本
还有一个存储超配的设置 。。针对主存储。一般来说为虚拟实例分配的存储是不会用完的。。默认的存储超配就是2.一般也不会修改 。这个全局设置修改后重启管理节点服务器是可以生效的。
storage.overprovisioning.factor
十、更改二级存储。
二级存储有时候用着用着不够用了。。我们希望更换二级存储。这个，添加一个二级存储的效果不确定。似乎镜像模板不会往新增的二级存储里存放。 可能是本来的二级存储还没用完的原因？
所有的二级存储都需要安装系统VM模板
这里是更改二级存储的地址，还要保证尽量不影响使用。这个不保证一定成功。
首先，禁用资源域
然后，管理节点停止cloudstack-management服务
systemctl stop cloudstack-management
接着，将原二级存储内所有内容复制到新的二级存储中。。。尽量这么做，不然模板ISO，什么的全没了。
可以在本地建一个待用二级存储的挂载点。然后将原二级存储内内容复制到待用二级存储
cp -r /export/secondary/* /export/secondary2/
复制完毕，这个新的二级存储里的内容就和原二级存储一致了。
修改数据库,主要是cloud库的image_store表
mysql -u root -p
use cloud;
select * from image_store;
修改 url 为新的二级存储地址。模仿着原二级存储url 更改，没问题的。
更改前
更改
update image_store set url='********' where id =1;
例如
update image_store set url='nfs://192.168.199.91/export/secondary2' where id =1;
更改后
接下来重启 cloudstack-management
systemctl restart cloudstack-management
然后重启资源域。。。
应该是一切正常。查看二级存储，已经变成新设置的了
十一、主存储更改。。。
正常添加一个新的主存储。
然后将原主存储启用维护模式。时间较长，耐心等待。这个过程会停掉所有使用该存储的虚拟机。。。。
也有比较麻烦的一步，需要一个一个将实例存储迁移到新增的上面
全部迁移完毕。。。然后就可以删除该主存储了。。可以强制删除。不用担心虚拟机无法启动，再次启动虚拟机时，它会在新的主存储启动。
可以启动虚拟机
相关卷在第二个主存储上
十二、转移管理节点
还未测试使用多个管理节点。先测试一下管理节点的转移。就是manager。
192.168.199.91 manager 安装management 和 数据库
192.168.199.92 agent 安装agent
现希望暂时 将management 管理程序从manager转移到agent
首先，确定如果新的管理节点和数据库不在同一个主机，需要设置数据库配置文件。
vi /etv/my.cnf
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=700
log-bin=mysql-bin
binlog-format = 'ROW'
bind-address = 0.0.0.0
和之前的相比多了一行 bind-address = 0.0.0.0。因为数据库要允许其它主机连接。
mysql -uroot -p123456 -e "GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY '123456' WITH GRANT OPTION";
设置其他所有主机可以通过 root 用户 使用密码 123456 连接到本数据库，并赋予了root用户 所有权限。
一、主动更换管理节点。
可能觉得之前的管理节点内存小之类的原因，希望更换管理节点，并不是原管理节点意外损坏。192.168.199.91 替换为192.168.199.92
原WEBUI界面更改全局设置
http://192.168.199.91:8080/client/
将 host 值设置为 新的管理节点 192.168.199.92
停止原管理节点 management 服务
192.168.199.91 主机执行
systemctl stop cloudstack-management
新节点安装manager软件，并连接数据库
新节点安装 management软件
yum -y install cloudstack-management
设置连接数据库和初始化管理服务
数据库安装在 192.168.199.91节点。。。（不要太在意，这只是一个实验，真实环境替换为真正的数据库节点就好了）
cloudstack-setup-databases cloud:123456@192.168.199.91
cloudstack-setup-management
等待管理节点设置完成可以查看一下 agent 配置文件。
cat /etc/cloudstack/agent/agent.properties
[root@agent ~]# cat /etc/cloudstack/agent/agent.properties
#Storage
#Thu Jul 02 14:33:55 CST 2020
guest.network.device=cloudbr0
workers=5
private.network.device=cloudbr0
port=8250
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
pod=1
zone=1
hypervisor.type=kvm
guid=e2aa0a07-271e-3e5e-8246-bddf881c1dd0
public.network.device=cloudbr0
cluster=1
local.storage.uuid=7eee29b9-f94d-4987-ace3-7e81122c771a
keystore.passphrase=W6OdK2K7vdPe4pDp
domr.scripts.dir=scripts/network/domr/kvm
LibvirtComputingResource.id=1
host=192.168.199.92@static
router.aggregation.command.each.timeout=600
重点看到 host 变成了 192.168.199.91@static 不管 @static是什么了，只用知道agent计算节点现在连接的是 192.168.199.92 这个管理节点就好。
通过新管理节点IP访问WEBUI界面并删除原管理节点残留信息
http://192.168.199.92:8080/client/
可以看到是成功更换管理节点了。经测试可以添加主机，创建虚拟机，设置模板。正常使用。
唯一的瑕疵在于 原管理节点有残留信息，但是并不会影响使用。如果一定要删除可以通过数据库。
down状态的 就是原管理节点。可以通过数据库删除。
mysql -u root -p
use cloud
查看管理节点信息
select * from mshost\G
可以看到id 为3 的就是原管理节点 state 为Down service_ip 为192.168.199.91 可以将这条数据删除。但在这之前还要删除 表mshost_peer和op_it_work 中对应数据，
mshost_peer的字段peer_mshost对应外键为mshost表的id段。
op_it_work字段mgmt_server_id对应外键为mshost表的msid段。
删除相关信息。
delete from mshost_peer where peer_mshost=3;
delete from op_it_work where mgmt_server_id=3232286555;
delete from mshost where id=3;
exit
删除完成 退出数据库，再次查看WEB 。发现管理节点只剩下一个了
二，管理节点意外损坏，全局变量未设置新的host
上面的是管理节点主动替换，步骤较为简单，管理节点意外损坏的话，数据库数据未丢失，更换管理节点只是多了一两步，也不复杂。
无法通过原管理节点访问WEBUI修改全局设置host
关闭cloudstack-management服务模拟管理节点意外损坏
systemctl stop cloudstack-management
创建新的管理节点进行基本配置。
192.168.199.92
安装manager管理程序
yum -y install cloudstack-management
连接数据库初始化管理程序
cloudstack-setup-databases cloud:123456@192.168.199.91
cloudstack-setup-management
使用新管理节点IP访问WEBUI修改 host 为192.168.199.92
192.168.199.92:8080/client
修改计算节点主机配置
由于host 并非原管理节点修改，计算节点主机配置配置文件需要手动修改
vim /etc/cloudstack/agent/agent.properties
将 host 修改为新管理节点IP
host=192.168.199.92
重启cloudstack-agent
systemctl restart cloudstack-agent
新管理节点在UI界面删除两个原系统VM
新的管理节点不能与原系统VM通信，需要删除掉原有系统VM。会自动生成新的VM。
等一段时间，便可看到新的系统VM
等待系统VM生成，状态变为running 和 up 管理节点即可正常使用。
删除残余信息
原管理节点残余信息删除和方式 一一致。
十三、数据库节点转移。
CloudStack 即使设置了多个管理节点，也只是和一个数据库建立了连接，当这个数据库意外发生故障。CloudStack与数据库的连接断开，管理节点就会失效。
为此准备一些数据库常用的措施，比如定期备份数据库、设置主从备份之类的。但这些备份的设置与cloudstack没有什么关系，是数据库本身备份设置问题，如何备份不做详述。
数据库意外失效，且有备份数据时，更换cloudstack使用的数据库
cloudstack与数据库建立连接使用的是 cloud 用户，操作的两个库是cloud和cloud_usage。
数据库发生意外情况 首先 停止 cloudstack-management
systemctl stop cloudstack-management
数据库内容
cloudstack-setup-databases cloud:123456@localhost --deploy-as=root:123456
可以看做 管理节点和 数据库的初始化
初始化后配置文件/etc/cloudstack/management/db.properties
下列设置可能使用
## 设置cloudstack用于和数据库连接使用的用户名密码
db.cloud.name=cloud
db.cloud.password=ENC(PMfot7AVj8R+OEXzdVOZ9w==)## 管理节点IP
cluster.node.IP=192.168.199.91## cloud 库的节点
db.cloud.host=localhost## usage 库的节点
db.usage.host=localhost
查看 数据库，可以发现多了两个用户。就是cloudstack需要使用的用户。
select user,host from mysql.user;
'cloud'@'localhost'
'cloud'@'%'
查看用户权限
show grants for 'cloud'@'%';
show grants for 'cloud'@'localhost';
可以看到cloud用户对 cloud 和cloud_usage库 有所有权限，另外 对所有库有进程管理的权限
原数据库节点操作
原数据库节点意外损坏，不应该有什么操作的。只是测试数据库节点转移，知道操作就好，不要在意细节。
备份一份数据出来，包括 cloud cloud_usage两个库的所有内容。
mysqldump -u root -p --databases cloud cloud_usage > cloud.sql
cloud.sql 是 mysql的可执行文件，执行后可以还原 cloud 和 cloud_usage 库的所有内容。但是有个前提，那就是 cloud 用户存在，且有权限
备份完毕，关闭数据库，假装数据库意外损坏
systemctl stop mariadb
新数据库节点操作
新数据库节点假设是 192.168.199.93
编辑数据库配置文件
vi /etc/my.cnf
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
bind-address = 0.0.0.0
重启数据库
systemctl restart mariadb
进入数据库控制台
mysql -u root -p
创建cloud用户并 赋予 权限
GRANT PROCESS ON *.* TO 'cloud'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON `cloud`.* TO 'cloud'@'localhost' ;
GRANT ALL PRIVILEGES ON `cloud_usage`.* TO 'cloud'@'localhost';GRANT PROCESS ON *.* TO 'cloud'@'%' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON `cloud`.* TO 'cloud'@'%';
GRANT ALL PRIVILEGES ON `cloud_usage`.* TO 'cloud'@'%';
刷新权限 退出控制台
flush privileges;
exit
将之前备份的sql文件复制到本节点，将其中数据备份到本节点数据库
mysql -u root -p < cloud.sql
现在数据已经转移到新的数据节点了，重点是 管理节点设置与新数据库管理节点建立连接
管理节点操作
管理节点 只用将 /etc/cloudstack/management/db.properties 文件中cloud和cloud_usage库相关host 改为新数据库节点 然后重新启动管理程序即可
不过一般不推荐手动修改。。。
cloudstack-setup-databases cloud:123456@192.168.199.93
cloudstack-setup-management
查看 配置文件，host 已经修改。且管理节点也正常运行了
十四。设置KVM最大来宾数。
否则默认是50，很可能很快就超出上限，然后创建VM失败。。。找错误还不是error 而是debug。
2020-11-25 20:15:41,946 INFO [c.c.c.CapacityManagerImpl] (API-Job-Executor-1:ctx-bf553e79 job-1126 ctx-46ddea4e FirstFitRoutingAllocator) (logid:e0df3994) Host name: compute-a001d4, hostId: 1 already reached max Running VMs(count includes system VMs), limit: 50, Running VM count: 50
2020-11-25 20:15:41,947 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (API-Job-Executor-1:ctx-bf553e79 job-1126 ctx-46ddea4e FirstFitRoutingAllocator) (logid:e0df3994) Host name: compute-a001d4, hostId: 1 already has max Running VMs(count includes system VMs), skipping this and trying other available hosts
默认每个KVM主机上只能运行50个 VM（Running状态）。
修改
图片上是已经修改过的。
全局设置–》选择视图（虚拟机管理程序功能）–》KVM 最大来宾数限制
十五。添加提供点后并设置可用IP后。该提供点删除时。一定要把公有IP移除，否则会影响查询公用IP 的API使用。。。
忘记删的话 只能去数据库。
ipset 和 ebtables命令
查看ipset 设置列表
ipset list
查询ebtables的nat表配置。
ebtables -t nat -L
