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 -- 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
