nova挂载cinder卷流程分析

Nova挂载cinder卷流程分析

  

1. nova通过命令nova volume-attach server volume device-name或者http请求

Req:POST /v2/{tenant-id}/servers/{server-id}/os-volume_attachments‘

Body:{‘volumeAttachment‘: {‘device‘: ‘/dev/vdb‘,

‘volumeId‘: ‘951be889-b794-4723-9ac9-efde61cacf3a‘}}‘

发起卷挂载请求。

2. nova获取可用的挂载点,若指定了挂载点则验证其有效性,没有则找出一个有效的挂载点,同时创建数据库信息,在block_device_mapping表写入一条如下信息:

   *************************** 1. row ***************************

created_at: 2014-07-07 06:24:12

updated_at: NULL

id: 6

device_name: /dev/vdb

volume_id: b5ce6d0f-e7db-41cb-a5f1-5c47454248c1

volume_size: NULL

connection_info: NULL

instance_uuid:9de3d836-be91-4348-9fc1-b67d8623157f            
       source_type: volume

destination_type: volume

   

3. nova向cinder发送请求,获取卷信息,请求和回复如下所示:

Req: GET /v1/{tenant-id}/volumes/{volume-id}

Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"

Res:

{

"volume": {

"status": "available",

"display_name": "dfg",

          "attachments": [],

          "availability_zone": "nova",

          "bootable": "false",

          "encrypted": false,

          "created_at": "2014-06-30T08:33:47.000000",

          "os-vol-tenant-attr:tenant_id":  "xxx-tenant-id",

          "display_description": null,

          "os-vol-host-attr:host": "xfolsom",

          "volume_type": "None",

          "snapshot_id": null,

          "source_volid": null,

          "os-vol-mig-status-attr:name_id": null,

          "metadata": {

              "readonly": "False"

          },

          "id": "951be889-b794-4723-9ac9-efde61cacf3a",

          "os-vol-mig-status-attr:migstat": null,

          "size": 1

         }

}

4.nova检查卷的状态,若volume[‘status‘]!=‘available‘,抛出400异常,异常信息为:status must be ‘available‘,一个典型的错误信息如下:

ERROR (BadRequest): Invalid volume: status must be ‘available‘ (HTTP 400)

   若volume[‘status‘]==‘attached‘,抛出ERROR (BadRequest): Invalid volume: already attached (HTTP 400)

   

5. 向cinder发送请求,保留这个盘,避免被别人使用,请求和回复如下:

Req:POST  v1/{tenant-id}/volumes/{volume-id}/action

        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"

        Body:{"os-reserve": null}

   Res:Http 202

Cinder收到请求后,若volume[‘status‘]==‘available‘,则将状态改为volume[‘status‘]==‘attaching’,否则抛出400异常。

6. nova获取connector,得到connector信息如下所示:

   {‘ip‘: ‘10.160.162.24‘, ‘host‘: ‘nvs-1‘, ‘initiator‘: ‘iqn.1993-08.org.debian:01:35725f2f2a‘}

   其中initiator为/etc/iscsi/initiatorname.iscsi文件内容。

7. 将上一步得到的connector和volume-id发送给cinder,初始化连接接口,获取iscsi的connection_info,cinder返回connection_info,其请求和回复信息如下所示:

Req:POST  v1/{tenant-id}/volumes/{volume-id}/action

        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"

        Body:

        {

         "os-initialize_connection": {

           "connector": {

               "ip": "10.160.161.32",

               "host": "xfolsom",

               "initiator": "iqn.1993-08.org.debian:01:11a1a0aa28f1"

           }

          }

}

Res:

{u‘data‘: {u‘access_mode‘: u‘rw‘,

u‘auth_method‘: u‘CHAP‘,

u‘auth_password‘: u‘jVu68HfYhUBtAQ5vQGpq‘,

u‘auth_username‘: u‘pg9Zc8o7JiCpjf6LHh9C‘,

u‘encrypted‘: False,

u‘qos_specs‘: None,

u‘target_discovered‘: False,

u‘target_iqn‘:      u‘iqn.2010-10.org.openstack:volume-b5ce6d0f-a5f1-5c47454248c1‘,

u‘target_lun‘: 1,

u‘target_portal‘: u‘10.160.162.24:3260‘,

u‘volume_id‘: u‘b5ce6d0f-e7db-41cb-a5f1-5c47454248c1‘},

u‘driver_volume_type‘: u‘iscsi‘}

