Openstack中虚拟机的Resize功能详解

本文详细介绍了在Openstack中如何使用Resize功能扩展虚拟机资源,包括在单节点和多节点环境下的操作步骤,以及遇到的问题和解决方法。主要内容涉及源码分析、磁盘格式转换、网络配置调整等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文由guwenwu写于2012年08月11日,转载请注明出处,谢谢!

   摘要:在Openstack中生成VM后,由于业务的变更或业务量的增加,需要对VM进行扩展。目前Openstack中提供了Resize功能,本文对Openstack中的源码进行了测试和分析,并进行了一定的修改。

环境:2台Centos6.2机器
          HOSTA:10.28.170.93   8core 16G 实体机 安装和运行全部Openstack组件
          HOSTB:10.28.168.55   4core 4G   虚拟机 安装和运行nova-compute nova-network

一.Openstack中Resize功能源码分析
    Openstack的resize功能默认的操作是在两台HOST(宿主机)之间进行静态的迁移(VM会重启,内存状态无法保存),但是通过修改配置文件,可以允许Openstack在一台HOST上进行RESIZE而不用迁移。
    Resize的过程中,vm主要经过以下几个方法的处理:
    def prep_resize(self, context, instance_uuid, instance_type_id, image,
                    **kwargs):
    def prep_resize(self, context, instance_uuid, instance_type_id, image,
                    **kwargs):
    def finish_resize(self, context, instance_uuid, migration_id, disk_info,
                      image):
   详细的代码就不一一例举了,有兴趣的朋友可以自行阅读源码。
   主要的操作步骤如下:
    1.检查VM虚拟磁盘格式是否为qcow2,如果是的话,将磁盘格式转换为RAW
        qemu-img convert -f qcow2 -O raw 
    2.将虚拟磁盘从HOST A scp到HOST B上
    3.用以下命令对虚拟磁盘大小进行重置
    qemu-img resize
    e2fsck -fp
    resize2fs
     4.如果use_cow_images设置为true,则将磁盘重新转为qcow2格式。
     5.重新获取网络配置,在HOST B上设置DHCP绑定和Iptables规则。
     6.修改XML文件,重新启动虚拟机。
  OK啦,整个Resize的工作就完成了。下面重点讲一下实际操作中遇到的问题和BUG

二.在一个单节点中进行resize

同一机器中进行resize需要在配置文件nova.conf中添加:
--allow_resize_to_same_host=True
重启服务:
service nova-api restart
service nova-compute restart

三.在多个节点上进行resize
3.1.采用共享存储
    从源码上来看, Openstack中resize这个功能并没有考虑使用共享存储的情况。因此需要对源码进行一些改造,并不复杂,在这里就不交代了,有兴趣的朋友可以留言。PS:测试多节点时请注释掉--allow_resize_to_same_host=True
3.1.1.在HOST A上安装配置NFS服务器
(1)检查是否安装nfs(Centos6.2默认是安装好了的)
        rpm -qa|grep nfs    
       如未安装:
<think>好的,我需要详细解释OpenStack虚拟机创建的流程。首先,用户的问题是关于流程的详细步骤,所以我需要结合之前提供的引用内容来组织回答。根据引用2和引用5,流程大致分为几个阶段:身份验证、调度、资源准备、网络配置和虚拟机实例化。首先,用户发起请求,这涉及到nova-api接收请求。然后,Keystone进行身份验证,确保用户有权限。接着,nova-scheduler会选择合适的计算节点。这部分需要详细说明调度过程,可能涉及过滤和权重计算,不过引用中没有提到具体调度算法,可能需要保持一般性描述。 然后是nova-compute的工作,包括与Glance获取镜像,Neutron分配网络,Cinder提供存储(如果有的话)。这里要强调各组件之间的协作,比如通过消息队列通信,以及各服务如何通过Keystone验证。引用4和引用5提到nova-conductor的作用,用来安全访问数据库,需要解释这一点。最后是虚拟机实例化的具体步骤,比如调用libvirt创建虚拟机,并更新数据库状态。同时,整个流程中数据库记录的状态变化也很重要,比如初始状态到运行中的转变。 需要确保回答结构清晰,分步骤说明,并正确引用相关的引用编号。同时,要检查是否有遗漏的步骤,比如安全组配置、密钥对注入等,这些在引用3中提到过,需要包含在内。 另外,用户可能对各个组件之间的交互感兴趣,例如nova-api如何与数据库通信,nova-scheduler如何选择节点,以及消息队列的作用。引用5详细说明了消息队列作为交通枢纽的重要性,这点要突出。 最后,生成相关问题时要考虑用户可能进一步想知道的内容,比如如何优化流程、常见错误排查,或者各个组件的详细功能。确保问题与创建流程相关,并引导用户深入理解。</think>### OpenStack虚拟机创建详细流程 OpenStack虚拟机创建是一个涉及多个组件协同工作的复杂过程,主要分为以下几个阶段: #### 一、用户请求与身份验证 1. **用户发起请求**:通过命令行或Dashboard向`nova-api`发送创建虚拟机请求,包含镜像、规格(flavor)、网络等参数[^3][^5]。 2. **Keystone认证**: - 用户首先需提供用户名和密码获取临时令牌(token)[^5]。 - `nova-api`携带该令牌向Keystone验证权限,确保用户有权执行操作[^2][^5]。 #### 二、调度与资源分配 3. **数据库记录初始化**: - `nova-api`将虚拟机元数据写入数据库(如MySQL),并生成初始记录[^4][^5]。 4. **调度器选择计算节点**: - `nova-scheduler`通过消息队列接收请求,根据资源可用性(CPU、内存等)和策略选择最优的`nova-compute`节点[^2][^5]。 #### 三、资源准备与组件协作 5. **镜像获取**: - `nova-compute`从Glance下载指定镜像,期间需通过Keystone验证镜像访问权限[^5]。 6. **网络配置**: - 调用Neutron分配IP并配置虚拟网络(如创建端口、绑定安全组),Neutron同样需验证Token[^3][^5]。 7. **存储资源分配**(可选): - 若需云硬盘,`nova-compute`会请求Cinder创建并挂载卷,Cinder需通过Keystone认证[^5]。 #### 四、虚拟机实例化 8. **底层虚拟化调用**: - `nova-compute`通过Libvirt(默认使用KVM)创建虚拟机实例,加载镜像并配置虚拟硬件[^5]。 9. **状态同步与更新**: - `nova-conductor`持续更新数据库中的虚拟机状态(如“构建中”→“运行中”)[^5]。 10. **网络连通性检查**: - Neutron确保虚拟机获得IP并可通过网络访问[^3]。 #### 五、流程完成 11. **用户接收结果**: - 创建成功后,用户可通过Dashboard或命令行访问虚拟机[^1]。 ```plaintext 流程图简化为: 用户 → nova-api → Keystone认证 → 调度 → nova-compute → 资源协调 → 实例化 → 状态更新 → 完成 ``` ###
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值