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>

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.


vdsm-devel mailing list

Reply via email to