在 2012-11-09五的 13:00 +0100，Jiri Denemark写道： > On Fri, Nov 09, 2012 at 10:57:23 +0800, li guang wrote: > ... > > > > @@ -2150,6 +2192,9 @@ qemuMigrationRun(struct qemud_driver *driver, > > > > return -1; > > > > } > > > > > > > > + if (flags & VIR_MIGRATE_OFFLINE) > > > > + return 0; > > > > + > > > > if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, > > > cookieinlen, > > > > > > > QEMU_MIGRATION_COOKIE_GRAPHICS))) > > > > goto cleanup; > > > > > > I still think we should not even get into qemuMigrationRun when doing > > > offline migration. > > > > No, it will get into here for I did not touch migrationPerform path, > > initially I don't want to change any code at libvirt.c so I must keep > > offline migration walk through whole path like normal, or there're maybe > > lots of fixes, any will break up the migration path. > > Well, and that's the thing that actually needs fixing. The migration code in > libvirt.c and the code doing peer-to-peer migration in qemu_migration.c are > very similar because they are doing almost the same job (only at different > levels). It makes sense to change them both at the same time. Why do you want > to avoid changing code in libvirt.c? first, I think it's clean enough for my patch to do offline migration, second, someone told me to keep public API stability of libvirt before(it's not clear who and when), so I fear to change. you mean I should take care of fixing or re-factoring redundant code this time? maybe I can try to do something after this patch. > > Jirka -- li guang lig.fnst@xxxxxxxxxxxxxx linux kernel team at FNST, china -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list