CloudStack 与 Netscaler集成实现弹性伸缩功能 的测试案例及方案

前言:
 近期有很多人问过cloudstack与Netscaler的集成,以及如何实现弹性伸缩(autoscaling)功能,我去年初在一个项目中,使用了企业版的cloudplatform与Netscaler做过对接并成功实现该功能。鉴于该案例网上文档极少,很多东西都是自己摸索这搞的,现在分享给大家,希望能帮助大家。互相交流。
 
PS:早在4.3版本时,官方的所说的弹性伸缩,有两种实现方式:
  1. cloudstack与xenserver虚拟化平台对接,不依赖Netscaler设备,实现弹性伸缩功能。
  2. cloudstack与Netscaler对接,可对接kvm、xenserver、vmware等虚拟化平台,实现弹性伸缩功能。

 
但实现方式1一直没见正式发布,所以采用了方式2,与Netscaler对接的方式实现。
方式不同的地方在于:
方案1是通过cs调取xs的资源使用信息,作为弹性伸缩的依据,不依赖商业设备,可底层本实现,但仅支持xs虚拟化。
方案2是通过cs与Netscaler联动,并通过在vm中安装snmp软件,通过snmp与ns的交互,或通过ns本身的负载,作为判断依据,由cs实现弹性伸缩。
 
目录:
版本历史    2
目录    3
1.    背景概况    6
2.    测试目的    7
2.1    阶段一、云平台功能测试    7
2.2    阶段二、云平台对业务的结合及支撑能力    7
2.3    测试说明    8
3.    软硬件要求    9
3.1    软件版本    9
3.2    硬件型号    9
3.3    网络资源需求    10
3.4    存储空间需求    10
3.5    测试虚拟机列表    11
4.    前提条件    12
5.    测试环境搭建    13
5.1    测试环境架构图    13
5.2    网络配置    13
5.2.1    网络配置    13
5.2.2    IP地址配置    14
5.2.3    服务器网络配置    15
5.2.4    CloudPlatform网络规划    15
5.2.5    H3C 交换机配置    16
5.3    安装XenServer6.2    21
5.3.1    安装介质准备    21
5.3.2    系统安装配置    21
5.3.3    补丁更新    30
5.4    CloudPlatform安装配置    32
5.4.1    在XenServer中创建CCP虚拟机    32
5.4.2    Linux操作系统安装    37
5.4.3    系统初始化配置    43
5.4.4    NFS服务安装配置    47
5.4.5    MySQL服务配置    48
5.4.6    CloudPlatform软件安装配置    49
5.4.7    CloudPlatform区域配置    50
5.4.8    方案配置    67
5.4.9    上传ISO    70
5.4.10    通过ISO创建虚拟机    71
5.4.11    制作模版    80
5.5    NetScaler VPX 安装配置    83
5.5.1    导入VPX至XenServer服务器    83
5.5.2    配置VPX网络信息    87
5.5.3    上传License,并启用LB服务    88
5.5.4    查看NetScaler VPX interface 配置    91
5.6    CloudPlatform与NetScaler集成实现AutoScale    91
5.6.1    配置CCP全局参数    91
5.6.2    配置CCP并添加NetScaler VPX设备    93
5.6.3    配置CCP网络方案,定义LB由NetScaler提供    95
5.6.4    配置CCP启用NetScaler网络服务提供程序    98
5.6.5    建立隔离网络并配置AutoScale规则    99
5.6.6    验证应用LB及AutoScale    109
6.    测试过程    111
6.1    阶段一测试验证    111
6.1.1    需求一、CloudPlatform云管理平台环境搭建(包括CCP,XenServer和NetScaler)    111
6.1.2    需求二、应用系统虚机部署,在CloudPlatform上部署XXXX应用系统虚机    111
6.1.3    需求三、验证应用系统虚机可以根据CPU,内存等资源负载实现自动伸缩    112
6.1.4    需求四、除了Cloudplatform的内置资源检测项目外,能否自定义触发自动伸缩的资源检测条件    113
6.2    阶段二测试验证    113
6.2.1    需求一、云管理平台的搭建、管理和调度    113
6.2.2    需求二、GMLC和PDC业务各模块的云化安装、运行    114
6.2.3    需求三、网管跟云化管理平台的结合    114
7.    测试总结    116
 
 
方案下载:
链接  http://pan.baidu.com/s/1i5fTfE1  
提取密码  m5ud

 
 
继续阅读 »
前言:
 近期有很多人问过cloudstack与Netscaler的集成,以及如何实现弹性伸缩(autoscaling)功能,我去年初在一个项目中,使用了企业版的cloudplatform与Netscaler做过对接并成功实现该功能。鉴于该案例网上文档极少,很多东西都是自己摸索这搞的,现在分享给大家,希望能帮助大家。互相交流。
 
PS:早在4.3版本时,官方的所说的弹性伸缩,有两种实现方式:
  1. cloudstack与xenserver虚拟化平台对接,不依赖Netscaler设备,实现弹性伸缩功能。
  2. cloudstack与Netscaler对接,可对接kvm、xenserver、vmware等虚拟化平台,实现弹性伸缩功能。

 
但实现方式1一直没见正式发布,所以采用了方式2,与Netscaler对接的方式实现。
方式不同的地方在于:
方案1是通过cs调取xs的资源使用信息,作为弹性伸缩的依据,不依赖商业设备,可底层本实现,但仅支持xs虚拟化。
方案2是通过cs与Netscaler联动,并通过在vm中安装snmp软件,通过snmp与ns的交互,或通过ns本身的负载,作为判断依据,由cs实现弹性伸缩。
 
目录:
版本历史    2
目录    3
1.    背景概况    6
2.    测试目的    7
2.1    阶段一、云平台功能测试    7
2.2    阶段二、云平台对业务的结合及支撑能力    7
2.3    测试说明    8
3.    软硬件要求    9
3.1    软件版本    9
3.2    硬件型号    9
3.3    网络资源需求    10
3.4    存储空间需求    10
3.5    测试虚拟机列表    11
4.    前提条件    12
5.    测试环境搭建    13
5.1    测试环境架构图    13
5.2    网络配置    13
5.2.1    网络配置    13
5.2.2    IP地址配置    14
5.2.3    服务器网络配置    15
5.2.4    CloudPlatform网络规划    15
5.2.5    H3C 交换机配置    16
5.3    安装XenServer6.2    21
5.3.1    安装介质准备    21
5.3.2    系统安装配置    21
5.3.3    补丁更新    30
5.4    CloudPlatform安装配置    32
5.4.1    在XenServer中创建CCP虚拟机    32
5.4.2    Linux操作系统安装    37
5.4.3    系统初始化配置    43
5.4.4    NFS服务安装配置    47
5.4.5    MySQL服务配置    48
5.4.6    CloudPlatform软件安装配置    49
5.4.7    CloudPlatform区域配置    50
5.4.8    方案配置    67
5.4.9    上传ISO    70
5.4.10    通过ISO创建虚拟机    71
5.4.11    制作模版    80
5.5    NetScaler VPX 安装配置    83
5.5.1    导入VPX至XenServer服务器    83
5.5.2    配置VPX网络信息    87
5.5.3    上传License,并启用LB服务    88
5.5.4    查看NetScaler VPX interface 配置    91
5.6    CloudPlatform与NetScaler集成实现AutoScale    91
5.6.1    配置CCP全局参数    91
5.6.2    配置CCP并添加NetScaler VPX设备    93
5.6.3    配置CCP网络方案,定义LB由NetScaler提供    95
5.6.4    配置CCP启用NetScaler网络服务提供程序    98
5.6.5    建立隔离网络并配置AutoScale规则    99
5.6.6    验证应用LB及AutoScale    109
6.    测试过程    111
6.1    阶段一测试验证    111
6.1.1    需求一、CloudPlatform云管理平台环境搭建(包括CCP,XenServer和NetScaler)    111
6.1.2    需求二、应用系统虚机部署,在CloudPlatform上部署XXXX应用系统虚机    111
6.1.3    需求三、验证应用系统虚机可以根据CPU,内存等资源负载实现自动伸缩    112
6.1.4    需求四、除了Cloudplatform的内置资源检测项目外,能否自定义触发自动伸缩的资源检测条件    113
6.2    阶段二测试验证    113
6.2.1    需求一、云管理平台的搭建、管理和调度    113
6.2.2    需求二、GMLC和PDC业务各模块的云化安装、运行    114
6.2.3    需求三、网管跟云化管理平台的结合    114
7.    测试总结    116
 
 
方案下载:
链接  http://pan.baidu.com/s/1i5fTfE1  
提取密码  m5ud

 
  收起阅读 »

