话说前段安装了CloudStack并使用它来管理XenServer，这回要用它来管理VMware。虽说之前遇到了大大小小的问题都攻克了，但在VMware这一块还是遇到了一些麻烦。
在创建资源域、加入集群和主机、存储后，看起来一切都好好的，可系统VM死活起不来。
看log发现诸如“InsufficientServerCapacityException”之类的，但是不知道哪些资源不够(在管理XenServer时自己创建的VM起不来，曾发现是Vlan范围没有指定)。再看看界面，二级存储显示的大小是0kb，但是在加入二级存储的时候又没有不论什么错误提示。
通过vCenter去看存储。主存储是已经挂载好了，二级存储确实没有挂载。
从log中又看到这一行“Unable to unpack /var/cloudstack/mnt/VM/178516920059281.2288ef8e/template/tmpl/1/8/routing-8.ova”，但是这个文件压根不存在。自己创建文件夹并把文件systemvm64template-4.5-vmware.ova复制过来并重命名，还是一样没不论什么效果，后来想想是不是权限问题，索性把文件夹“/var/cloudstack/mnt/VM”改为可写。这回二级存储真的正常了，系统VM也能够正常启动了。在安装CloudStack的时候，我并没有看到哪儿须要指定“/var/cloudstack/mnt/VM”这个文件夹。这算不算是CloudStack本身的问题？
系统VM起来后，其agent状态却不是up。预计是网络不通。要登录系统VM去看看网络问题，网上有说使用这个命令“VMware: ssh -i /var/cloudstack/management/.ssh/id_rsa -p 3922 root@<Private Ip address of SSVM>”这个登录。但我使用时却提示“Permission denied”。网上也有一些又一次注入密钥解决问题的介绍，但我懒得折腾。就直接从vCenter里的控制台登录进去。
首先我搜了系统VM的密码。网上好几个地方都说是*******，但我死活登不进去，结果改为"password"，忽的进去了。首先往外ping，不通后查看路由表，发现确实是路由表的问题，删掉一些项后正常了。
我想这里应该是我在指定网络信息时，对一些信息的确切含义没有特别清楚导致的，CloudStack本身不太可能出现这样的大bug。
系统VM状态正常，上传模板，可是自己创建的VM却起不来。
UI界面提示是不支持“Concurrent operation”。log则更具体一些。说是模板没有下载完毕，可是我自己注冊的模板已经下载完毕并就绪，和VMware系统模板一模一样。并在界面上把它移动到最上端，我以为这样它会优先选择我的这个模板，这样VM就能够启动了。
这里自己创建的VM起不来。首先是由于虚拟路由器起不来，虚拟路由器须要系统模板。所以系统模板下载没完毕虚拟路由器起不来，因此要解决的就是系统模板的问题。
我之前看到说虚拟路由器和系统VM使用的是同一个模板。仅仅是传入參数不同。但为什么系统VM起来后虚拟路由器却找不到模板呢？我不知道。看看界面，VMware使用的系统模板下载进度比蜗牛慢。尽管仅仅有200多M，预计没有两三天下载不完，于是想到将下载地址指定为公司内外某个URL。直接去看mysql里边的vm_template表。这个表里有个url字段。这个字段就是各个模板的下载地址，CloudStack默认都指到了“download.cloud.com”上。由于我之前已经把模板下载到本地，因此把这个url改为"localhost"，这回刷的一下下载完了，再次创建VM，启动正常，最终能够Happy一下了。