 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
用 CloudStack 配置和管理一个简单云
下载积分：1000
内容提示：用 CloudStack 配置和管理一个简单云
文档格式：DOC|
浏览次数：11|
上传日期： 03:58:55|
文档星级：
该用户还上传了这些文档
用 CloudStack 配置和管理一个简单云
官方公共微信查看: 1804|回复: 0
CloudStack VMware遇到的问题及解决问题的过程
主题帖子积分
高级会员, 积分 1829, 距离下一级还需 3171 积分
高级会员, 积分 1829, 距离下一级还需 3171 积分
话说前段安装了CloudStack并使用它来管理XenServer，这回要用它来管理VMware。虽说之前遇到了大大小小的问题都解决了，但在VMware这一块还是遇到了一些麻烦。
在创建资源域、添加集群和主机、存储后，看起来一切都好好的，可系统VM死活起不来。看log发现诸如“InsuffientCapacity”之类的，可是不知道哪些资源不够(在管理XenServer时自己创建的VM起不来，曾发现是Vlan范围没有指定)。再看看界面，二级存储显示的大小是0kb，但是在添加二级存储的时候又没有任何错误提示。通过vCenter去看存储，主存储是已经挂载好了，二级存储确实没有挂载。从log中又看到这一行“Unable to unpack /var/cloudstack/mnt/VM/281.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默认都指到了“”上。因为我之前已经把模板下载到本地，因此把这个url改为&localhost&，这回刷的一下下载完了，再次创建VM，启动正常，终于可以Happy一下了。
站长推荐 /6
about云|新出视频，openstack零基础入门，解决你ping不通外网难题
云计算hadoop视频大全(新增 yarn、flume|storm、hadoop一套视频
视频资料大优惠
大数据零基础由入门到实战
阶段1：hadoop零基础入门基础篇
阶段2：hadoop2入门
阶段3：大数据非hadoop系列课程
阶段4：项目实战篇
阶段5：大数据高级系列应用课程
阶段6：工作实用系列教程
等待验证会员请验证邮箱
新手获取积分方法
Powered by更改CloudStack中KVM平台的Windows虚拟机默认磁盘类型为VirtIO
前言本文的目的是为了解决在使用CloudStack（CloudPlatform）时，基于KVM虚拟化平台，Windows虚拟机的性能低下的问题。此性能，主要指磁盘IO和网卡性能。相关文
%28PV%29%E8%99%9A%E6%8B%9F%E5%8C%96另外，关于virtio，可以查看如下链接：& & （这个值得不懂kvm的兄弟一看）由上面的信息得知：启用了PV模式的操作系统，根磁盘，也就是系统磁盘，默认会使用VirtIO模式，而没用启用PV模式的操作系统，将会默认使用IDE模式。细心的你也会发现，上面的列表中，几乎全部是Linux系统，除了"Other PV"这个怪胎（其实还有"Windows PV"啦，至于为啥，也许是写文档的人懒，也许是，，稍后再说）。为啥几乎都是Linux系统，官方说了这样一句话：（仅KVM）All VMs are required to support the virtio drivers. These drivers are installed in all Linux kernel versions 2.6.25 and greater. The administrator must set CONFIG_VIRTIO_BALLOON=y in the virtio configuration.所有的虚拟机都要求支持virtio驱动，而Linux平台的virtio驱动已经集成到2.6.25或更高版本的内核中。也就是说Linux可以直接识别virtio接口设备。而virtio是一个在hypervisor之上的抽象API接口，是一个半虚拟化驱动，virtio与hypervisor协作工作，用于提供出色的性能。也就是说，virtio不是标准接口类型。你买硬盘的时候有看到过virtio硬盘嘛。所以，Windows中不集成此驱动，也在情理之中。这也是为啥没有启用PV模式的虚拟机的系统磁盘接口类型为IDE。那是不是Windows就不能使用VirtIO了？当然不是。人家说了嘛，只要启用了PV模式的操作系统，系统磁盘就会是VirtIO。所以CS中提供了2中PV模式的操作系统类型Other PV 和 Windows PV。 其实只有Other PV这一种。因为代码中，Windows PV最终也是归类为Other PV。当然了，Windows 系统中的VirtIO驱动，就需要自己安装了。初步解决到这里，问题初步已经可以解决了，就是在CS中，将Windows相关的虚拟机和模版中的操作系统类型，定义为：Windows PV或Other PV。只要选择了PV模式的操作系统类型，系统磁盘类型即可使用VirtIO。如果这样你以为就该高兴了，那我就要呵呵了。本着 no zuo no die , why you try的原则，我还是要找到根本解决方法。深入分析首先想想为啥CS中定义了启用PV和不启用PV模式的操作系统，为啥CS中基于KVM平台的windows虚拟机系统磁盘不直接使用virtio接口类型。而除系统磁盘以外的第二块，第三块磁盘却使用virtio接口类型？难道CS的开发人员不知道这样性能会有质的提升吗？我认为：1.启用PV和不启用PV，在CS代码层面，最根本要解决的还是区分根磁盘接口类型使用IDE或VirtIO（针对KVM平台）2.KVM平台中windows虚拟机系统磁盘不直接使用virtio接口而是使用IDE，实际上是为了方便使用CS部署KVM虚拟机的人员。为啥，如果windows虚拟机默认也使用virtio接口类型的磁盘驱动器，那你会碰到什么问题？你会发现虚拟机启动失败。或者当你在从ISO安装一台windows虚拟机时发现到磁盘驱动器那一步，windows找不到磁盘驱动器。这个时候你会怎么办？安装 vista,win7,2008.win8 等高版本windows时，在硬盘驱动器那一步骤中，允许你通过ISO加载驱动器驱动。确实也提供了virtio的iso格式驱动安装包，这个时候你可以弹出安装iso，然后附加virtio的驱动iso，安装完驱动以后再弹出该iso，再次附件系统iso。好了，系统可以识别到磁盘驱动器了。那2003呢，xp呢，必须要插入软盘安装驱动，你咋办？CS提供软驱了不？3.系统盘为IDE接口，其他盘均为virtio，如上面所说。先保证你可以把系统安装好，再来装virtio驱动。不管xp，2003，还是win7，2008，windows系统都能识别到IDE接口的硬盘吧，等你安装好系统，再为数据盘安装virtio驱动。4.开发人员正是基于如上考虑，才这么设计的吧。当然你可以在安装完virtio的磁盘和网卡驱动后，关机，把虚拟机操作系统类型改为Windows PV模式，再开机，那虚拟机就会使用virtio作为系统磁盘接口类型。或者你可以把安装好virtio驱动的虚拟机转化为模版，并设置操作系统类型为windows pv,那么以后使用该模版创建的虚拟机，都不用再担心驱动问题。5.当然，如果你在CS之外，已经做好了KVM平台的windows虚拟机模版，并直接加入了virtio的驱动，然后导入CS。然后这个模版的操作系统类型，你也需要设置为Windows PV模式。但，我目前所在的项目中，不太方便使用将虚拟机或模版的操作系统类型修改为Windows PV的方式。一来虚拟机多了，统计不方便，所有的windows虚拟机都是windows pv模式。。。二来，本着打破沙锅的精神，从代码层面，直接找到根源，并修改之。这样就不用设置烦人的Windows PV了。当然，前提是，我的模版中，已经加入了VirtIO的所有驱动（磁盘驱动器+网卡）解析代码：在CS官方的github&/apache/cloudstack搜索如下关键字： vritio，windows pv，other pv，ide 等等，自由发挥。经过一番研究，找到如下两个文件：/apache/cloudstack/blob/afc188cb5c72e529e8692ddcb94b/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java/apache/cloudstack/blob/7542ffc4fdb586ceae3c02/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java1.首先来看KVMGuestOsMapper.java ， 定义了kvm平台中，支持的操作系统列表：public&class&KVMGuestOsMapper&{
&&&&private&static&final&Logger&s_logger&=&Logger.getLogger(KVMGuestOsMapper.class);
&&&&private&static&Map&String,&String&&s_mapper&=&new&HashMap&String,&String&();
&&&&static&{
&&&&&&&......
&&&&&&&&s_mapper.put("Windows&Server&2008&(64-bit)",&"Windows&Server&2008");
&&&&&&&&s_mapper.put("Windows&Server&-bit)",&"Windows&Server&2008");
&&&&&&&&s_mapper.put("Windows&XP&(64-bit)",&"Windows&XP");
&&&&&&&&s_mapper.put("Windows&NT&4",&"Windows&NT");
&&&&&&&&s_mapper.put("Windows&3.1",&"Windows&3.1");
&&&&&&&&s_mapper.put("Windows&PV",&"Other&PV");
&&&&&&&&s_mapper.put("FreeBSD&10&(32-bit)",&"FreeBSD&10");
&&&&&&&&s_mapper.put("FreeBSD&10&(64-bits",&"FreeBSD&10");
&&&&&&&&s_mapper.put("Other&PV&(32-bit)",&"Other&PV");
&&&&&&&&s_mapper.put("Other&PV&(64-bit)",&"Other&PV");
&&&&&&&......
&&&&}可以看到，此表为操作系统类型对应关系，s_mapper.put中，有两个字段： s_mapper.put(操作系统版本，操作系统类型);&一个操作系统类型中，包括多个操作系统版本，注意我们说过的Windows PV，也被归类为Other PV。2.再来查看LibvirtComputingResource.java文件。查找virtio看到如下信息：
你最喜欢的