On Wed, Feb 23, 2011 at 03:01:14PM +0200, Avi Kivity wrote: > On 02/23/2011 01:14 AM, Anthony Liguori wrote: > > > >-drive already ties into the qemuopts infrastructure and we have > >readconfig and writeconfig. I don't think we're missing any major > >pieces to do this in a more proper fashion. > > The problem with qemu config files is that it splits the > authoritative source of where images are stored into two. Is it in > the management tool's database or is it in qemu's config file? > > For the problem at hand, one solution is to make qemu stop after the > copy, and then management can issue an additional command to > rearrange the disk and resume the guest. A drawback here is that if > management dies, the guest is stopped until it restarts. We also > make management latency guest visible, even if it doesn't die at an > inconvenient place. > > An alternative approach is to have the copy be performed by a new > layered block format driver: > > - create a new image, type = live-copy, containing three pieces of > information > - source image > - destination image > - copy state (initially nothing is copied) > - tell qemu switch to the new image > - qemu starts copying, updates copy state as needed > - copy finishes, event is emitted; reads and writes still serviced > - management receives event, switches qemu to destination image > - management removes live-copy image > > If management dies while this is happening, it can simply query the > state of the copy. > Similarly, if qemu dies, the copy state is persistent (could be 0/1 or > real range of blocks).
You don't know if a given block is uptodate or not without the dirty bitmap. So unless you also keep track of dirty log somehow, this is meaningless. So a commit file as proposed indicates copy state (in 0/1 fashion). The difference in your proposal is that such information is stored inside a special purpose image format?
