Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
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. 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. 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. 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. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
Am 14.05.2010 11:54, schrieb MORITA Kazutaka: 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. Yes, it probably requires a bit more than just five lines. We should have it in the final version of the patch series, but we seem to agree there and image creation is separate enough, so we can ignore it for the discussion of the other parts. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
At Thu, 13 May 2010 04:46:46 +0900, MORITA Kazutaka wrote: On 2010/05/12 20:38, Kevin Wolf wrote: I'll have a closer look at your code later, but one thing I noticed is that the new block driver is something in between a protocol and a format driver (just like vvfat, which should stop doing so, too). I think it ought to be a real protocol with the raw format driver on top (or any other format - I don't see a reason why this should be restricted to raw). The one thing that is unusual about it as a protocol driver is that it supports snapshots. However, while it is the first one, supporting snapshots in protocols is a thing that could be generally useful to support (for example thinking of a LVM protocol, which was discussed in the past). I agreed. I'll modify the sheepdog driver patch as a protocol driver one, and remove unnecessary format check from my patch. So in block.c we could check if the format driver supports snapshots, and if it doesn't we try again with the underlying protocol. Not sure yet what we would do when both format and protocol do support snapshots (qcow2 on sheepdog/LVM/...), but that's a detail. 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? 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. 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. If my suggestions are okay, I'd like to prepare the patches. Regards, Kazutaka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
On 2010/05/12 20:38, Kevin Wolf wrote: Am 12.05.2010 12:46, schrieb MORITA Kazutaka: Hi all, This patch adds a block driver for Sheepdog distributed storage system. Please consider for inclusion. Sheepdog is a distributed storage system for QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. Sheepdog features are: - No node in the cluster is special (no metadata node, no control node, etc) - Linear scalability in performance and capacity - No single point of failure - Autonomous management (zero configuration) - Useful volume management support such as snapshot and cloning - Thin provisioning - Autonomous load balancing The more details are available at the project site [1] and my previous post about sheepdog [2]. We have implemented the essential part of sheepdog features, and believe the API between Sheepdog and QEMU is finalized. Any comments or suggestions would be greatly appreciated. These patches don't apply, neither on git master nor on the block branch. Please rebase them on git://repo.or.cz/qemu/kevin.git block for the next submission. Ok, I'll rebase them and resend later. Sorry for inconvenience. I'll have a closer look at your code later, but one thing I noticed is that the new block driver is something in between a protocol and a format driver (just like vvfat, which should stop doing so, too). I think it ought to be a real protocol with the raw format driver on top (or any other format - I don't see a reason why this should be restricted to raw). The one thing that is unusual about it as a protocol driver is that it supports snapshots. However, while it is the first one, supporting snapshots in protocols is a thing that could be generally useful to support (for example thinking of a LVM protocol, which was discussed in the past). I agreed. I'll modify the sheepdog driver patch as a protocol driver one, and remove unnecessary format check from my patch. So in block.c we could check if the format driver supports snapshots, and if it doesn't we try again with the underlying protocol. Not sure yet what we would do when both format and protocol do support snapshots (qcow2 on sheepdog/LVM/...), but that's a detail. Thanks, Kazutaka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
