From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: [PATCH v2 2/2] rbd: allow configuration of rados from the rbd filename Date: Fri, 8 Apr 2011 10:07:10 +0900 Message-ID: References: <6f9466b6098b5159aca9c789f9fce45f409e684f.1301354138.git.josh.durgin@dreamhost.com> <99252a76de350c8123eebfe4fc01fc6a1c9b2383.1301354138.git.josh.durgin@dreamhost.com> <20110407084707.GA21871@stefanha-thinkpad.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: kvm-owner@vger.kernel.org To: Yehuda Sadeh Weinraub Cc: Stefan Hajnoczi , Josh Durgin , kvm@vger.kernel.org, qemu-devel@nongnu.org, ceph-devel@vger.kernel.org List-Id: ceph-devel.vger.kernel.org 2011/4/8 Yehuda Sadeh Weinraub : > On Thu, Apr 7, 2011 at 2:54 AM, Yoshiaki Tamura > wrote: >> 2011/4/7 Stefan Hajnoczi : >>> On Thu, Apr 07, 2011 at 10:14:03AM +0900, Yoshiaki Tamura wrote: >>>> 2011/3/29 Josh Durgin : >>>> > The new format is rbd:pool/image[@snapshot][:option1=3Dvalue1[:o= ption2=3Dvalue2...]] >>>> > Each option is used to configure rados, and may be any Ceph opti= on, or "conf". >>>> > The "conf" option specifies a Ceph configuration file to read. >>>> > >>>> > This allows rbd volumes from more than one Ceph cluster to be us= ed by >>>> > specifying different monitor addresses, as well as having differ= ent >>>> > logging levels or locations for different volumes. >>>> > >>>> > Signed-off-by: Josh Durgin >>>> > --- >>>> > =A0block/rbd.c | =A0119 ++++++++++++++++++++++++++++++++++++++++= ++++++++++-------- >>>> > =A01 files changed, 102 insertions(+), 17 deletions(-) >>>> > >>>> > diff --git a/block/rbd.c b/block/rbd.c >>>> > index cb76dd3..bc3323d 100644 >>>> > --- a/block/rbd.c >>>> > +++ b/block/rbd.c >>>> > @@ -22,13 +22,17 @@ >>>> > =A0/* >>>> > =A0* When specifying the image filename use: >>>> > =A0* >>>> > - * rbd:poolname/devicename >>>> > + * rbd:poolname/devicename[@snapshotname][:option1=3Dvalue1[:op= tion2=3Dvalue2...]] >>>> >>>> I'm not sure IIUC, but currently this @snapshotname seems to be >>>> meaningless; it doesn't allow you to boot from a snapshot because = it's >>>> read only. =A0Am I misunderstanding or tested incorrectly? >>> >>> Read-only block devices are supported by QEMU and can be useful. >> >> I agree. =A0My expectation was that @snapshotname is introduced to h= ave >> writable snapshot. >> > The RADOS backend doesn't support writable snapshots. However, down > the rbd roadmap we plan to have layering which in a sense is writable > snapshots. The whole shift to librbd was done so that introducing suc= h > new functionality will be transparent and will not require much or an= y > changes in the qemu code. Thanks. It made things clear :) I think it's a good move. Yoshi > > Yehuda > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36775 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q80AL-00039d-G3 for qemu-devel@nongnu.org; Thu, 07 Apr 2011 21:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q80AK-0005Tn-BK for qemu-devel@nongnu.org; Thu, 07 Apr 2011 21:07:13 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:57216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q80AJ-0005Th-Fm for qemu-devel@nongnu.org; Thu, 07 Apr 2011 21:07:12 -0400 Received: by wwi18 with SMTP id 18so34834wwi.4 for ; Thu, 07 Apr 2011 18:07:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <6f9466b6098b5159aca9c789f9fce45f409e684f.1301354138.git.josh.durgin@dreamhost.com> <99252a76de350c8123eebfe4fc01fc6a1c9b2383.1301354138.git.josh.durgin@dreamhost.com> <20110407084707.GA21871@stefanha-thinkpad.localdomain> Date: Fri, 8 Apr 2011 10:07:10 +0900 Message-ID: From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH v2 2/2] rbd: allow configuration of rados from the rbd filename List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yehuda Sadeh Weinraub Cc: Stefan Hajnoczi , ceph-devel@vger.kernel.org, Josh Durgin , qemu-devel@nongnu.org, kvm@vger.kernel.org 2011/4/8 Yehuda Sadeh Weinraub : > On Thu, Apr 7, 2011 at 2:54 AM, Yoshiaki Tamura > wrote: >> 2011/4/7 Stefan Hajnoczi : >>> On Thu, Apr 07, 2011 at 10:14:03AM +0900, Yoshiaki Tamura wrote: >>>> 2011/3/29 Josh Durgin : >>>> > The new format is rbd:pool/image[@snapshot][:option1=3Dvalue1[:optio= n2=3Dvalue2...]] >>>> > Each option is used to configure rados, and may be any Ceph option, = or "conf". >>>> > The "conf" option specifies a Ceph configuration file to read. >>>> > >>>> > This allows rbd volumes from more than one Ceph cluster to be used b= y >>>> > specifying different monitor addresses, as well as having different >>>> > logging levels or locations for different volumes. >>>> > >>>> > Signed-off-by: Josh Durgin >>>> > --- >>>> > =A0block/rbd.c | =A0119 ++++++++++++++++++++++++++++++++++++++++++++= ++++++-------- >>>> > =A01 files changed, 102 insertions(+), 17 deletions(-) >>>> > >>>> > diff --git a/block/rbd.c b/block/rbd.c >>>> > index cb76dd3..bc3323d 100644 >>>> > --- a/block/rbd.c >>>> > +++ b/block/rbd.c >>>> > @@ -22,13 +22,17 @@ >>>> > =A0/* >>>> > =A0* When specifying the image filename use: >>>> > =A0* >>>> > - * rbd:poolname/devicename >>>> > + * rbd:poolname/devicename[@snapshotname][:option1=3Dvalue1[:option= 2=3Dvalue2...]] >>>> >>>> I'm not sure IIUC, but currently this @snapshotname seems to be >>>> meaningless; it doesn't allow you to boot from a snapshot because it's >>>> read only. =A0Am I misunderstanding or tested incorrectly? >>> >>> Read-only block devices are supported by QEMU and can be useful. >> >> I agree. =A0My expectation was that @snapshotname is introduced to have >> writable snapshot. >> > The RADOS backend doesn't support writable snapshots. However, down > the rbd roadmap we plan to have layering which in a sense is writable > snapshots. The whole shift to librbd was done so that introducing such > new functionality will be transparent and will not require much or any > changes in the qemu code. Thanks. It made things clear :) I think it's a good move. Yoshi > > Yehuda >