On Thu, Feb 24, 2011 at 10:58:10AM +0200, Avi Kivity wrote: > On 02/23/2011 07:49 PM, Marcelo Tosatti wrote: > >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
There is a similar situation with atomicity here. Mgmt app requests a switch and dies immediately, before receiving the command reply. Qemu crashes. Which image is the uptodate one, source or live-copy? > >> - 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. > > First, you no longer need the dirty bitmap. Since all writes go > through the layered block format driver, you know first-hand what is > dirty and what isn't. > > >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? > > > > It could also store the already synced range. > > The difference is that the file is self contained. > You could hot-unplug the image and hot-plug it later (continuing the > copy with qemu-img), Then there's no need for live copy. qemu-img does that already. > or live migrate it. You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. > In fact I think a qemu RAID-1 driver > removes the restriction that you can't live-migrate and live-copy > simultaneously. As mentioned its just an implementation detail.