CentOS 6.5 安装 CS 4.8、4.9版本启动报404或mysql错误的解决方案

最近很多朋友都出现一个问题:
在使用centos、rhel 的6.5版本安装cs的4.8、4.9版本(其他版本未测试)后,访问web页面提示404错误,后台日志报如下错误:
t/WEB-INF/lib/cloud-core-4.8.0.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml]
2016-08-30 05:08:41,754 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is Data Base High Availiability enabled? Ans : false
2016-08-30 05:08:41,833 WARN [c.c.u.d.T.Transaction] (main:null) (logid:) Unable to load db configuration, using defaults with 5 connections. Falling back on assumed datasource on localhost:3306 using username:password=cloud:cloud. Please check your configuration
org.jasypt.exceptions.EncryptionInitializationException: java.lang.InternalError
at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.initialize(StandardPBEByteEncryptor.java:716)
at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.initialize(StandardPBEStringEncryptor.java:553)
at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:705)
at org.jasypt.properties.PropertyValueEncryptionUtils.decrypt(PropertyValueEncryptionUtils.java:72)
at org.jasypt.properties.EncryptableProperties.decode(EncryptableProperties.java:230)
at org.jasypt.properties.EncryptableProperties.getProperty(EncryptableProperties.java:172)
at com.cloud.utils.db.TransactionLegacy.initDataSource(TransactionLegacy.java:1025)
at com.cloud.utils.db.TransactionLegacy.<clinit>(TransactionLegacy.java:999)



分析:

检查/etc/cloudstack/management/db.properties 中发现相关加密密码未生成:
# grep -r ENC /etc/cloudstack/management/db.properties 
db.cloud.password=ENC() ##cloud数据库密码
db.usage.password=ENC() ##usage数据库密码
db.cloud.encrypt.secret=ENC() ##数据库加密密码,存放在/etc/cloudstack/management/key文件中

可以看到上方括号中并未生成加密后的数据库密码信息。此步骤应该在执行:
cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:root
数据库初始化时,将数据库密码通过jaspyt.jar库加密,然后更新到db.properties文件中。

如果上述密码为空,则cloudstack启动时会报 最上方的报错。

排查:
定位了问题,我们需要排查为何加密后的密码未正常写入db配置文件,是加密密码未生成还是写入失败?其实cloudstack报错日志中,已经给出答案:
org.jasypt.exceptions.EncryptionInitializationException: java.lang.InternalError
java异常,内部错误。
我们来验证下,手动执行明文密码加密程序,看是否能生成加密密码:
# java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.2.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh input="cloud" password="`cat /etc/cloudstack/management/key`" verbose=false
输出:java.lang.InternalError
正常情况下,该命令会直接输出“cloud”加密后的字符串,但现在提示java异常。导致加密字符串无法生成。

解决:
新版本的CS使用jdk1.8.0版本,所以我们发现在6.5中,安装的jdk版本为1.7.0,并未安装1.8.0,所以安装即可:
yum install java-1.8.0-openjdk  java-1.8.0-openjdk-devel
然后测试,再次运行上述加密程序:
# java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.2.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh input="cloud" password="`cat /etc/cloudstack/management/key`" verbose=false
输出:Ml0pjO5fucvBWEUdM4nmtQ==
现在已经正常了。

再次运行数据库初始化脚本即可。
cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:root
注意:
本文针对的环境是 CentOS6.5版本,其他版本未必是该原因。
推荐使用另外一个解决方案是,使用6.7或6.8版本的centos或者使用centos7.

 
继续阅读 »
最近很多朋友都出现一个问题:
在使用centos、rhel 的6.5版本安装cs的4.8、4.9版本(其他版本未测试)后,访问web页面提示404错误,后台日志报如下错误:
t/WEB-INF/lib/cloud-core-4.8.0.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml]
2016-08-30 05:08:41,754 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is Data Base High Availiability enabled? Ans : false
2016-08-30 05:08:41,833 WARN [c.c.u.d.T.Transaction] (main:null) (logid:) Unable to load db configuration, using defaults with 5 connections. Falling back on assumed datasource on localhost:3306 using username:password=cloud:cloud. Please check your configuration
org.jasypt.exceptions.EncryptionInitializationException: java.lang.InternalError
at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.initialize(StandardPBEByteEncryptor.java:716)
at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.initialize(StandardPBEStringEncryptor.java:553)
at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:705)
at org.jasypt.properties.PropertyValueEncryptionUtils.decrypt(PropertyValueEncryptionUtils.java:72)
at org.jasypt.properties.EncryptableProperties.decode(EncryptableProperties.java:230)
at org.jasypt.properties.EncryptableProperties.getProperty(EncryptableProperties.java:172)
at com.cloud.utils.db.TransactionLegacy.initDataSource(TransactionLegacy.java:1025)
at com.cloud.utils.db.TransactionLegacy.<clinit>(TransactionLegacy.java:999)



分析:

检查/etc/cloudstack/management/db.properties 中发现相关加密密码未生成:
# grep -r ENC /etc/cloudstack/management/db.properties 
db.cloud.password=ENC() ##cloud数据库密码
db.usage.password=ENC() ##usage数据库密码
db.cloud.encrypt.secret=ENC() ##数据库加密密码,存放在/etc/cloudstack/management/key文件中

可以看到上方括号中并未生成加密后的数据库密码信息。此步骤应该在执行:
cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:root
数据库初始化时,将数据库密码通过jaspyt.jar库加密,然后更新到db.properties文件中。

如果上述密码为空,则cloudstack启动时会报 最上方的报错。

排查:
定位了问题,我们需要排查为何加密后的密码未正常写入db配置文件,是加密密码未生成还是写入失败?其实cloudstack报错日志中,已经给出答案:
org.jasypt.exceptions.EncryptionInitializationException: java.lang.InternalError
java异常,内部错误。
我们来验证下,手动执行明文密码加密程序,看是否能生成加密密码:
# java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.2.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh input="cloud" password="`cat /etc/cloudstack/management/key`" verbose=false
输出:java.lang.InternalError
正常情况下,该命令会直接输出“cloud”加密后的字符串,但现在提示java异常。导致加密字符串无法生成。

解决:
新版本的CS使用jdk1.8.0版本,所以我们发现在6.5中,安装的jdk版本为1.7.0,并未安装1.8.0,所以安装即可:
yum install java-1.8.0-openjdk  java-1.8.0-openjdk-devel
然后测试,再次运行上述加密程序:
# java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.2.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh input="cloud" password="`cat /etc/cloudstack/management/key`" verbose=false
输出:Ml0pjO5fucvBWEUdM4nmtQ==
现在已经正常了。

再次运行数据库初始化脚本即可。
cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:root
注意:
本文针对的环境是 CentOS6.5版本,其他版本未必是该原因。
推荐使用另外一个解决方案是,使用6.7或6.8版本的centos或者使用centos7.

  收起阅读 »

升级到4.9后报错,mysql提示错误的解决方案

问题:
从低版本升级到4.9.0后,可能会造成管理端启动时无法连接数据库,有如下报错:
Unble to gent a new db connction
java.sql.SQLException:Access denied for user 'cloud'@'localhost' (using password:YES)
解决:
主要的报错在于升级后db.properties文件被改写,而漏了数据库的driver配置。
首先确认该文件中是否没有如下几行记录,如果没有,加上即可:
db.cloud.driver=jdbc:mysql
db.usage.driver=jdbc:mysql
db.simulator.driver=jdbc:mysql
然后重启管理端服务:
service cloudstack-management restart
继续阅读 »
问题:
从低版本升级到4.9.0后,可能会造成管理端启动时无法连接数据库,有如下报错:
Unble to gent a new db connction
java.sql.SQLException:Access denied for user 'cloud'@'localhost' (using password:YES)
解决:
主要的报错在于升级后db.properties文件被改写,而漏了数据库的driver配置。
首先确认该文件中是否没有如下几行记录,如果没有,加上即可:
db.cloud.driver=jdbc:mysql
db.usage.driver=jdbc:mysql
db.simulator.driver=jdbc:mysql
然后重启管理端服务:
service cloudstack-management restart
收起阅读 »

CPVM 和 SSVM 不能启动,CCVM一会启动一会儿停止

