[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] storage motion question

  • To: 'Thomas Gazagnaire' <thomas@xxxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
  • Date: Mon, 25 Jun 2012 18:44:47 +0100
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Delivery-date: Mon, 25 Jun 2012 17:45:43 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: Ac1S7fSBJjbjHML6RmKprvKhUuY+iwACu9Ow
  • Thread-topic: [Xen-API] storage motion question


> With the new storage architecture, I am wondering how xapi know if a
> vdi is activated or not. Previously he was looking the the attached VBD,
> but with storage motion it appears that some VDI can be activated while
> not attached to a VM. So what is the correct way to VDI activation
> within xapi ?

There's a "high-level storage layer" (currently within xapi but it should be 
moved into a separate daemon) which tracks the state of each VDI. Check out 
this command:

[root@st30 ~]# xe host-get-sm-diagnostics 
DataPath information:
The following SRs are attached:
    SR 80577daf-9ea3-40de-80ef-d077e3962540
        VDI win7sp1-x86.iso
            activated RO (device=Some {"params": 
 "xenstore_data": {"scsi\/0x12\/0x80": "AIAAEjE3MzZhNGU4LWM1NWItNDggIA==", 
"vdi-uuid": "1736a4e8-c55b-4846-b894-e176c6523177"}})
                DP: vbd/20/hdb: activated RO
    SR bf20dbf4-2db4-4968-9d86-09aca7f8d9d4
    SR 8a0eade3-713d-e13d-641c-8cfa5ac92094
    SR 0e5b1dca-9fdc-c8ea-ffe7-9e02950e3804
    SR 1244bde2-7762-c559-0a57-701128598f3e
    SR cf0ee8a5-befb-d8d4-b0e7-614cf07f084c
        VDI win7old.1
            activated RW (device=Some {"params": 
"\/dev\/xen\/blktap-2\/tapdev0", "xenstore_data": {}})
                DP: vbd/20/hda: activated RW

With my new experimental storage backend it also displays the .vhd 
relationships in graphviz format, but I digress ;)

> (currently, it seems that all VDI operations are allowed on disks
> created by storage motion, while the migration is in progress,
> including deletion which is not good)

Hm, looking in ocaml/xapi/storage_impl.ml:

       let destroy context ~dbg ~sr ~vdi =
            info "VDI.destroy dbg:%s sr:%s vdi:%s" dbg sr vdi;
            with_vdi sr vdi
                (fun () ->
                    remove_datapaths_andthen_nolock context ~dbg ~sr ~vdi 
                        (fun () ->
                            Impl.VDI.destroy context ~dbg ~sr ~vdi

So it's currently deactivating and detaching the disk as part of the 
VDI.destroy. This could be changed, the only problem is that it *might* be 
working around leaking "attaches" or "activates". Arguably we should fix those 
resource leaks too though.


Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.