On Wed, Apr 04, 2018 at 12:03:03 +0200, Kevin Wolf wrote: > Am 03.04.2018 um 22:52 hat Dr. David Alan Gilbert geschrieben: > > * Kevin Wolf (kw...@redhat.com) wrote: > > > Consider a case where the management tool keeps a mirror job with > > > sync=none running to expose all I/O requests to some external process. > > > It needs to shut down the old block job on the source in the > > > 'pre-switchover' state, and start a new block job on the destination > > > when the destination controls the images, but the VM doesn't run yet (so > > > that it doesn't miss an I/O request). This patch removes the migration > > > phase that the management tool needs to implement this correctly. > > > > > > If we need a "neither side has control" phase, we might need to > > > introduce it in addition to the existing phases rather than replacing a > > > phase that is still needed in other cases. > > > > This is yet another phase to be added. > > IMHO this needs the managment tool to explicitly take control in the > > case you're talking about. > > What kind of mechanism do you have in mind there? > > Maybe what could work would be separate QMP commands to inactivate (and > possibly for symmetry activate) all block nodes. Then the management > tool could use the pre-switchover phase to shut down its block jobs > etc., inactivate all block nodes, transfer its own locks and then call > migrate-continue.
Libvirt's migration protocol consists of several phases, the ones relevant to QEMU are: 1. destination libvirtd starts a new QEMU process with -incoming 2. source libvirtd calls migrate QMP command and waits until migration completes; in this step we actually wait for the pre-switchover, shut down all block jobs, and call migrate-continue 3. destination libvirtd calls cont QMP command The daemons only communicated between these steps, i.e., the result of each steps is transferred to the other side of migration. In other words, transferring of locks and other state IIUC what you suggested would require step 2. to be split so that some work can be done on the destination between "migrate" command and completed migration. This would be pretty complicated and I don't think the problem we're trying to solve would be worth it. Not to mention that it would multiply the number of possible code paths in the migration code. However, I don't think the extra step is even necessary. We could just have a separate QMP command to activate block nodes. Thus the source would wait for pre-switchover, shut down all block jobs and call migrate-continue. Once migration completes, the control would be transferred to the destination which would call the new command to activate block nodes followed by cont. That is, the "cont" command would just be replaced with two commands. And this similarly to the pre-switchover state, this could be controlled by a new migration capability to make sure all block nodes are activated automatically with old libvirt which doesn't know anything about the new command. This would solve compatibility with non-libvirt use cases too. Jirka
