Re: [Qemu-devel] Live Block Migration using Mirroring

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

On 03/05/2012 09:59 AM, Marcelo Tosatti wrote:
> On Wed, Feb 22, 2012 at 05:13:32PM +0000, Federico Simoncelli wrote:
>> Hi,
>>  recently I've been working on live block migration combining the live
>> snapshots and the blkmirror patch sent by Marcelo Tosatti few months ago.
>>
>> The design is summarized at this url as "Mirrored-Snapshot": 
>>
>> http://www.ovirt.org/wiki/Features/Design/StorageLiveMigration
>>
>> The design assumes that the qemu process can reach both the source and
>> destination storages and no real VM migration between hosts is involved.
>> The principal problem that it tries to solve is moving a VM to a new
>> reachable storage (more space, faster) without temporarily disrupting its
>> services.
>>
>> The following set of patches are implementing the required changes in
>> QEMU.
> 
> What is the motivation here? What is the limitation with image streaming
> that this tries to solve?

My understanding is that this solves the scenario of a storage failure
during the migration.  The original post-copy approach has the flaw that
you are setting up a situation where qemu is operating on a qcow2 file
on one storage domain that is backed by a file on another storage
domain.  After you start the migration process, but before it completes,
any failure in the migration is fatal to the domain: if the destination
storage domain fails, then you have lost all the delta changes made
since the migration started.  And after the migration has completed, you
still have the problem that qemu is crossing storage domains - if the
source storage domain fails, then qemu's access to the backing file
renders the destination qcow2 worthless, so you cannot shut down the
source storage domain without also restarting the guest.

But a mirrored solution does not have these drawbacks - at all points
through the migration phase, you are guaranteed that _all_ data is
accessible from a single storage domain.  If the destination storage
fails, you still have the source storage intact, and can restart the
migration process.  Then, when the migration is complete, you tell qemu
to atomically switch storage domains, at which point the entire storage
is accessed from the destination domain, and you can safely shut down
the source storage domain while the guest continues to run..

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]