检查日志内容:
 Unable to start instance due to Unable to acquire lock on VMTemplateStoragePool
 
类似报错是由于二级存储挂载问题导致,检查二级存储发现是由于写错路径导致,重新修改二级存储配置,重新启动资源域,结果正常。
继续阅读 »
检查日志内容:
 Unable to start instance due to Unable to acquire lock on VMTemplateStoragePool
 
类似报错是由于二级存储挂载问题导致,检查二级存储发现是由于写错路径导致,重新修改二级存储配置,重新启动资源域,结果正常。 收起阅读 »

控制台无法打开


最近在使用Cloudstack4.7.1时遇到一个问题,无法打开控制台

提示如下:

    火狐浏览器:

    无法找到在10-244-12-12.realhostip.com的服务器

    谷歌浏览器:

    Unable to resolve the server's DNS address.



看上去像是DNS无法解析,此前大都用cloudstack4.3版本,没碰到过控制台有域名解析,为何么这里有域名解析?

经咨询,4.3以前的版本是通过https://x-x-x-x.realhostip.com方式访问控制台,

从4.3开始已经把https 和DNS解析去掉了,但是从老版本升级的还是会默认保留以前的配置

而我的Cloudstack4.7.1是由4.2.0升级而来,所以有了这种现象

那么我们需要把全局变量做下修改

secstorage.ssl.cert.domain  值设为空

consoleproxy.url.domain  值设为空



就可以把https改为http 域名改为IP

需要注意的是:

1.修改后要重启management

2.CPVM要删除重建,否则无法连接





这里也顺便讨论下其他的无法访问console的情况:


①.Client communic action error,please retry later.

②.access isdenied for the console session.Please close the window and retry again

③.unable to start console sesion as connection is refused by the machine you aacessing



(1) 查看CPVM的Console是否正常,如果也打不开,则尝试重启CPVM

  如果CPVM公共IP地址不能Ping通,则删除CPVM,让CloudStack进行重建即可

(2) 如果CPVM的Console正常,把报错的虚拟机Console关闭后重新打开



这个问题一般就是 由于CPVM某些原因出现了异常,不能正常提供服务,修复CPVM即可


 
继续阅读 »

最近在使用Cloudstack4.7.1时遇到一个问题,无法打开控制台

提示如下:

    火狐浏览器:

    无法找到在10-244-12-12.realhostip.com的服务器

    谷歌浏览器:

    Unable to resolve the server's DNS address.



看上去像是DNS无法解析,此前大都用cloudstack4.3版本,没碰到过控制台有域名解析,为何么这里有域名解析?

经咨询,4.3以前的版本是通过https://x-x-x-x.realhostip.com方式访问控制台,

从4.3开始已经把https 和DNS解析去掉了,但是从老版本升级的还是会默认保留以前的配置

而我的Cloudstack4.7.1是由4.2.0升级而来,所以有了这种现象

那么我们需要把全局变量做下修改

secstorage.ssl.cert.domain  值设为空

consoleproxy.url.domain  值设为空



就可以把https改为http 域名改为IP

需要注意的是:

1.修改后要重启management

2.CPVM要删除重建,否则无法连接





这里也顺便讨论下其他的无法访问console的情况:


①.Client communic action error,please retry later.

②.access isdenied for the console session.Please close the window and retry again

③.unable to start console sesion as connection is refused by the machine you aacessing



(1) 查看CPVM的Console是否正常,如果也打不开,则尝试重启CPVM

  如果CPVM公共IP地址不能Ping通,则删除CPVM,让CloudStack进行重建即可

(2) 如果CPVM的Console正常,把报错的虚拟机Console关闭后重新打开



这个问题一般就是 由于CPVM某些原因出现了异常,不能正常提供服务,修复CPVM即可


  收起阅读 »

CloudStack升级到4.7.1后系统虚拟机无法启动

概述:
因为此前已经按照Cloudstack官方升级文档做过测试,所以此次参照官方升级文档以为是信手拈来,万万没想到 一不留神就掉进深坑  在此先感谢大神@ak_qq的鼎力帮助。
官方升级文档:
http://docs.cloudstack.apache. ... .html

环境:
使用Cloudplatform 4.2.0, 共五个zone:
  • zone01 vmware环境 5.1
  • zone02 vmware5.1+kvm(redhat6.3)
  • zone03 kvm(redhat6.3)
  • zone04 kvm (redhat6.3)
  • zone05 kvm(redhat6.5)

所有KVM使用的存储类型为CLVM
所有VMWare使用的存储类型NFS 


 踩坑经过:
现在复述下升级过程的坎坷经历 ,有条不紊的按照官方文档升级:
 1.上传模板    
  •     上传系统模板时候选择的all zone(没意识到此已经处埋下伏笔)
  •     上传systemvm-kvm-4.6
  •     上传systemvm-vmware-4.6 

 2.备份数据库
 3.升级kvm host    
  •     升级qemu-img
  •     升级cloudstack-agent 

 4.升级管理端

怀着满心期待的心情启动management,打开日志滚动 ,嗯,正常的节奏,井井有序的在升级数据库。
就尝试打开web,果然打开了,有点小鸡冻。

可是随后就发现host里面物理机大部分都是disconnect状态,纳闷了,
找了一台物理机登录上去瞅了下,发现cloudstack-agent状态不正常 无法启动,
检查内存磁盘空余 还有很多 多次尝试重启agent 然并卵。。。
这不科学!!!
突然想到upgrade的时候安装了有java-1.7 会不会因为这个:
[root@kvm01 ~]#rpm -qa | grep java 
java-1.6.0-openjdk-devel-1.6.0.0-1.66.1.13.0.el6.x86_64
ant-javamail-1.7.1-13.el6.x86_64
tzdata-java-2013g-1.el6.noarch
java_cup-0.10k-5.el6.x86_64
java-1.5.0-gcj-javadoc-1.5.0.0-29.1.el6.x86_64
java-1.6.0-openjdk-1.6.0.0-1.66.1.13.0.el6.x86_64
java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64
java-1.7.0-openjdk-1.7.0.45-2.4.3.3.el6.x86_64
果然 把java-1.6.0相关的包删除 就好了,host里面物理机正常了 那么就来看下systemvm 。
发现只zone01的系统vm重启后正常 其他区域的系统都无法重启新建,查看日志报错:
Invocation exception, caused by: 
com.cloud.utils.exception.CloudRuntimeException: Template 322 has not been completely downloaded to zone 5
再查看2,3,4,5区域果真没有新上传的系统模板,悲剧了(后来才意识到这是因为各个区域网络隔离,二级存储不通的原因导致) ,此时向@ak_qq大神求救后 大神分享了一篇文章
http://note.youdao.com/share/% ... Dnote

看了下情况有些类似 但不完全相同,但是此文提到一个表template_store_ref,按照template_id=322(322是上传的4.6的系统模板id)查询出了两条记录如下:
*************************** 1. row ***************************
id: 8137
store_id: 10
template_id: 322
created: 2016-03-26 12:26:43
last_updated: 2016-03-26 09:07:09
job_id: ab77d559-6814-4d1f-8cc7-5652f2363749
download_pct: 100
size: 3145728000
store_role: Image
physical_size: 322954240
download_state: DOWNLOADED
error_str: Install completed successfully at 3/26/16 4:36 AM
local_path: /mnt/SecStorage/a42f0bc8-404e-3dc1-be92-70120a410fbd/template/tmpl/2/322/dnld8096114924302918339tmp_
install_path: template/tmpl/2/322/bfe62afd-9aeb-3079-bb6b-0102b3492d56.qcow2
url: NULL
download_url: NULL
download_url_created: NULL
state: Ready
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 12:27:36
*************************** 2. row ***************************
id: 8261
store_id: 13
template_id: 322
created: 2016-03-26 08:05:23
last_updated: 2016-03-26 08:06:23
job_id: NULL
download_pct: 0
size: 0
store_role: Image
physical_size: 0
download_state: DOWNLOAD_ERROR
error_str: Timeout waiting for response from storage host
local_path: NULL
install_path: NULL
url: NULL
download_url: NULL
download_url_created: NULL
state: Allocated
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 08:06:23
******************************************************




