[Gluster-devel] How to figure out the transport type of Gluster volume from VDSM host (which is not a gluster peer) ?

Deepak C Shetty deepakcs at linux.vnet.ibm.com
Mon May 6 14:33:11 UTC 2013


Hi Lists,
     I am looking at options to figure the transport type of a gluster 
volume (given the volfileserver:volname) from a host that is *not* part 
of gluster volume (aka not a gluster peer).

The context here is GlusterFS as a storage domain in oVirt/VDSM, which 
is currently available in upstream oVirt.
This features exploits the QEMU-GlusterFS native integration, where the 
VM disk is specified using gluster+<transport>://... protocol.

     For eg. if transport is TCP.. the URI looks liek gluster+tcp://..., 
otherwise gluster+rdma://...

Thus, to generate the gluster QEMU URI in VDSM, i need to know the 
Gluster volume's transport type and the only inputs that oVirt gets for 
GlusterFS storage domain are...
a) volfileserver (the host running glusterd)
b) volname (the name of the volume)

Currently i use VDSM's gluster plugin to do the eq. of "gluster volume 
info <volname>" to determine Gluster volume's transport type, but this 
won't work if the VDSM host is not a gluster peer, which is a 
constraint! ... and I would like to fix/remove this constraint.

So i discussed a bit on #glsuter-dev IRC and want to put down the 
options here for the community to help provide inputs on whats the best 
way to approach this...

1) Use gluster --remote-host=<host_running_glusterd> volume info <volname>

This is not a supported way and there is no guarantee on how long the 
--remote-host option be supported in gluster, since it has some security 
issues

2) Use gluster ::system getspec <volname>

I tried this but it never worked for me... whats the right way of using 
this ?
For me.. it just returned back to shell w/o dumping the volfile at all!

3) Have oVirt user provide the transport type as well (while creating 
Gluster storgae domain) in addition to volfileserver:volname options

This would be easiest, since VDSM can form the gluster QEMU URI by 
directly using the transport type specified by the user, and this won't 
have a need to use the vdsm-gluster plugin, hence no need for VDSM host 
to be part of gluster peer...but this would mean addnl input for user to 
provide during Gluster domain creation and oVirt UI changes to take the 
transport type as input in addition to volfileserver:volname

Comments/Opinions/Inputs appreciated

thanx,
deepak

(P.S. cross-posting this to VDSM and Gluster devel lists, as it relates 
to both)





More information about the Gluster-devel mailing list