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
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