看了之后发现id 8261 这条记录是因为下载模板超时(上传模板时候选择的allzone,各个zone之间网络不通) ,既然如此那可不可以把这条记录改成下载成功的状态,然后手动把模板文件导入到对应的zone二级存储内呢?
说干就干,按照成功的那条把失败的那条记录进行修改如下:
id: 8261 
store_id: 13
template_id: 322
created: 2016-03-26 12:26:43
last_updated: 2016-03-26 09:07:09
job_id: ab77d559-6814-4d1f-8cc7-5652f2363749
download_pct: 100 size: 3145728000
store_role: Image physical_size: 322954240
download_state: DOWNLOADED
error_str: Install
completed successfully at 3/26/16 4:36 AM
local_path: /mnt/SecStorage/a42f0bc8-404e-3dc1-be92-70120a410fbd/template/tmpl/2/322/dnld8096114924302918340tmp_
install_path: template/tmpl/2/322/98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2
url: NULL
download_url: NULL
download_url_created: NULL
state: Ready
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 12:27:36
改了表以后还有一步操作  把系统模板导入到zone05的二级存储:
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/nfs -f systemvm64template-4.6.0-kvm.qcow2.bz2 -h kvm -s -F
导入后发现模板被导入到template/tmpl/1/322目录下 :
mv template/tmpl/1/322 template/tmpl/2/322
拷贝完后还需编辑template.properties:
filename=98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2 
id=322 qcow2.size=322954240
public=true uniquename=322-2-7d2fec17-0405-340e-8e20-a5d4deee3d72
qcow2.virtualsize=3145728000
virtualsize=3145728000
checksum=c059b0d051e0cd6fbe9d5d4fc40c7e5d
hvm=true
description=systemvm-kvm-4.6
qcow2=true
qcow2.filename=98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2
size=322954240

注释:
filename填写模板文件的名称
id为模板在vm_template表中的id
uniquename模板在vm_template表中的uniquename
checksum模板在vm_template表中的checksum


好,是时候来检验成果了。果真奏效。perfect!!
但是没想到事情远远没这么简单。

zone02排查半天后将vmware模板导入后系统vm启动成功,但是zone03和zone04死活无法启动vm,那还是老老实实看日志吧:
management-server.log
Invocation exception, caused by: java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createVolumeFromBaseImageCallBack java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createVolumeFromBaseImageCallBack
libvirtd.log 
error : virStorageBackendVolOpenCheckMode:1012 : cannot stat file '/dev/EBS-Primary01/085ddb2f-3f87-4f88-b4de-78d2c1178e9d': No such file or directory error : virCommandWait:2308 : internal error Child process (/sbin/vgchange -aln EBS-Primary01) status unexpected: exit status 5 error : qemuMonitorIO:574 : internal error End of file from monitor

发现libvirtd日志有校验lv的动作并且失败了  那就重新激活下vg 结果发现反应特别慢(这边用的存储比较老,zone03,04 无法启动系统虚拟机也和存储有些关系 可能是校验超时):
vgchange -ay Primary 
vgchange -ay Primary01
vgchange -ay Primary02
vgchange -ay Primary03
/etc/init.d/libvirtd restart
/etc/init.d/cloudstack-agent stop
killall jsvc
/etc/init.d/cloudstack-agent start

事实证明希望越大失望越大,满怀欣喜的进行第N次重启systemvm,结果还是不行!!!
再仔细看下agent  发现有一条不能获取qcow2文件信息的报错:
Failed to fetch the information of file /mnt/e13c2844-b627-35e2-b256-a17c79833768/c1408ffc-a132-41a9-8803-dad9580e484c.qcow2 the error was: qemu-img: error while loading shared libraries: libusbredirparser.so.1: cannot open shared object file: No such file or directory

那咱就手动执行一把,看看到底哪里的问题 :
qemu-img info /mnt/e13c2844-b627-35e2-b256-a17c79833768/c1408ffc-a132-41a9-8803-dad9580e484c.qcow2

结果提示:
qemu-img: error while loading shared libraries: libusbredirparser.so.1: cannot open shared object file: No such file or directory
麻蛋 这是qemu-img都不能用的节奏,回想原因:
此zone的kvm系统版本为6.3,使用的qemu-img版本为CCP自带的295版本,而此次升级时,特意下载了一个新的版本进行了升级,估计是升级qemu-img时,相关依赖包没有安装,所以再次安装295版本的qemu-img即可:
rpm -e --nodeps qemu-img 
rpm -ivh qemu-img-0.12.1.2-3.295.el6.10.x86_64.rpm --nodeps
/etc/init.d/cloudstack-agent stop
killall jsvc
/etc/init.d/cloudstack-agent start
焦急的等待终于迎来了胜利的曙光,zone03可以启动systemvm,照葫芦画瓢 zone04也得以解决。
终于松了口气,可以安心的回去玩耍了,再次感谢@ak_qq和@宾哥。

最后总结:
 1.重要的事情说三遍  细心细心细心  看日志一定要细心
 2.出了问题首先检查日志 如果日志没看出来头绪   那么一定仔细检查做过的操作是否有问题 
 3.cloudstack 故障排查 无非存储 网络 agnet端 management端, 一定保证基本的功能都正常,否则就容易造成很大的迷雾。 
 
继续阅读 »
概述:
因为此前已经按照Cloudstack官方升级文档做过测试,所以此次参照官方升级文档以为是信手拈来,万万没想到 一不留神就掉进深坑  在此先感谢大神@ak_qq的鼎力帮助。
官方升级文档:
http://docs.cloudstack.apache. ... .html

环境:
使用Cloudplatform 4.2.0, 共五个zone:
  • zone01 vmware环境 5.1
  • zone02 vmware5.1+kvm(redhat6.3)
  • zone03 kvm(redhat6.3)
  • zone04 kvm (redhat6.3)
  • zone05 kvm(redhat6.5)

所有KVM使用的存储类型为CLVM
所有VMWare使用的存储类型NFS 


 踩坑经过:
现在复述下升级过程的坎坷经历 ,有条不紊的按照官方文档升级:
 1.上传模板    
  •     上传系统模板时候选择的all zone(没意识到此已经处埋下伏笔)
  •     上传systemvm-kvm-4.6
  •     上传systemvm-vmware-4.6 

 2.备份数据库
 3.升级kvm host    
  •     升级qemu-img
  •     升级cloudstack-agent 

 4.升级管理端

怀着满心期待的心情启动management,打开日志滚动 ,嗯,正常的节奏,井井有序的在升级数据库。
就尝试打开web,果然打开了,有点小鸡冻。

可是随后就发现host里面物理机大部分都是disconnect状态,纳闷了,
找了一台物理机登录上去瞅了下,发现cloudstack-agent状态不正常 无法启动,
检查内存磁盘空余 还有很多 多次尝试重启agent 然并卵。。。
这不科学!!!
突然想到upgrade的时候安装了有java-1.7 会不会因为这个:
[root@kvm01 ~]#rpm -qa | grep java 
java-1.6.0-openjdk-devel-1.6.0.0-1.66.1.13.0.el6.x86_64
ant-javamail-1.7.1-13.el6.x86_64
tzdata-java-2013g-1.el6.noarch
java_cup-0.10k-5.el6.x86_64
java-1.5.0-gcj-javadoc-1.5.0.0-29.1.el6.x86_64
java-1.6.0-openjdk-1.6.0.0-1.66.1.13.0.el6.x86_64
java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64
java-1.7.0-openjdk-1.7.0.45-2.4.3.3.el6.x86_64
果然 把java-1.6.0相关的包删除 就好了,host里面物理机正常了 那么就来看下systemvm 。
发现只zone01的系统vm重启后正常 其他区域的系统都无法重启新建,查看日志报错:
Invocation exception, caused by: 
com.cloud.utils.exception.CloudRuntimeException: Template 322 has not been completely downloaded to zone 5
再查看2,3,4,5区域果真没有新上传的系统模板,悲剧了(后来才意识到这是因为各个区域网络隔离,二级存储不通的原因导致) ,此时向@ak_qq大神求救后 大神分享了一篇文章
http://note.youdao.com/share/% ... Dnote

