Re: [libvirt] [PATCH V3] implement offline migration

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(a)cn.fujitsu.com&gt; > > 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.