On 11/17/2017 06:10 AM, John Snow wrote: > > On 11/16/2017 03:17 AM, Vladimir Sementsov-Ogievskiy wrote: >> 16.11.2017 00:20, John Snow wrote: >>> On 11/13/2017 11:20 AM, Vladimir Sementsov-Ogievskiy wrote: >>>> Hi all. >>>> >>>> There are three qmp commands, needed to implement external backup API. >>>> >>>> Using these three commands, client may do all needed bitmap >>>> management by >>>> hand: >>>> >>>> on backup start we need to do a transaction: >>>> {disable old bitmap, create new bitmap} >>>> >>>> on backup success: >>>> drop old bitmap >>>> >>>> on backup fail: >>>> enable old bitmap >>>> merge new bitmap to old bitmap >>>> drop new bitmap >>>> >>> Can you give me an example of how you expect these commands to be used, >>> and why they're required? >>> >>> I'm a little weary about how error-prone these commands might be and the >>> potential for incorrect usage seems... high. Why do we require them? >> It is needed for incremental backup. It looks like bad idea to export >> abdicate/reclaim functionality, it is simpler >> and clearer to allow user to merge/enable/disable bitmaps by hand. >> >> usage is like this: >> >> 1. we have dirty bitmap bitmap0 for incremental backup. >> >> 2. prepare image fleecing (create temporary image with backing=our_disk) >> 3. in qmp transaction: >> - disable bitmap0 >> - create bitmap1 >> - start image fleecing (backup sync=none our_disk -> temp_disk) > This could probably just be its own command, though: > > block-job-fleece node=foobar bitmap=bitmap0 etc=etera etc=etera > > Could handle forking the bitmap. I'm not sure what the arguments would > look like, but we could name the NBD export here, too. (Assuming the > server is already started and we just need to create the share.) > > Then, we can basically do what mirror does: > > (1) Cancel > (2) Complete > > Cancel would instruct QEMU to keep the bitmap changes (i.e. roll back), > and Complete would instruct QEMU to discard the changes. > > This way we don't need to expose commands like split or merge that will > almost always be dangerous to use over QMP. > > In fact, a fleecing job would be really convenient even without a > bitmap, because it'd still be nice to have a convenience command for it. > Using an existing infrastructure and understood paradigm is just a bonus. > actually this is a very good question about safety/simplicity...
We actually have spent a bit of time on design and have not come to a good solution. Yes, technically for now we can put all into fleecing command and rely on its semantics. Though I am not convinced with that approach. We can think that this can be reused on snapshot operations (may be, may be not). Also technically there are other cases. This is actually a matter that QEMU should provide low level API while management software should make decisions. Providing merge etc operations is done using exactly that approach. We can also consider this in a similar way we have recently fixed "revert to snapshot" operation. Management can make and should make a decision. Den