看了下情况有些类似 但不完全相同,但是此文提到一个表template_store_ref,按照template_id=322(322是上传的4.6的系统模板id)查询出了两条记录如下:
*************************** 1. row ***************************
id: 8137
store_id: 10
template_id: 322
created: 2016-03-26 12:26:43
last_updated: 2016-03-26 09:07:09
job_id: ab77d559-6814-4d1f-8cc7-5652f2363749
download_pct: 100
size: 3145728000
store_role: Image
physical_size: 322954240
download_state: DOWNLOADED
error_str: Install completed successfully at 3/26/16 4:36 AM
local_path: /mnt/SecStorage/a42f0bc8-404e-3dc1-be92-70120a410fbd/template/tmpl/2/322/dnld8096114924302918339tmp_
install_path: template/tmpl/2/322/bfe62afd-9aeb-3079-bb6b-0102b3492d56.qcow2
url: NULL
download_url: NULL
download_url_created: NULL
state: Ready
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 12:27:36
*************************** 2. row ***************************
id: 8261
store_id: 13
template_id: 322
created: 2016-03-26 08:05:23
last_updated: 2016-03-26 08:06:23
job_id: NULL
download_pct: 0
size: 0
store_role: Image
physical_size: 0
download_state: DOWNLOAD_ERROR
error_str: Timeout waiting for response from storage host
local_path: NULL
install_path: NULL
url: NULL
download_url: NULL
download_url_created: NULL
state: Allocated
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 08:06:23
******************************************************




看了之后发现id 8261 这条记录是因为下载模板超时(上传模板时候选择的allzone,各个zone之间网络不通) ,既然如此那可不可以把这条记录改成下载成功的状态,然后手动把模板文件导入到对应的zone二级存储内呢?
说干就干,按照成功的那条把失败的那条记录进行修改如下:
id: 8261 
store_id: 13
template_id: 322
created: 2016-03-26 12:26:43
last_updated: 2016-03-26 09:07:09
job_id: ab77d559-6814-4d1f-8cc7-5652f2363749
download_pct: 100 size: 3145728000
store_role: Image physical_size: 322954240
download_state: DOWNLOADED
error_str: Install
completed successfully at 3/26/16 4:36 AM
local_path: /mnt/SecStorage/a42f0bc8-404e-3dc1-be92-70120a410fbd/template/tmpl/2/322/dnld8096114924302918340tmp_
install_path: template/tmpl/2/322/98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2
url: NULL
download_url: NULL
download_url_created: NULL
state: Ready
destroyed: 0
is_copy: 0
update_count: 2
ref_cnt: 0
updated: 2016-03-26 12:27:36
改了表以后还有一步操作  把系统模板导入到zone05的二级存储:
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/nfs -f systemvm64template-4.6.0-kvm.qcow2.bz2 -h kvm -s -F
导入后发现模板被导入到template/tmpl/1/322目录下 :
mv template/tmpl/1/322 template/tmpl/2/322
拷贝完后还需编辑template.properties:
filename=98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2 
id=322 qcow2.size=322954240
public=true uniquename=322-2-7d2fec17-0405-340e-8e20-a5d4deee3d72
qcow2.virtualsize=3145728000
virtualsize=3145728000
checksum=c059b0d051e0cd6fbe9d5d4fc40c7e5d
hvm=true
description=systemvm-kvm-4.6
qcow2=true
qcow2.filename=98dec58d-4ef6-4f46-8e56-417da81f7b5d.qcow2
size=322954240

注释:
filename填写模板文件的名称
id为模板在vm_template表中的id
uniquename模板在vm_template表中的uniquename
checksum模板在vm_template表中的checksum


好,是时候来检验成果了。果真奏效。perfect!!
但是没想到事情远远没这么简单。

zone02排查半天后将vmware模板导入后系统vm启动成功,但是zone03和zone04死活无法启动vm,那还是老老实实看日志吧:
management-server.log
Invocation exception, caused by: java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createVolumeFromBaseImageCallBack java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createVolumeFromBaseImageCallBack
libvirtd.log 
error : virStorageBackendVolOpenCheckMode:1012 : cannot stat file '/dev/EBS-Primary01/085ddb2f-3f87-4f88-b4de-78d2c1178e9d': No such file or directory error : virCommandWait:2308 : internal error Child process (/sbin/vgchange -aln EBS-Primary01) status unexpected: exit status 5 error : qemuMonitorIO:574 : internal error End of file from monitor

发现libvirtd日志有校验lv的动作并且失败了  那就重新激活下vg 结果发现反应特别慢(这边用的存储比较老,zone03,04 无法启动系统虚拟机也和存储有些关系 可能是校验超时):
vgchange -ay Primary 
vgchange -ay Primary01
vgchange -ay Primary02
vgchange -ay Primary03
/etc/init.d/libvirtd restart
/etc/init.d/cloudstack-agent stop
killall jsvc
/etc/init.d/cloudstack-agent start

事实证明希望越大失望越大,满怀欣喜的进行第N次重启systemvm,结果还是不行!!!
再仔细看下agent  发现有一条不能获取qcow2文件信息的报错:
Failed to fetch the information of file /mnt/e13c2844-b627-35e2-b256-a17c79833768/c1408ffc-a132-41a9-8803-dad9580e484c.qcow2 the error was: qemu-img: error while loading shared libraries: libusbredirparser.so.1: cannot open shared object file: No such file or directory

那咱就手动执行一把,看看到底哪里的问题 :
qemu-img info /mnt/e13c2844-b627-35e2-b256-a17c79833768/c1408ffc-a132-41a9-8803-dad9580e484c.qcow2

结果提示:
qemu-img: error while loading shared libraries: libusbredirparser.so.1: cannot open shared object file: No such file or directory
麻蛋 这是qemu-img都不能用的节奏,回想原因:
此zone的kvm系统版本为6.3,使用的qemu-img版本为CCP自带的295版本,而此次升级时,特意下载了一个新的版本进行了升级,估计是升级qemu-img时,相关依赖包没有安装,所以再次安装295版本的qemu-img即可:
rpm -e --nodeps qemu-img 
rpm -ivh qemu-img-0.12.1.2-3.295.el6.10.x86_64.rpm --nodeps
/etc/init.d/cloudstack-agent stop
killall jsvc
/etc/init.d/cloudstack-agent start
焦急的等待终于迎来了胜利的曙光,zone03可以启动systemvm,照葫芦画瓢 zone04也得以解决。
终于松了口气,可以安心的回去玩耍了,再次感谢@ak_qq和@宾哥。

最后总结:
 1.重要的事情说三遍  细心细心细心  看日志一定要细心
 2.出了问题首先检查日志 如果日志没看出来头绪   那么一定仔细检查做过的操作是否有问题 
 3.cloudstack 故障排查 无非存储 网络 agnet端 management端, 一定保证基本的功能都正常,否则就容易造成很大的迷雾。 
  收起阅读 »

CloudStack+XenServer6.2 部署手册

根据POC环境,整理了这个CloudStack4.3.1+XenServer6.2 sp1的 部署手册。

此手册支持更高版本的cloudstack,并不限于CS4.3.1和XS6.2

相关软件下载连接稍后补充。
文档下载   http://pan.baidu.com/s/1sk3VTDz
继续阅读 »
根据POC环境,整理了这个CloudStack4.3.1+XenServer6.2 sp1的 部署手册。

此手册支持更高版本的cloudstack,并不限于CS4.3.1和XS6.2

相关软件下载连接稍后补充。
文档下载   http://pan.baidu.com/s/1sk3VTDz
收起阅读 »

CloudStack升级后,KVM agent无法与管理端建立连接,提示Unable to initialize the threads. java.io.IOException

测试环境:
  • CloudStack4.3.1
  • XenServer6.2SP1(1个群集,使用本地硬盘)
  • KVM(redhat6.3)

背景:
目前一生产环境在实际使用中,发现致命问题(bug/功能缺陷):
https://issues.apache.org/jira/browse/CLOUDSTACK-6004   (主要原因)
https://issues.apache.org/jira ... -6810
https://issues.apache.org/jira ... -8196
https://issues.apache.org/jira ... -5967
发现其中一个使用本地存储的XenServer群集中的虚拟机,无法在线/离线迁移(XS本身支持跨存储的迁移),此坑不多说。
反正就是要升级到4.5.2(因为这个bug在4.5.x中解决,之前版本中未找到bugfix,蛋疼的是据说4.3.0里面没这个问题)

