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

[Morrissey, Christopher]

-Chris


> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Sunday, December 23, 2012 11:58 AM
> To: Shu Ming
> Cc: Morrissey, Christopher; engine-devel at ovirt.org; vdsm-
> devel at lists.fedorahosted.org
> Subject: Re: [vdsm] [Engine-devel] FW: Querying for and registering
> unknown disk images on a storage domain
> 
> On 12/23/2012 04:00 PM, Shu Ming wrote:
> > 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?
> 
> I'd expect either a livesnapshot before, or doing this on a VM which is down.
>

Yes, we were planning on only allowing this type of operation on a VM which has been stopped and if it is not a template, we would create a template in the background which would ensure the disk is coalesced. All of this being done through the REST API which from what I can tell is currently possible.
 
> >
> >> 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
> 
> floating disks are disks the engine is aware of, but not associated to any VM.
> the scan domain feature is to add "orphan" disks - disks on the storage the
> engine isn't aware of to begin with.