[libvirt] [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
Anthony Liguori
anthony at codemonkey.ws
Thu Nov 10 19:11:42 UTC 2011
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
More information about the libvir-list
mailing list