From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sn1C4-0007Q3-M8 for qemu-devel@nongnu.org; Fri, 06 Jul 2012 01:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sn1C2-0000BT-R6 for qemu-devel@nongnu.org; Fri, 06 Jul 2012 01:35:04 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:50803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sn1C2-00006c-6x for qemu-devel@nongnu.org; Fri, 06 Jul 2012 01:35:02 -0400 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 6 Jul 2012 11:04:52 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q665YmdJ14746056 for ; Fri, 6 Jul 2012 11:04:49 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q66B5SBm032367 for ; Fri, 6 Jul 2012 21:05:28 +1000 Date: Fri, 6 Jul 2012 11:05:53 +0530 From: Bharata B Rao Message-ID: <20120706053553.GA31524@in.ibm.com> References: <20120611141806.GA2737@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120611141806.GA2737@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH 0/3] GlusterFS support in QEMU Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Anand Avati , Amar Tumballi , Vijay Bellur On Mon, Jun 11, 2012 at 07:48:07PM +0530, Bharata B Rao wrote: > > # qemu-system-x86_64 --enable-kvm --nographic -smp 4 -m 1024 -drive file=gluster:c-qemu.vol:/F16,format=gluster > If you notice above, I am directly feeding the gluster volume file to QEMU. During my discussions with GlusterFS developers, I realized that it is more relevant to use volume name than volume file directly. Hence I am proposing that QEMU should have the gluster specifications like this: -drive file=gluster:volfileserver:volumename:imagename Note that volfile server and volume name combination is the standard way of specifying a volume in gluster world. QEMU would pass volfileserver:volumename to libglusterfsclient which will contact the server and fetch the right client volume file to use. This specification change has two side effects: 1. It limits the QEMU user to pick volfiles that are generated only by gluster CLI. This should be fine as long as gluster CLI provides the capability to generate or regenerate volume files for a given volume with the xlator set that QEMU user is interested in. GlusterFS developers tell me that this can be provided with some enhancements to glusterCLI/glusterd. Note that custom volume files could be typically needed when GlusterFS server is co-located with QEMU in which case you would like to get rid of client-server overhead and RPC communication overhead. 2. As of now, the specification of volfileserver:volumename picks the default client volume file for the given volume name. Since we want to have the flexibility to pick the volfile of our choice, we could slightly extend the specification like this: volfileserver:volumename.custom that would instruct gluster to pick a custom volume file. Eg. volfileserver:myvol.rpcbypass would pick myvol.rpcbypass.vol volume file for the volume myvol. Here also, the creation of custom volume file is done by gluster CLI, so that gluster is in a position to pick the right volume file. As per my current understanding, such custom volfile extensions works with gluster. Request QEMU developers to comment on the new specification and point out any use cases that wouldn't be possible or would be hindered by this volfileserver:volumename specification. I also request the GlusterFS developers (on CC) to validate my understanding of gluster here and let me know if the proposed enhancements to glusterCLI/glusterd are indeed feasible. Regards, Bharata.