真实环境部署CloudStack问题和一些特别需求设置

经过多次测试。。。建议安装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

1. custom 指定CPU型号

guest.cpu.mode=custom
guest.cpu.model=SandyBridge

guest.cpu.model = 指定的CPU型号。。。需要是kvm支持的。。。具体支持哪些，可以查看/usr/share/libvirt/cpu_map.xml 文件

这个方式。。怎么说呢，一般指定的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

五，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 添加可正常添加 模板也能正常删除。。有正在使用的除外 不过也可以强制删除。

八、添加主存储和二级存储

添加新的主存储时，一般来说，不管使用什么协议。。。提供程序需要选择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:[email protected]
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:[email protected]
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 管理节点即可正常使用。

删除残余信息

原管理节点残余信息删除和方式 一一致。

十三、数据库节点转移。

十四、设置多个管理节点。

直接创建多个管理节点，会有一些问题。

可能只有一个节点可以与系统VM通信，通过该节点的IP的URL访问，UI界面才是正常的，可以看到正常的二级存储，也可以查看系统VM控制台。其它节点无法与系统VM正常通信，访问的UI显示不太准确，二级存储为0，系统VM无法查看控制台。

设置了全局设置 host= IP1,IP2 中间用逗号隔开

只测试了两个节点，两个节点日志文件都有ERROR。
可以与系统VM通信的管理节点报错。

猜测两个管理节点一个可以通信，一个不可以通信的原因是SSL问题，可能只有一个节点保存了相应的证书，因此可以访问。产生不同的原因可能是

• 创建资源域时使用的哪个IP访问的UI创建的，该IP就可以与系统VM通信
• 初始化数据库时，是在哪个管理节点执行，哪个节点就可以访问系统VM

不过重点不是探究哪一个IP可以与系统VM通信，而是要求所有管理节点都可以正常使用。看官方文档，设置多个管理节点要设置负载均衡。访问负载均衡节点。。。

附加管理服务器

• 对于第二个和以后的管理服务器，您将安装ManagementServer软件，将其连接到数据库，并为ManagementServer设置操作系统。

• 确保启动必要的服务并将其设置为在启动时启动。

service rpcbind start
service nfs start
chkconfig nfs on
chkconfig rpcbind on

• 配置数据库客户端。请注意，在本例中没有-Deploy-as参数。(有关此命令的参数的详细信息，请参阅在单独的节点上安装数据库.)

cloudstack-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key -k database_key -i management_server_ip

• 配置操作系统并启动ManagementServer：

cloudstack-setup-management

此节点上的ManagementServer现在应该正在运行。如果servlet容器是Tomcat 7，则必须使用参数-tomcat 7。

• 在每个附加管理服务器上重复这些步骤。

• 确保为管理服务器配置负载均衡器。（Be sure to configure a load balancer for the Management Servers.）

负载均衡器
应将CloudStack管理服务器部署在多节点配置中，使其不会受到单个服务器故障的影响。ManagementServer本身(与MySQL数据库不同)是无状态的，可以放在负载均衡器后面。

主机的正常运行不会受到所有管理服务中断的影响。所有来宾虚拟机都会继续工作。

当ManagementServer关闭时，无法创建新的VM，最终用户和管理UI、API、动态负载分布和HA将停止工作。

CloudStack可以使用负载均衡器为多个管理服务器提供虚拟IP。管理员负责为管理服务器创建负载均衡器规则。应用程序需要跨越多个会话的持久性或粘性。下图列出了应该负载平衡的端口，以及是否需要持久化。

即使不需要持久性，也允许启用持久性。

源端口	目的港	协议	需要持久吗
80或443	8080(或20400（AJP)	http(或AJP)	是
8250	8250	tcp	是
8096	8096	http	不

除上述设置外，管理员还负责从管理服务器IP中设置“host”全局配置值，以加载平衡器虚拟IP地址。如果未将“host”值设置为端口8250的VIP，而您的管理服务器之一崩溃，则UI仍然可用，但系统VM将无法与管理服务器联系。

测试使用HAProxy设置负载均衡，看是否可以所有管理节点都可以正常使用