[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

but, how can dst knows the prepared migration is offline or not at src?
virDomainObjIsActive will always return 0 at dst at prepare phase,
so, how can we setup a distinguished stream for offline migration here?
a special parameter for this purpose? roughly way, a modified API same
with a new API, I think.

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

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