[libvirt] [PATCH 3/6] Introduce yet another migration version in API.

Stefan Berger stefanb at linux.vnet.ibm.com
Thu Apr 21 20:00:03 UTC 2011


On 04/21/2011 10:24 AM, Daniel P. Berrange wrote:
> On Thu, Apr 21, 2011 at 09:33:42AM -0400, Stefan Berger wrote:
>> On 04/21/2011 07:43 AM, Daniel P. Berrange wrote:
>>> On Thu, Apr 21, 2011 at 07:37:30AM -0400, Stefan Berger wrote:
>>>> and simply doesn't start the VM. After this function is called all
>>>> sockets are closed and the communication with the source host is
>>>> cut. I don't think it allows for fall-back at this point.
>>> Sure it does. As long as the destination QEMU CPUs have not been
>>> started, you can fallback by simply killing the dest QEMU and
>>> restarting CPUs on the src QEMU.
>>>
>> FWIW, I did a test and disabled the starting of the CPUs on the
>> destination side and
>> did a sleep() instead. Before the sleep() was over the Qemu on the
>> source side had already disappeared.
> That is with the old v2 migration protocol. In the new v3 protocol
> that has changed to work as I described.
Hm... From what I see in the Qemu code and from the tracing I have done 
Qemu goes right from sending out the last byte in 
qemu_savevm_state_complete() to closing the sockets in 
migrate_fd_cleanups() with this sequence in migrate_fd_put_ready(). Also 
the receiving side attempts to receive all bytes in 
process_incoming_migration() and then goes straight to closing the 
sockets with this sequence in tcp_accept_incoming_migration(). This 
means that once migration has completely sent or received all bytes, the 
connection between the two Qemus is cut and there is no waiting for 
starting the CPUs or something like that. If relative to the Qemu 
migration the association of profiles returns a negative result after 
Qemu has sent all bytes, it's too late to kill the destination and fall 
back to the source.

   Stefan
>
> Daniel




More information about the libvir-list mailing list