[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
From: |
MORITA Kazutaka |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm |
Date: |
Mon, 24 May 2010 20:42:08 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.2 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Mon, 24 May 2010 14:05:58 +0300,
Avi Kivity wrote:
>
> On 05/24/2010 10:12 AM, MORITA Kazutaka wrote:
> > At Sun, 23 May 2010 15:01:59 +0300,
> > Avi Kivity wrote:
> >
> >> On 05/21/2010 12:29 AM, Anthony Liguori wrote:
> >>
> >>> I'd be more interested in enabling people to build these types of
> >>> storage systems without touching qemu.
> >>>
> >>> Both sheepdog and ceph ultimately transmit I/O over a socket to a
> >>> central daemon, right?
> >>>
> >> That incurs an extra copy.
> >>
> >>
> >>> So could we not standardize a protocol for this that both sheepdog and
> >>> ceph could implement?
> >>>
> >> The protocol already exists, nbd. It doesn't support snapshotting etc.
> >> but we could extend it.
> >>
> >>
> > I have no objection to use another protocol for Sheepdog support, but
> > I think nbd protocol is unsuitable for the large storage pool with
> > many VM images. It is because nbd protocol doesn't support specifing
> > a file name to open. If we use nbd with such a storage system, the
> > server needs to listen ports as many as the number of VM images. As
> > far as I see the protocol, It looks difficult to extend it without
> > breaking backward compatibility.
> >
>
> The server would be local and talk over a unix domain socket, perhaps
> anonymous.
>
> nbd has other issues though, such as requiring a copy and no support for
> metadata operations such as snapshot and file size extension.
>
Sorry, my explanation was unclear. I'm not sure how running servers
on localhost can solve the problem.
What I wanted to say was that we cannot specify the image of VM. With
nbd protocol, command line arguments are as follows:
$ qemu nbd:hostname:port
As this syntax shows, with nbd protocol the client cannot pass the VM
image name to the server.
Regards,
Kazutaka
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, (continued)
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Blue Swirl, 2010/05/20
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/23
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, MORITA Kazutaka, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm,
MORITA Kazutaka <=
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Cláudio Martins, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, MORITA Kazutaka, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Christian Brunner, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Anthony Liguori, 2010/05/24
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/25
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Anthony Liguori, 2010/05/25
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/25
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Anthony Liguori, 2010/05/25
- Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm, Avi Kivity, 2010/05/25