[vdsm] Using vdsm hook to exploit gluster backend of qemu

Hello,
     Recently there were patches posted in qemu-devel to support gluster 
as a block backend for qemu.

This introduced new way of specifying drive location to qemu as ...
-drive file=gluster:<volumefile>:<image name>

where...
     volumefile is the gluster volume file name ( say gluster volume is 
pre-configured on the host )
     image name is the name of the image file on the gluster mount point

I wrote a vdsm standalone script using SHAREDFS ( which maps to PosixFs 
) taking cues from http://www.ovirt.org/wiki/Vdsm_Standalone
The conndict passed to connectStorageServer is as below...
[dict(id=1, connection="kvmfs01-hs22:dpkvol", vfs_type="glusterfs", 
mnt_options="")]

Here note that 'dpkvol' is the name of the gluster volume

I and am able to create and invoke a VM backed by a image file residing 
on gluster mount.

But since this is SHAREDFS way, the qemu -drive cmdline generated via 
VDSM is ...
-drive file=/rhev/datacentre/mnt/.... -- which eventually softlinks to 
the image file on the gluster mount point.

I was looking to write a vdsm hook to be able to change the above to ....
-drive file=gluster:<volumefile>:<image name>

which means I would need access to some of the conndict params inside 
the hook, esp. the 'connection' to extract the volume name.

1) In looking at the current VDSM code, i don't see a way for the hook 
to know anything abt the storage domain setup. So the only
way is to have the user pass a custom param which provides the path to 
the volumefile & image and use it in the hook. Is there
a better way ? Can i use the vdsm gluster plugin support inside the hook 
to determine the volfile from the volname, assuming I
only take the volname as the custom param, and determine imagename from 
the existing <source file = ..> tag ( basename is the
image name). Wouldn't it be better to provide a way for hooks to access 
( readonly) storage domain parameters, so that they can
use that do implement the hook logic in a more saner way ?

2) In talking to Eduardo, it seems there are discussion going on to see 
how prepareVolumePath and prepareImage could be exploited
to fit gluster ( and in future other types) based images. I am not very 
clear on the image and volume code of vdsm, frankly its very
complex and hard to understand due to lack of comments.

I would appreciate if someone can guide me on what is the best way to 
achive my goal (-drive file=gluster:<volumefile>:<image name>)
here. Any short term solutions if not perfect solution are also 
appreciated, so that I can atleast have a working setup where I just
run my VDSM standaloen script and my qemu cmdline using gluster:... is 
generated.

Currently I am using <qemu:commandline> tag facility of libvirt to 
inject the needed qemu options and hardcoding the volname, imagename
but i would like to do this based on the conndict passed by the user 
when creating SHAREDFS domain.

thanx,
deepak