On 07/29/2012 05:16 PM, Itamar Heim wrote:
On 07/16/2012 04:07 PM, Deepak C Shetty wrote:

I am sure VDSM hook is not the ideal way to add this functionality in
VDSM, would request inputs from experts on this list on
what would be a better way in VDSM to exploit QEMU-GlusterFS native
integration ? Ideally based on the Storage Domain type
and options used, there should be a way in VDSM to modify the libvirt
XML formed.

from your discussion with saggi, the recommended approach was a gluster storage domain.

Yes, I am working on it. The hooks approach was taken as a intermediate step just to verify if from VDSM, the libvirt/qemu side of things work fine & also to help validate the gluster block backend of qemu via VDSM ( consumability aspect).

do i understand correctly that here are two ways to consume the images via qemu: block based or file based?

From libvirt's perspective, -drive file=/rhev/data-center/.. maps to <disk> 'type = file' and -drive file=gluster:...:...:...image maps to <disk> 'type = network', so there is nothing block based here. I think the confusion might be arising due to the fact that gluster fits as a new block backend in qemu, but from a user perspective, they map to either a file based drive or network based drive, depending on how we want to use it. Under PosixFS, we would end up using file based qemu drive option, under Gluster domain (wip) I plan to add support for network based qemu drive option.

would there also be a difference in how these images are provisioned (i.e., would this imply a gluster_fs and a gluster_block storage domains, which sounds somewhat of an overkill, unless there are very good different use cases for this)?

Currently no. For both PosixFS domain and GlusterFS domain, pre-req is to have the gluster volume already setup. The input to VDSM is the gluster volfile server and image name ( and few others as being decided by the qemu / gluster community). Once the engine has support for provisioning Gluster volumes (which i feel is on the way?), the pre-req can be met from the engine UI itself.

I am currently working on creating a new GlusterFS domain in VDSM, that re-uses the PosixFS core and provides ability to exploit the network disk type option of qemu. Going ahead.. the implemention of GlusterFS domain can change/modified/improved by exploiting the vdsm gluster plugin and/or repo engines for a more native implementation, if need be.


vdsm-devel mailing list

Reply via email to