升级过程:
不多说,ISO标准流程。
参见:
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.2/upgrade/upgrade-4.3.html
老鸟了,所以一切顺利。
管理端服务正常启动。
然后,
然后悲剧了:
SSVM+CPVM  VM state正常,为running,但Agent state不正常,为空。
KVM agent 服务可以启动,但日志中,如下报错循环抛出:
2016-01-19 11:19:11,294 INFO  [cloud.agent.AgentShell] (main:null) Agent started
2016-01-19 11:19:11,295 INFO [cloud.agent.AgentShell] (main:null) Implementation Version is 4.5.2
2016-01-19 11:19:11,297 INFO [cloud.agent.AgentShell] (main:null) agent.properties found at /etc/cloudstack/agent/agent.properties
2016-01-19 11:19:11,306 INFO [cloud.agent.AgentShell] (main:null) Defaulting to using properties file for storage
2016-01-19 11:19:11,307 INFO [cloud.agent.AgentShell] (main:null) Defaulting to the constant time backoff algorithm
2016-01-19 11:19:11,326 INFO [cloud.utils.LogUtils] (main:null) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-01-19 11:19:11,342 INFO [cloud.agent.AgentShell] (main:null) Preferring IPv4 address family for agent connection
2016-01-19 11:19:11,444 INFO [cloud.agent.Agent] (main:null) id is 1
2016-01-19 11:19:11,951 INFO [kvm.resource.LibvirtComputingResource] (main:null) No libvirt.vif.driver specified. Defaults to BridgeVifDriver.
2016-01-19 11:19:11,995 INFO [cloud.agent.Agent] (main:null) Agent [id = 1 : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers = 5 : host = 192.168.88.4 : port = 8250
2016-01-19 11:19:12,010 INFO [utils.nio.NioClient] (Agent-Selector:null) Connecting to 192.168.88.4:8250
2016-01-19 11:19:12,086 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.Link.doHandshake(Link.java:513)
at com.cloud.utils.nio.NioClient.init(NioClient.java:81)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:113)
at java.lang.Thread.run(Thread.java:744)
2016-01-19 11:19:17,089 INFO [utils.nio.NioClient] (Agent-Selector:null) Connecting to 192.168.88.4:8250
2016-01-19 11:19:17,100 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.Link.doHandshake(Link.java:513)
at com.cloud.utils.nio.NioClient.init(NioClient.java:81)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:113)
at java.lang.Thread.run(Thread.java:744)

仔细查看一番,SSVM和CPVM中,cloud.log文件中,也为此报错,始终提示:
ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size
初步猜想管理端的8250端口异常,但经过查看,8250端口已经打开,且iptables/selinux均无异常下,遂进行如下实验:

在管理端中telnet  192.168.88.4 8250端口:
[root@mgmt ~]# telnet  localhost 8250
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[root@mgmt ~]#
看到Connection closed by foreign host.是立即返回,而不是等待输入状态。所以应该是管理端启动过程中,有地方异常了。

经过查看,发现/var/log/cloudstack/management/management-server.log 中有如下异常(目测下来,只有这一处明显报错):
2016-01-19 11:15:36,020 INFO  [c.c.s.ConfigurationServerImpl] (main:null) Processing updateSSLKeyStore
2016-01-19 11:15:36,023 INFO [c.c.s.ConfigurationServerImpl] (main:null) SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
2016-01-19 11:15:36,060 DEBUG [c.c.u.d.T.Transaction] (main:null) Rolling back the transaction: Time = 3 Name = persist; called by -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy14.persist:-1-ConfigurationServerImpl.updateSSLKeystore:641-ConfigurationServerImpl.persistDefaultValues:304-ConfigurationServerImpl.configure:166
2016-01-19 11:15:36,060 WARN [c.c.s.ConfigurationServerImpl] (main:null) Would use fail-safe keystore to continue.
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
... 120 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'ssl.keystore' for key 'PRIMARY'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
... 64 more
2016-01-19 11:15:36,136 DEBUG [c.c.u.s.Script] (main:null) Searching in environment.properties

注意最前面的报错:
找到cloudmanagementserver.keystore:
SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
此文件默认在:
/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore

再往下看:
2016-01-19 11:32:08,315 INFO  [c.c.s.ConfigurationServerImpl] (main:null) SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
2016-01-19 11:32:08,321 DEBUG [c.c.u.s.Script] (main:null) Executing: sudo keytool -genkey -keystore /etc/cloudstack/management/cloudmanagementserver.keystore -storepass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn="Cloudstack User",ou="mgmt.leaptocloud.com",o="mgmt.leaptocloud.com",c="Unknown"
2016-01-19 11:32:08,339 DEBUG [c.c.u.s.Script] (main:null) Exit value is 1
2016-01-19 11:32:08,339 DEBUG [c.c.u.s.Script] (main:null) sudo: no tty present and no askpass program specified
2016-01-19 11:32:08,340 WARN [c.c.s.ConfigurationServerImpl] (main:null) Would use fail-safe keystore to continue.
java.io.IOException: Fail to generate certificate!: sudo: no tty present and no askpass program specified
at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:606)
...
2016-01-19 11:32:08,365 INFO [c.c.s.ConfigurationServerImpl] (main:null) Processing updateKeyPairs
2016-01-19 11:32:08,365 INFO [c.c.s.ConfigurationServerImpl] (main:null) Keypairs already in database, updating local copy
2016-01-19 11:32:08,401 INFO [c.c.s.ConfigurationServerImpl] (main:null) Going to update systemvm iso with generated keypairs if needed
2016-01-19 11:32:08,401 INFO [c.c.s.ConfigurationServerImpl] (main:null) Trying to inject public and private keys into systemvm iso
2016-01-19 11:32:08,401 DEBUG [c.c.u.s.Script] (main:null) Looking for scripts/vm/systemvm/injectkeys.sh in the classpath
接下来就是生成systemvm.iso的操作了。

问题是啥,咋解决?
我也蒙逼了啊,依稀记得很早以前这个文件cloudmanagementserver.keystore是我从/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore拷贝到: 里面的,目的是为了开启https访问。PS:当时是测试,高了一半,没这个需求了。就没研究了。有鸡毛关系嘛。
然后我就抱着试试的态度,删除了/etc/cloudstack/management/cloudmanagementserver.keystore  ,再次启动管理端,然后重启kvm agent服务/CPVM/SSVM,然后,就正常了。
目前看下来是权限问题的可能性大。keytool工具执行时是使用sudo,估计对/etc/cloudstack/management/这个文件夹里面的文件没权限读。。。不过没依据。
因为我比较了下,/etc/cloudstack/management/cloudmanagementserver.keystore和/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore的md5是相同的。。。

后续:
后面研究出来了再更新。



 
继续阅读 »
测试环境:
  • CloudStack4.3.1
  • XenServer6.2SP1(1个群集,使用本地硬盘)
  • KVM(redhat6.3)

背景:
目前一生产环境在实际使用中,发现致命问题(bug/功能缺陷):
https://issues.apache.org/jira/browse/CLOUDSTACK-6004   (主要原因)
https://issues.apache.org/jira ... -6810
https://issues.apache.org/jira ... -8196
https://issues.apache.org/jira ... -5967
发现其中一个使用本地存储的XenServer群集中的虚拟机,无法在线/离线迁移(XS本身支持跨存储的迁移),此坑不多说。
反正就是要升级到4.5.2(因为这个bug在4.5.x中解决,之前版本中未找到bugfix,蛋疼的是据说4.3.0里面没这个问题)

升级过程:
不多说,ISO标准流程。
参见:
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.2/upgrade/upgrade-4.3.html
老鸟了,所以一切顺利。
管理端服务正常启动。
然后,
然后悲剧了:
SSVM+CPVM  VM state正常,为running,但Agent state不正常,为空。
KVM agent 服务可以启动,但日志中,如下报错循环抛出:
2016-01-19 11:19:11,294 INFO  [cloud.agent.AgentShell] (main:null) Agent started
2016-01-19 11:19:11,295 INFO [cloud.agent.AgentShell] (main:null) Implementation Version is 4.5.2
2016-01-19 11:19:11,297 INFO [cloud.agent.AgentShell] (main:null) agent.properties found at /etc/cloudstack/agent/agent.properties
2016-01-19 11:19:11,306 INFO [cloud.agent.AgentShell] (main:null) Defaulting to using properties file for storage
2016-01-19 11:19:11,307 INFO [cloud.agent.AgentShell] (main:null) Defaulting to the constant time backoff algorithm
2016-01-19 11:19:11,326 INFO [cloud.utils.LogUtils] (main:null) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-01-19 11:19:11,342 INFO [cloud.agent.AgentShell] (main:null) Preferring IPv4 address family for agent connection
2016-01-19 11:19:11,444 INFO [cloud.agent.Agent] (main:null) id is 1
2016-01-19 11:19:11,951 INFO [kvm.resource.LibvirtComputingResource] (main:null) No libvirt.vif.driver specified. Defaults to BridgeVifDriver.
2016-01-19 11:19:11,995 INFO [cloud.agent.Agent] (main:null) Agent [id = 1 : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers = 5 : host = 192.168.88.4 : port = 8250
2016-01-19 11:19:12,010 INFO [utils.nio.NioClient] (Agent-Selector:null) Connecting to 192.168.88.4:8250
2016-01-19 11:19:12,086 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.Link.doHandshake(Link.java:513)
at com.cloud.utils.nio.NioClient.init(NioClient.java:81)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:113)
at java.lang.Thread.run(Thread.java:744)
2016-01-19 11:19:17,089 INFO [utils.nio.NioClient] (Agent-Selector:null) Connecting to 192.168.88.4:8250
2016-01-19 11:19:17,100 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.Link.doHandshake(Link.java:513)
at com.cloud.utils.nio.NioClient.init(NioClient.java:81)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:113)
at java.lang.Thread.run(Thread.java:744)

