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
> 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
> 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.
floating disks are disks the engine is aware of, but not associated to
the scan domain feature is to add "orphan" disks - disks on the storage
the engine isn't aware of to begin with.