Re: [Qemu-devel] KVM call agenda for June 28
On Tue, Jul 5, 2011 at 7:18 PM, Marcelo Tosatti mtosa...@redhat.com wrote: On Tue, Jul 05, 2011 at 04:37:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 3:32 PM, Marcelo Tosatti mtosa...@redhat.com wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. One use case I have in mind is the Live Backup approach that Jagane has been developing. Here the backup solution only creates a snapshot for the period of time needed to read out the dirty blocks. Then the snapshot is deleted again and probably contains very little new data relative to the base image. The backup solution does this operation every day. This is the pathalogical case for any approach that copies the entire base into a new file. We could have avoided a lot of I/O by doing an in-place update. I want to make sure this works well. This use case does not fit the streaming scheme that has come up. Its a completly different operation. IMO it should be implemented separately. Okay, not everything can fit into this one grand unified block copy/image streaming mechanism :). Stefan -- 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] KVM call agenda for June 28
Am 05.07.2011 20:18, schrieb Marcelo Tosatti: On Tue, Jul 05, 2011 at 04:37:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 3:32 PM, Marcelo Tosatti mtosa...@redhat.com wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. One use case I have in mind is the Live Backup approach that Jagane has been developing. Here the backup solution only creates a snapshot for the period of time needed to read out the dirty blocks. Then the snapshot is deleted again and probably contains very little new data relative to the base image. The backup solution does this operation every day. This is the pathalogical case for any approach that copies the entire base into a new file. We could have avoided a lot of I/O by doing an in-place update. I want to make sure this works well. This use case does not fit the streaming scheme that has come up. Its a completly different operation. IMO it should be implemented separately. I agree, this is a case for a live commit operation. 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] KVM call agenda for June 28
I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Cheers, Dor On 06/30/2011 09:38 PM, Marcelo Tosatti wrote: On Thu, Jun 30, 2011 at 04:52:00PM +0200, Kevin Wolf wrote: Am 30.06.2011 16:36, schrieb Marcelo Tosatti: 4. Live block copy API and high-level control - the main code that adds the live block copy feature. Existing patches by Marcelo, can be restructured to use common core by Marcelo. Can use your proposed block_stream interface, with a block_switch command on top, so: 1) management creates copy.img with backing file current.img, allows access 2) management issues block_switch dev copy.img 3) management issues block_stream dev base Isn't this block_switch command the same as the existing snapshot_blkdev? Yep. Thought of implementing block_stream command by reopening device with blkstream:imagename.img Then: AIO_READ: - for each cluster in request: - if allocated-or-in-final-base, read. - check write queue, if present wait on it, if not, add copy entry to write queue. - issue cluster sized read from source. - on completion: - copy data to original read buffer, complete it. - if not cancelled, write cluster to destination. AIO_WRITE for each cluster in request: - check write queue, cancel/wait for copy entry. - add guest entry to write queue. - issue write to destination. - on completion: - remove write queue entry. With the 0...END background read, once it completes write final base file for image. So block_stream/block_stream_cancel/block_stream_status commands, the background read and the rebase -u update can be separate from the block driver. The way how it works looks good to me, I'm just not entirely sure about the right place to implement it. I think request queueing and copy on read could be useful outside blkstream, too. They could be lifted later, when there are other users. -- 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 -- 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] KVM call agenda for June 28
On Tue, Jul 5, 2011 at 9:01 AM, Dor Laor dl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laor dl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Management can set a higher limit on the size of data that is merged, and create a new base once exceeded. This avoids copying excessive amounts of data. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Management can set a higher limit on the size of data that is merged, and create a new base once exceeded. This avoids copying excessive amounts of data. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Management can set a higher limit on the size of data that is merged, and create a new base once exceeded. This avoids copying excessive amounts of data. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
Am 05.07.2011 16:32, schrieb Marcelo Tosatti: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 Hm, I would expect that a case like this is important, too: base - sn-1 - ... - sn-n-1 - sn-n - ... - sn-m Which should be merged so that we get the following (i.e. deleting older snapshots but retaining more recent ones): base - sn-merged - sn-n - ... - sn-m 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] KVM call agenda for June 28
On 07/05/2011 05:32 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base-- s1-- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base-- s1-- s2-- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base-- s1-- s2-- s3 base-- s1-- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base-- s1-- s2-- s3 after: base-- s1-- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 Sometimes one will want to merge the snapshot immediately post the base was backed-up It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. Not always, the image might be raw file/device - 1. raw image 2. live snapshot it and use COW above it raw - s1 3. backup the raw image using 3rd party mechanism 4. live merge (copy) s1 into raw All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Management can set a higher limit on the size of data that is merged, and create a new base once exceeded. This avoids copying excessive amounts of data. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
On Tue, Jul 05, 2011 at 06:04:34PM +0300, Dor Laor wrote: On 07/05/2011 05:32 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base-- s1-- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base-- s1-- s2-- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base-- s1-- s2-- s3 base-- s1-- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base-- s1-- s2-- s3 after: base-- s1-- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 Sometimes one will want to merge the snapshot immediately post the base was backed-up Well, ok, this needs a separate interface for management, needs write mirroring, and must mind crash handling. It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. Not always, the image might be raw file/device - 1. raw image 2. live snapshot it and use COW above it raw - s1 3. backup the raw image using 3rd party mechanism 4. live merge (copy) s1 into raw All data from snapshot and cow is copied into merge and then snapshot and cow can be deleted. But this approach is results in full data copying and uses potentially 3x space if cow is close to the size of snapshot. Management can set a higher limit on the size of data that is merged, and create a new base once exceeded. This avoids copying excessive amounts of data. Any other ideas that reuse live block copy for snapshot merge? Stefan -- 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] KVM call agenda for June 28
On Tue, Jul 5, 2011 at 3:32 PM, Marcelo Tosatti mtosa...@redhat.com wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. One use case I have in mind is the Live Backup approach that Jagane has been developing. Here the backup solution only creates a snapshot for the period of time needed to read out the dirty blocks. Then the snapshot is deleted again and probably contains very little new data relative to the base image. The backup solution does this operation every day. This is the pathalogical case for any approach that copies the entire base into a new file. We could have avoided a lot of I/O by doing an in-place update. I want to make sure this works well. Stefan -- 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] KVM call agenda for June 28
On Tue, Jul 05, 2011 at 04:37:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 3:32 PM, Marcelo Tosatti mtosa...@redhat.com wrote: On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: On Tue, Jul 5, 2011 at 9:01 AM, Dor Laordl...@redhat.com wrote: I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Live block copy was supposed to support snapshot merge. I think the current favored approach is to make the source image a backing file to the destination image and essentially do image streaming. Using this mechanism for snapshot merge is tricky. The COW file already uses the read-only snapshot base image. So now we cannot trivally copy the COW file contents back into the snapshot base image using live block copy. It never did. Live copy creates a new image were both snapshot and current are copied to. This is similar with image streaming. Not sure I realize what's bad to do in-place merge: Let's suppose we have this COW chain: base -- s1 -- s2 Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: base -- s1 -- s2 -- s3 Now we've done with s2 (post backup) and like to merge s3 into s2. With your approach we use live copy of s3 into newSnap: base -- s1 -- s2 -- s3 base -- s1 -- newSnap When it is over s2 and s3 can be erased. The down side is the IOs for copying s2 data and the temporary storage. I guess temp storage is cheap but excessive IO are expensive. My approach was to collapse s3 into s2 and erase s3 eventually: before: base -- s1 -- s2 -- s3 after: base -- s1 -- s2 If we use live block copy using mirror driver it should be safe as long as we keep the ordering of new writes into s3 during the execution. Even a failure in the the middle won't cause harm since the management will keep using s3 until it gets success event. Well, it is more complicated than simply streaming into a new image. I'm not entirely sure it is necessary. The common case is: base - sn-1 - sn-2 - ... - sn-n When n reaches a limit, you do: base - merge-1 You're potentially copying similar amount of data when merging back into a single image (and you can't easily merge multiple snapshots). If the amount of data thats not in 'base' is large, you create leave a new external file around: base - merge-1 - sn-1 - sn-2 ... - sn-n to base - merge-1 - merge-2 It seems like snapshot merge will require dedicated code that reads the allocated clusters from the COW file and writes them back into the base image. A very inefficient alternative would be to create a third image, the merge image file, which has the COW file as its backing file: snapshot (base) - cow - merge Remember there is a 'base' before snapshot, you don't copy the entire image. One use case I have in mind is the Live Backup approach that Jagane has been developing. Here the backup solution only creates a snapshot for the period of time needed to read out the dirty blocks. Then the snapshot is deleted again and probably contains very little new data relative to the base image. The backup solution does this operation every day. This is the pathalogical case for any approach that copies the entire base into a new file. We could have avoided a lot of I/O by doing an in-place update. I want to make sure this works well. This use case does not fit the streaming scheme that has come up. Its a completly different operation. IMO it should be implemented separately. Stefan -- 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] KVM call agenda for June 28
On 06/28/2011 08:48 AM, Avi Kivity wrote: On 06/28/2011 04:43 PM, Anthony Liguori wrote: FYI, I'm in an all-day meeting so I can't attend. Did you do something really bad? I named some variables with a leading underscore and now have to be re-educated. Regards, Anthony Liguori -- 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] KVM call agenda for June 28
On Thu, Jun 30, 2011 at 04:52:00PM +0200, Kevin Wolf wrote: Am 30.06.2011 16:36, schrieb Marcelo Tosatti: 4. Live block copy API and high-level control - the main code that adds the live block copy feature. Existing patches by Marcelo, can be restructured to use common core by Marcelo. Can use your proposed block_stream interface, with a block_switch command on top, so: 1) management creates copy.img with backing file current.img, allows access 2) management issues block_switch dev copy.img 3) management issues block_stream dev base Isn't this block_switch command the same as the existing snapshot_blkdev? Yep. Thought of implementing block_stream command by reopening device with blkstream:imagename.img Then: AIO_READ: - for each cluster in request: - if allocated-or-in-final-base, read. - check write queue, if present wait on it, if not, add copy entry to write queue. - issue cluster sized read from source. - on completion: - copy data to original read buffer, complete it. - if not cancelled, write cluster to destination. AIO_WRITE for each cluster in request: - check write queue, cancel/wait for copy entry. - add guest entry to write queue. - issue write to destination. - on completion: - remove write queue entry. With the 0...END background read, once it completes write final base file for image. So block_stream/block_stream_cancel/block_stream_status commands, the background read and the rebase -u update can be separate from the block driver. The way how it works looks good to me, I'm just not entirely sure about the right place to implement it. I think request queueing and copy on read could be useful outside blkstream, too. They could be lifted later, when there are other users. -- 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] KVM call agenda for June 28
On 06/27/2011 09:32 AM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. FYI, I'm in an all-day meeting so I can't attend. Regards, Anthony Liguori Later, Juan. -- 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] KVM call agenda for June 28
On 06/28/2011 04:43 PM, Anthony Liguori wrote: FYI, I'm in an all-day meeting so I can't attend. Did you do something really bad? -- error compiling committee.c: too many arguments to function -- 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
