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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
