-Chris
> -----Original Message----- > From: Itamar Heim [mailto:ih...@redhat.com] > Sent: Sunday, December 23, 2012 11:58 AM > To: Shu Ming > Cc: Morrissey, Christopher; engine-de...@ovirt.org; vdsm- > de...@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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel