在 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@xxxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxx FNST linux kernel team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list