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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux