[libvirt] [PATCH V3] implement offline migration

[liguang]

在 2012-08-27一的 23:38 -0700，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

yes, maybe, but as i see, MigratePrepareTunnel3 can only handler 1
stream once called, so only 1 file can be transferred,
if try to migrate multi-files, will be very hard, e.g. use cookie to
pass file info to remote, and at remote side, doPeer2PeerMigrate3 may
create a single thread to parse file info and setup streams for data
transferring, but it had to exit before we do the real stream sending,
so the new thread will be zombie, isn't it?
that's my consideration.

> 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.
> 

-- 
liguang    lig.fnst at cn.fujitsu.com
FNST linux kernel team