Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/10/2011 12:42 PM, Daniel P. Berrange wrote:
> On Thu, Nov 10, 2011 at 12:27:30PM -0600, Anthony Liguori wrote:
>> What does libvirt actually do in the monitor prior to migration
>> completing on the destination?  The least invasive way of doing
>> delayed open of block devices is probably to make -incoming create a
>> monitor and run a main loop before the block devices (and full
>> device model) is initialized.  Since this isolates the changes
>> strictly to migration, I'd feel okay doing this for 1.0 (although it
>> might need to be in the stable branch).
>
> The way migration works with libvirt wrt QEMU interactions is now
> as follows
>
>   1. Destination.
>         Run   qemu -incoming ...args...
>         Query chardevs via monitor
>         Query vCPU threads via monitor
>         Set disk / vnc passwords

Since RHEL carries Juan's patch, and Juan's patch doesn't handle disk passwords 
gracefully, how does libvirt cope with that?

Regards,

Anthony Liguori

>         Set netdev link states
>         Set balloon target
>
>   2. Source
>         Set  migration speed
>         Set  migration max downtime
>         Run  migrate command (detached)
>         while 1
>            Query migration status
>            if status is failed or success
>              break;
>
>   3. Destination
>        If final status was success
>           Run  'cont' in monitor
>        else
>           kill QEMU process
>
>   4. Source
>        If final status was success and 'cont' on dest succeeded
>           kill QEMU process
>        else
>           Run 'cont' in monitor
>
>
> In older libvirt, the bits from step 4, would actually take place
> at the end of step 2. This meant we could end up with no QEMU
> on either the source or dest, if starting CPUs on the dest QEMU
> failed for some reason.
>
>
> We would still really like to have a 'query-migrate' command for
> the destination, so that we can confirm that the destination has
> consumed all incoming migrate data successfully, rather than just
> blindly starting CPUs and hoping for the best.
>
> Regards,
> Daniel