8. 若第6、7步有异常(不区分异常种类,所有异常都一样),则给cinder发送unreserve请求,修改卷的状态,请求和回复如下:

Req:POST  v1/{tenant-id}/volumes/{volume-id}/action

        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"

        Body:{"os-unreserve": null}

   Res:Http 202

   Cinder这边做如下处理:若volume[‘status‘] == "attaching",则将其状态改为‘available’,同时nova这边会删除block_device_mapping表对应的数据库行,终止卷挂载行为。

   

9. nova调用驱动挂载卷到宿主机上,nova默认是调用LibvirtISCSIVolumeDriver驱动的connect_volume方法, 该方法用libvirt执行一些相关的iscsi命令挂载云硬盘到宿主机上,然后调用libvirt将该卷挂载到虚拟机上去,若在挂载卷到虚拟机过程中出现异常,则将前面卷挂载到宿主机这一步操作撤销,执行的是LibvirtISCSIVolumeDriver驱动的disconnect_volume方法。至此,挂载过程完成。

10. 给cinder发送请求挂载信息,通知cinder此卷已经完成宿主机虚拟机挂载过程:

   Req:POST  v1/{tenant-id}/volumes/{volume-id}/action

   Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"

   Body:

        {

           "os-attach": {

           "instance_uuid": "5f1c49d6-f3ec-4564-9b9a-f6b3dc938dd2",

           "mountpoint": "/dev/vdb",

           "mode": "rw"

              }

         }

   Res:Http 202

   Cinder收到请求后,进行挂载。从cinder的代码上看,并未做什么操作,只是将信息更新到数据库而已,将卷的状态改为in-use。

   

11. nova更新数据库,主要把connection_info信息更新进去。更新后的数据库如下所示:

   *************************** 1. row ***************************

created_at: 2014-07-07 06:24:12

updated_at: 2014-07-07 07:03:28

deleted_at: NULL

id: 6

device_name: /dev/vdb

delete_on_termination: 0

snapshot_id: NULL

volume_id: b5ce6d0f-e7db-41cb-a5f1-5c47454248c1

volume_size: NULL

no_device: NULL

connection_info: {"driver_volume_type": "iscsi", "serial": "b5ce6d0f-e7db-41cb-a5f1-5c47454248c1", "data": {"access_mode": "rw", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-b5ce6d0f-e7db-41cb-a5f1-5c47454248c1",
"target_portal": "10.160.162.24:3260", "volume_id": "b5ce6d0f-e7db-41cb-a5f1-5c47454248c1", "target_lun": 1, "device_path": "/dev/disk/by-path/ip-10.160.162.24:3260-iscsi-iqn.2010-10.org.openstack:volume-b5ce6d0f-e7db-41cb-a5f1-5c47454248c1-lun-1", "auth_password":
"jVu68HfYhUBtAQ5vQGpq", "auth_username": "pg9Zc8o7JiCpjf6LHh9C", "auth_method": "CHAP"}}

instance_uuid: 9de3d836-be91-4348-9fc1-b67d8623157f

deleted: 0

source_type: volume

destination_type: volume

   

   

nova挂载cinder卷流程分析,布布扣,bubuko.com

时间: 2024-12-28 23:15:20

nova挂载cinder卷流程分析的相关文章

Openstack之Nova创建虚机流程分析

前言  Openstack作为一个虚拟机管理平台,核心功能自然是虚拟机的生命周期的管理,而负责虚机管理的模块就是Nova. 本文就是openstack中Nova模块的分析,所以本文重点是以下三点: 先了解Openstack的整体架构,搞清楚为什么要用这样的架构: 然后再了解架构中的各个组件,组件提供的主要功能与各个组件之间的交互: 了解虚机的启动过程,能在遇到问题时发现问题出在哪个模块中的哪个组件. Nova组件介绍 接下来进行详细介绍,如有错误,欢迎拍砖! 下图为创建虚拟机的一个大概流程图.

