[Engine-devel] FW: Querying for and registering unknown disk images on a storage domain

[Shu Ming]

2012-12-20 23:18, Morrissey, Christopher:
>
> Hi All,
>
> I've been working on a bit of functionality for the engine that will 
> allow a user to query a domain for new disk images 
> (GetUnregisteredImagesQuery) for which the engine was previously 
> unaware and a separate command to register those images 
> (ImportImageCommand). These commands will be exposed through the REST API.
>
> This functionality is needed as we are developing an extension/plugin 
> to oVirt that will allow a NetApp storage controller to handle cloning 
> the actual disks outside of oVirt and need to import them once they 
> are cloned. We'll be using other existing APIs to attach the disk to 
> the necessary VM once the disk is cloned. On the NetApp side, we'll 
> ensure the disk is coalesced before cloning so as to avoid the issues 
> of registering snapshots.
>
  I am just curious about how the third party tool like NetApp to make 
sure the disk of a running VM coalesced before cloning? By an agent in 
the VM to flush file-system cache out to the disk?

> GetUnregisteredImagesQuery will be accessible through the disks 
> resource collection on a storage domain. A "disks" resource collection 
> does not yet exist and will need to be added. To access the 
> unregistered images, a parameter (maybe "unregistered=true") would be 
> passed. So the path to "GET" the unregistered disk images on a domain 
> would be something like 
> /api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true. 
> This will return a list of disk images that can be each used as input 
> to the ImportImageCommand to get them added to oVirt.
>
> ImportImageCommand will be accessible through "POST"ing a disk to 
> /api/disks?import=true. The disk will be added to the oVirt DB based 
> on the information supplied and afterward would be available to attach 
> to a VM.
>
> When querying for unregistered disk images, the 
> GetUnregisteredImagesQuery command will use the getImagesList() VDSM 
> command. Currently this only reports the GUIDs of all disk images in a 
> domain. I had been using the getVolumesList() and getVolumeInfo() VDSM 
> commands to fill in the information so that valid disk image objects 
> could be registered in oVirt. It seems these two functions are set to 
> be removed since they are too invasive into the internal VDSM 
> workings. The VDSM team will need to either return more information 
> about each disk as part of the getImagesList() function or add a new 
> function getImageInfo() that will give the same information for a 
> given image GUID.
>

Here is the project proposal for floating disk in oVirt.  I think 
unregistered images are also floating disks.
http://www.ovirt.org/Features/DetailedFloatingDisk

> Note that much of this work had originally been submitted under patch 
> http://gerrit.ovirt.org/#/c/9603/. After several reviews it was found 
> to be lacking in its design and was using deprecated APIs that did not 
> yet have replacements. I'm reworking the code now to conform to this 
> design and asking for further input from the VDSM, core, and restapi 
> teams to ensure we can get this done quickly and correctly as it is 
> needed for the 3.2 release.
>
> -Chris
>
> *Chris Morrissey*
>
> Software Engineer
>
> NetApp Inc.
>
> 919.476.4428
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121223/5f2112a5/attachment.html>