仔细查看一番,SSVM和CPVM中,cloud.log文件中,也为此报错,始终提示:
ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: Connection closed with -1 on reading size
初步猜想管理端的8250端口异常,但经过查看,8250端口已经打开,且iptables/selinux均无异常下,遂进行如下实验:

在管理端中telnet  192.168.88.4 8250端口:
[root@mgmt ~]# telnet  localhost 8250
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[root@mgmt ~]#
看到Connection closed by foreign host.是立即返回,而不是等待输入状态。所以应该是管理端启动过程中,有地方异常了。

经过查看,发现/var/log/cloudstack/management/management-server.log 中有如下异常(目测下来,只有这一处明显报错):
2016-01-19 11:15:36,020 INFO  [c.c.s.ConfigurationServerImpl] (main:null) Processing updateSSLKeyStore
2016-01-19 11:15:36,023 INFO [c.c.s.ConfigurationServerImpl] (main:null) SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
2016-01-19 11:15:36,060 DEBUG [c.c.u.d.T.Transaction] (main:null) Rolling back the transaction: Time = 3 Name = persist; called by -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy14.persist:-1-ConfigurationServerImpl.updateSSLKeystore:641-ConfigurationServerImpl.persistDefaultValues:304-ConfigurationServerImpl.configure:166
2016-01-19 11:15:36,060 WARN [c.c.s.ConfigurationServerImpl] (main:null) Would use fail-safe keystore to continue.
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
... 120 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'ssl.keystore' for key 'PRIMARY'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
... 64 more
2016-01-19 11:15:36,136 DEBUG [c.c.u.s.Script] (main:null) Searching in environment.properties

注意最前面的报错:
找到cloudmanagementserver.keystore:
SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
此文件默认在:
/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore

再往下看:
2016-01-19 11:32:08,315 INFO  [c.c.s.ConfigurationServerImpl] (main:null) SSL keystore located at /etc/cloudstack/management/cloudmanagementserver.keystore
2016-01-19 11:32:08,321 DEBUG [c.c.u.s.Script] (main:null) Executing: sudo keytool -genkey -keystore /etc/cloudstack/management/cloudmanagementserver.keystore -storepass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn="Cloudstack User",ou="mgmt.leaptocloud.com",o="mgmt.leaptocloud.com",c="Unknown"
2016-01-19 11:32:08,339 DEBUG [c.c.u.s.Script] (main:null) Exit value is 1
2016-01-19 11:32:08,339 DEBUG [c.c.u.s.Script] (main:null) sudo: no tty present and no askpass program specified
2016-01-19 11:32:08,340 WARN [c.c.s.ConfigurationServerImpl] (main:null) Would use fail-safe keystore to continue.
java.io.IOException: Fail to generate certificate!: sudo: no tty present and no askpass program specified
at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:606)
...
2016-01-19 11:32:08,365 INFO [c.c.s.ConfigurationServerImpl] (main:null) Processing updateKeyPairs
2016-01-19 11:32:08,365 INFO [c.c.s.ConfigurationServerImpl] (main:null) Keypairs already in database, updating local copy
2016-01-19 11:32:08,401 INFO [c.c.s.ConfigurationServerImpl] (main:null) Going to update systemvm iso with generated keypairs if needed
2016-01-19 11:32:08,401 INFO [c.c.s.ConfigurationServerImpl] (main:null) Trying to inject public and private keys into systemvm iso
2016-01-19 11:32:08,401 DEBUG [c.c.u.s.Script] (main:null) Looking for scripts/vm/systemvm/injectkeys.sh in the classpath
接下来就是生成systemvm.iso的操作了。

问题是啥,咋解决?
我也蒙逼了啊,依稀记得很早以前这个文件cloudmanagementserver.keystore是我从/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore拷贝到: 里面的,目的是为了开启https访问。PS:当时是测试,高了一半,没这个需求了。就没研究了。有鸡毛关系嘛。
然后我就抱着试试的态度,删除了/etc/cloudstack/management/cloudmanagementserver.keystore  ,再次启动管理端,然后重启kvm agent服务/CPVM/SSVM,然后,就正常了。
目前看下来是权限问题的可能性大。keytool工具执行时是使用sudo,估计对/etc/cloudstack/management/这个文件夹里面的文件没权限读。。。不过没依据。
因为我比较了下,/etc/cloudstack/management/cloudmanagementserver.keystore和/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/cloudmanagementserver.keystore的md5是相同的。。。

后续:
后面研究出来了再更新。



  收起阅读 »

SSVM/CPVM虚拟机运行正常,SSVM/CPVM中agent进程未运行,agent状态为空

ISSUE:
SSVM and CPVM do not have agents running AND  SSVM health check runs fine. cloud.log on SSVM/CPVM keeps showing the following message: 
2014-06-16 08:08:01,108 INFO  [utils.nio.NioClient] (Agent-Selector:null) Connecting to 10.102.192.247:8250
2014-06-16 08:08:01,872 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.NioClient.init(NioClient.java:84)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
at java.lang.Thread.run(Thread.java:701)
Solution : -
1. rm ./client/target/cloud-client-ui-4.3.0.0/WEB-INF/classes/cloudmanagementserver.keystore ./client/target/conf/cloudmanagementserver.keystore ./client/target/generated-webapp/WEB-INF/classes/cloudmanagementserver.keystore
2. remove root entry from cloud.keystore;
3. remove ssl.keystore from cloud.configuration where description like '%key%';
4. restart MS/agent in ssvm

