qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system fo


From: MORITA Kazutaka
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
Date: Fri, 14 May 2010 18:54:27 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.3 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 14 May 2010 10:32:26 +0200,
Kevin Wolf wrote:
> 
> Am 13.05.2010 16:03, schrieb MORITA Kazutaka:
> > To support snapshot in a protocol, I'd like to call the hander of the
> > protocol driver in the following functions in block.c:
> > 
> >     bdrv_snapshot_create
> >     bdrv_snapshot_goto
> >     bdrv_snapshot_delete
> >     bdrv_snapshot_list
> >     bdrv_save_vmstate
> >     bdrv_load_vmstate
> > 
> > Is it okay?
> 
> Yes, I think this is the way to go.
> 
Done.

> > In the case both format and protocol drivers support snapshots, I
> > think it is better to call the format driver handler.  Because qcow2
> > is well known as a snapshot support format, so when users use qcow2,
> > they expect to get snapshot with qcow2.
> 
> I agree.
> 
Done.

> > There is another problem to make the sheepdog driver be a protocol;
> > how to deal with protocol specific create_options?
> > 
> > For example, sheepdog supports cloning images as a format driver:
> > 
> >   $ qemu-img create -f sheepdog dst -b sheepdog:src
> > 
> > But if the sheepdog driver is a protocol, error will occur.
> > 
> >   $ qemu-img create sheepdog:dst -b sheepdog:src
> >   Unknown option 'backing_file'
> >   qemu-img: Backing file not supported for file format 'raw'
> > 
> > It is because the raw format doesn't support a backing_file option.
> > To support the protocol specific create_options, if the format driver
> > cannot parse some of the arguments, the protocol driver need to parse
> > them.
> 
> That's actually a good point. Yes, I think it makes a lot of sense to
> allow parameters to be passed to the protocol driver.
> 

Okay. But it seemed to require many changes to the qemu-img parser, so I didn't
do it in the patchset I sent just now.

> Also, I've never tried to create an image over a protocol other than
> file. As far as I know, raw is the only format for which it should work
> right now (at least in theory). As we're going forward, I'm planning to
> convert the other drivers, too.
> 

I see. Thank you for the explanations.


Regards,

Kazutaka



reply via email to

[Prev in Thread] Current Thread [Next in Thread]