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

-----Original Message----- From: Itamar Heim [mailto:iheim@redhat.com] Sent: Sunday, December 23, 2012 11:58 AM To: Shu Ming Cc: Morrissey, Christopher; engine-devel(a)ovirt.org; vdsm- devel(a)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.

> >> 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.