[libvirt] [PATCH V3] implement offline migration

[Eric Blake]

On 08/27/2012 11:20 PM, Daniel P. Berrange wrote:
> On Tue, Aug 28, 2012 at 01:38:32PM +0800, liguang wrote:
>> Signed-off-by: liguang <lig.fnst at cn.fujitsu.com>
> 
> Please provide a full description of what this patch is supposed
> to be doing and why you've implemented it this way. I struggle
> to understand what on earth this patch is doing with the streams
> APIs, nor why we need a new public API for this.

I agree with Daniel that we do not need a new API, but that the existing
API is sufficient.  Remember, virDomainMigrate will eventually boil down
to these RPC transactions if both sides support v3:

src: begin - pass the xml to dst (unchanged for offline)
dst: prepare - get ready to accept incoming VM (online starts a new qemu
process, offline migration has nothing to do beyond defining the xml
just received)
src: perform - start the migration (online triggers the migration of vm
state; offline migration has nothing to do since there is no vm state)
dst: finish - wait for completion and kill on failure (online continues
the qemu process to run the vm, offline has nothing further to do)
src: confirm - final cleanup (unchanged for offline)

That is, I think you should modify the existing APIs to delete their
current check that does an early exit for an offline domain, and instead
handle offline domains by migrating the XML definition.  If you are also
trying to allow migration of non-shared disk images (that is, implement
the 'virsh migrate --copy-storage-all' flag) for offline VMs, that would
be where you have to use virStream under the hood, since you no longer
have qemu doing it on your behalf.  But set up that stream and
coordinate its progress using the 5 existing steps of v3 migration, not
by creating a new API.

Furthermore, recall that the existing qemu implementation of live
migration of storage alongside vm state is considered deprecated, and
that for qemu 1.3, we already have to use different methodologies to
continue to support the same top-level semantics of a --copy-storage-all
flag (most likely, by libvirt setting up the source to be an NBD server,
the destination to connect to that NBD server as a backing file, then do
a block pull, and finally breaking the NBD connection down when
everything is migrated).  Depending on how things to with upstream qemu
on this design change, it may impact how we do live migration of
non-shared storage, and we should be looking at how best to share the
work between both online and offline migration.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120827/c1e6caac/attachment-0001.sig>