[Gluster-devel] [vdsm] How to figure out the transport type of Gluster volume from VDSM host (which is not a gluster peer) ?
Shu Ming
shuming at linux.vnet.ibm.com
Mon May 6 15:17:47 UTC 2013
2013-5-6 22:33, Deepak C Shetty:
> 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,
What do you mean by using "gluster peer"? Does "gluster peer" mean the
host is running glusterd?
> 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
What will happen if a user gives a wrong transport type to VDSM?
>
> Comments/Opinions/Inputs appreciated
>
> thanx,
> deepak
>
> (P.S. cross-posting this to VDSM and Gluster devel lists, as it
> relates to both)
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC
More information about the Gluster-devel
mailing list