nova boot代码流程分析(三):nova与neutron的交互(2)

继续<nova boot代码流程分析(三):nova与neutron的交互(1)>的分析. #/nova/virt/libvirt/driver.py:LibvirtDriver # NOTE(ilyaalekseyev): Implementation like in multinics # for xenapi(tr3buchet) def spawn(self, context, instance, image_meta, injected_files, admin_password,

nova boot代码流程分析(五):VM启动从neutron-dhcp-agent获取IP与MAC

1.   network和subnet创建代码流程 [[email protected] ~(keystone_user1)]# neutron net-create demo-net [[email protected] ~(keystone_user1)]# neutron subnet-create  demo-net 1.1.1.0/24 --name demo-subnet --gateway 1.1.1.1 --enable_dhcp true 这里,我们主要分析上面两个命令的代码流

Linux系统启动流程分析与关机流程

Linux 系统启动流程分析 Linux系统的启动过程并不是大家想象中的那么复杂,其过程可以分为5个阶段: 内核的引导. 运行 init. 系统初始化. 建立终端. 用户登录系统. init程序的类型: SysV: init, CentOS 5之前, 配置文件: /etc/inittab. Upstart: init,CentOS 6, 配置文件: /etc/inittab, /etc/init/*.conf. Systemd: systemd, CentOS 7,配置文件: /usr/lib/

ubuntu upstart启动流程分析

ubuntu自从6.10版本之后就使用了较新的upstart机制来进行系统的初始化. upstart是一种基于事件驱动的服务启动机制,可以使多个系统任务在保持依赖关系的前提下并发启动(据说这样这样启动会比较快,理论上应当如此).使用upstart机制时,我们通过/etc/init下的一系列 *.conf 配置文件来指定各种系统服务的依赖关系(启动时机).系统启动时,upstart主进程/sbin/init会解析这些配置文件,按照指定的依赖关系并发启动各种服务与应用. 主要程序 upstart有三

Android启动流程分析(一)

############################################# 本文为极度寒冰原创,转载请注明出处 ############################################# Android的启动流程绝大部分人都知道,但是大多数人都是这样描述的: Android启动,首先是启动Bootloader,然后挂载kernel,挂载完kernel之后,会启动android的init进程,init进程会去孵化Zygote,Zygote是android的重要支柱之

openstack之nova-api服务流程分析

nova-api发布api服务没有用到一个些框架,基本都是从头写的.在不了解它时,以为它非常复杂,难以掌握.花了两三天的时间把它分析一遍后,发现它本身的结构比较简单,主要难点在于对它所使用的一些类库不了解,如paste.deploy/webob/routes.对于paste.deploy,结合它的官网文档把它的源码看了两遍.webob看的是源码.routes看的是文档.对于这些类库提供的函数,如果从文档中去理解他们想要做什么,真不是件容易的事.查看其实现源码,就明了了.不过在分析源码过程中,碰到

thttpd和cgilua安装与运行流程分析

安装 参考如下博文安装thttpd软件 http://blog.csdn.net/21aspnet/article/details/7045845 http://blog.csdn.net/dragoncheng/article/details/5614559 thttpd配置文件: [email protected]:/usr/local/bin# cat /usr/local/thttpd/conf/ etc/  logs/ man/  sbin/ www/  [email protecte

u-boot启动流程分析(2)_板级(board)部分

转自:http://www.wowotech.net/u-boot/boot_flow_2.html 目录: 1. 前言 2. Generic Board 3. _main 4. global data介绍以及背后的思考 5. 前置的板级初始化操作 6. u-boot的relocation 7. 后置的板级初始化操作 1. 前言 书接上文(u-boot启动流程分析(1)_平台相关部分),本文介绍u-boot启动流程中和具体版型(board)有关的部分,也即board_init_f/board_i