On Thu, Feb 24, 2011 at 05:28:20PM +0200, Avi Kivity wrote: > On 02/24/2011 05:14 PM, Marcelo Tosatti wrote: > >> >> 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? > > live-copy (or it's new name, RAID-1). Once you've created it it is > equivalent to source. Once it switches to state=synced you can > switch back to either source or destination (I guess by telling qemu > to detach the one you don't want first, so it falls back to > state=degraded). > > > > >> 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. > > It will start from the beginning. > > >> 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. > > A RAID-1 driver will work with block live migration too.
Nobody cares about that one (block copy and block live migration in progress). In fact, i doubt anybody cares about parallel block migration and block copy either (mgmt can easily cope with that limitation, stop live copy if migration is needed). > >> 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. I meant the restriction of live-migrate and live-copy in parallel. > I think it's an important one. It moves the code from the generic > layer to a driver. Well it is a nice idea, but devil is in the details: - Guest writes must invalidate in progress live copy reads and live copy writes, so you have to maintain a queue for live copy AIO. - Live copy writes must be aware of in progress guest AIO writes, so you have to maintain a queue for guest AIO. - Guest writes must be mirrored to source and destination. - qemu-img must handle this new format. So my view ATM is that this is overengineering. > It allows generic RAID-1 functionality (for high > availablity). Isnt HA responsability of the host filesystem?