原文链接:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM%2C+templates%2C+Secondary+storage+troubleshooting
继续阅读 »
ISSUE:
SSVM and CPVM do not have agents running AND  SSVM health check runs fine. cloud.log on SSVM/CPVM keeps showing the following message: 
2014-06-16 08:08:01,108 INFO  [utils.nio.NioClient] (Agent-Selector:null) Connecting to 10.102.192.247:8250
2014-06-16 08:08:01,872 ERROR [utils.nio.NioConnection] (Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection closed with -1 on reading size.
at com.cloud.utils.nio.NioClient.init(NioClient.java:84)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
at java.lang.Thread.run(Thread.java:701)
Solution : -
1. rm ./client/target/cloud-client-ui-4.3.0.0/WEB-INF/classes/cloudmanagementserver.keystore ./client/target/conf/cloudmanagementserver.keystore ./client/target/generated-webapp/WEB-INF/classes/cloudmanagementserver.keystore
2. remove root entry from cloud.keystore;
3. remove ssl.keystore from cloud.configuration where description like '%key%';
4. restart MS/agent in ssvm

原文链接:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM%2C+templates%2C+Secondary+storage+troubleshooting
收起阅读 »

CloudStack 4.3 配置CPU超配

CloudStack中,可以配置内存超配参数 "cpu.overprovisioning.factor"的地方有两个,全局设置和群集设置,为何有两个地方,如何修改,看下面:
一:全局设置(创建区域前修改,创建区域后修改并不会对现有区域产生影响)。
凡是在全局设置中修改的参数,都是平台级别全局生效。一般情况下,刚安装好的CloudStack 所有参数均为默认。
如果需要进行相关调整,最好在创建区域前就做好相关参数的配置。特别是超配,等操作。
如果已经创建了区域和多个群集,再修改全局设置中的cpu超配系数,你会发现没生效。
这是因为,这对此类参数,全局设置中,提供整个默认值,供你创建区域、群集时自动从这里继承这个值。
你已经创建好的区域、群集是继承旧的值,所以修改此参数并不会对现有的区域产生任何变化。

二:基础架构-群集-设置(针对单个群集进行超配系数调整,会当前群集生效)。
所以,现在你知道为啥你在全局设置中修改不生效了吗?
当你需要进行cpu超配系数调整时,进入到某个已经存在的群集中,修改"cpu.overprovisioning.factor"参数。

所以,完事大吉了吗?
然并卵,重启完管理端服务后,你是不是发现群集的CPU总量虽然多了几倍,但已经使用的CPU容量是不是一起翻倍了?是不是跟你想象的不一样,应该总容量翻倍,已使用的至少不变,也不该也翻倍呀?
为啥?
来看看数据库:
mysql> use cloud;
Database changed
mysql> select * from user_vm_details where name="cpuOvercommitRatio";
+------+-------+--------------------+-------+---------+
| id | vm_id | name | value | display |
+------+-------+--------------------+-------+---------+
| 4362 | 529 | cpuOvercommitRatio | 2.0 | 1 |
| 4402 | 558 | cpuOvercommitRatio | 2.0 | 1 |
| 4430 | 581 | cpuOvercommitRatio | 2.0 | 1 |
| 4435 | 583 | cpuOvercommitRatio | 2.0 | 1 |
| 4437 | 584 | cpuOvercommitRatio | 2.0 | 1 |
| 4439 | 585 | cpuOvercommitRatio | 4.0 | 1 |
| 4441 | 586 | cpuOvercommitRatio | 4.0 | 1 |
| 4443 | 587 | cpuOvercommitRatio | 4.0 | 1 |
| 4445 | 588 | cpuOvercommitRatio | 3.0 | 1 |
| 4447 | 589 | cpuOvercommitRatio | 3.0 | 1 |
| 4449 | 590 | cpuOvercommitRatio | 3.0 | 1 |
| 4484 | 591 | cpuOvercommitRatio | 3.0 | 1 |
+------+-------+--------------------+-------+---------+
12 rows in set (0.00 sec)

mysql>

你会发现vm的value可能不一致,这个是啥? 这个就是针对vm生效的超配系数。当然是继承你的群集配置的超配系数。
默认应该都是2.0  , 你把每个2.0 都改为你的超配系数,保存,再看看已使用的CPU容量,是不是下降了?

看看我唠叨
在配置cloudstack的cpu超配这个参数必须得在创建vm之前改。如果创建了n多资源以后再调这个参数,会发现cpu总量和使用量都乘以设置的倍数了。
按cs的cpu资源统计逻辑,应该是只看cpu总频率(cpu个数x核数x2xCPU频率)。cpu超配的意义应该是把CPU总频率提高了n倍。
一个典型的场景是:
如果我的物理服务器cpu信息为32x2.13GHz,那么cpu总频率为68.13GHz,超陪系数为1.0时,可用cpu也为68.13,
这个时候如果我创建了10台2核,每核2000hz的vm,所使用的cpu资源为10x2x2g=40GHz,
这个时候再调整cpu超陪系数为3.0的话,实际cpu总量和使用量分别为204.48ghz,120ghz,实际上,超陪3倍以后可用cpu资源应该为68.14x3-(68.13-40)x3=80ghz。
如果在未创建vm之前,就把cpu超陪系数改为3.0,那么。情况就不同了。68.13x3-10x2x2g=160ghz。
如果已经创建了n多vm,再修改cpu超配系数,想正常使用的话,做法很简单。
将cloudstack数据库中,user_vm_details表中,所有的name字段的值为cpuOvercommitRatio 所对应的后面value得值改为超配系数然后保存即可。
然后回到cs的首页,刷新下,再看下控制版-系统容量-cpu的信息即可。

重要!
4.3版本cpu和内存超配问题,都可以使用此方法。
注意操作前做好数据库备份!!!(ps4.4未测试,4.5以上逻辑有变化,不要贸然使用该方法)。


 
继续阅读 »
CloudStack中,可以配置内存超配参数 "cpu.overprovisioning.factor"的地方有两个,全局设置和群集设置,为何有两个地方,如何修改,看下面:
一:全局设置(创建区域前修改,创建区域后修改并不会对现有区域产生影响)。
凡是在全局设置中修改的参数,都是平台级别全局生效。一般情况下,刚安装好的CloudStack 所有参数均为默认。
如果需要进行相关调整,最好在创建区域前就做好相关参数的配置。特别是超配,等操作。
如果已经创建了区域和多个群集,再修改全局设置中的cpu超配系数,你会发现没生效。
这是因为,这对此类参数,全局设置中,提供整个默认值,供你创建区域、群集时自动从这里继承这个值。
你已经创建好的区域、群集是继承旧的值,所以修改此参数并不会对现有的区域产生任何变化。

二:基础架构-群集-设置(针对单个群集进行超配系数调整,会当前群集生效)。
所以,现在你知道为啥你在全局设置中修改不生效了吗?
当你需要进行cpu超配系数调整时,进入到某个已经存在的群集中,修改"cpu.overprovisioning.factor"参数。

所以,完事大吉了吗?
然并卵,重启完管理端服务后,你是不是发现群集的CPU总量虽然多了几倍,但已经使用的CPU容量是不是一起翻倍了?是不是跟你想象的不一样,应该总容量翻倍,已使用的至少不变,也不该也翻倍呀?
为啥?
来看看数据库:
mysql> use cloud;
Database changed
mysql> select * from user_vm_details where name="cpuOvercommitRatio";
+------+-------+--------------------+-------+---------+
| id | vm_id | name | value | display |
+------+-------+--------------------+-------+---------+
| 4362 | 529 | cpuOvercommitRatio | 2.0 | 1 |
| 4402 | 558 | cpuOvercommitRatio | 2.0 | 1 |
| 4430 | 581 | cpuOvercommitRatio | 2.0 | 1 |
| 4435 | 583 | cpuOvercommitRatio | 2.0 | 1 |
| 4437 | 584 | cpuOvercommitRatio | 2.0 | 1 |
| 4439 | 585 | cpuOvercommitRatio | 4.0 | 1 |
| 4441 | 586 | cpuOvercommitRatio | 4.0 | 1 |
| 4443 | 587 | cpuOvercommitRatio | 4.0 | 1 |
| 4445 | 588 | cpuOvercommitRatio | 3.0 | 1 |
| 4447 | 589 | cpuOvercommitRatio | 3.0 | 1 |
| 4449 | 590 | cpuOvercommitRatio | 3.0 | 1 |
| 4484 | 591 | cpuOvercommitRatio | 3.0 | 1 |
+------+-------+--------------------+-------+---------+
12 rows in set (0.00 sec)

mysql>

你会发现vm的value可能不一致,这个是啥? 这个就是针对vm生效的超配系数。当然是继承你的群集配置的超配系数。
默认应该都是2.0  , 你把每个2.0 都改为你的超配系数,保存,再看看已使用的CPU容量,是不是下降了?

看看我唠叨
在配置cloudstack的cpu超配这个参数必须得在创建vm之前改。如果创建了n多资源以后再调这个参数,会发现cpu总量和使用量都乘以设置的倍数了。
按cs的cpu资源统计逻辑,应该是只看cpu总频率(cpu个数x核数x2xCPU频率)。cpu超配的意义应该是把CPU总频率提高了n倍。
一个典型的场景是:
如果我的物理服务器cpu信息为32x2.13GHz,那么cpu总频率为68.13GHz,超陪系数为1.0时,可用cpu也为68.13,
这个时候如果我创建了10台2核,每核2000hz的vm,所使用的cpu资源为10x2x2g=40GHz,
这个时候再调整cpu超陪系数为3.0的话,实际cpu总量和使用量分别为204.48ghz,120ghz,实际上,超陪3倍以后可用cpu资源应该为68.14x3-(68.13-40)x3=80ghz。
如果在未创建vm之前,就把cpu超陪系数改为3.0,那么。情况就不同了。68.13x3-10x2x2g=160ghz。
如果已经创建了n多vm,再修改cpu超配系数,想正常使用的话,做法很简单。
将cloudstack数据库中,user_vm_details表中,所有的name字段的值为cpuOvercommitRatio 所对应的后面value得值改为超配系数然后保存即可。
然后回到cs的首页,刷新下,再看下控制版-系统容量-cpu的信息即可。

重要!
4.3版本cpu和内存超配问题,都可以使用此方法。
注意操作前做好数据库备份!!!(ps4.4未测试,4.5以上逻辑有变化,不要贸然使用该方法)。


  收起阅读 »