[libvirt] [PATCH v13] support offline migration

li guang lig.fnst at cn.fujitsu.com
Mon Nov 19 01:00:18 UTC 2012

在 2012-11-16五的 11:21 +0100,Jiri Denemark写道:
> On Mon, Nov 12, 2012 at 09:26:30 +0800, li guang wrote:
> > 在 2012-11-09五的 13:00 +0100,Jiri Denemark写道:
> > > On Fri, Nov 09, 2012 at 10:57:23 +0800, li guang wrote:
> > >
> > > 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.
> Well, don't worry I'm aware of API/ABI stability we need to maintain in
> libvirt and I wouldn't suggest you to do something that would break anything
> in that area. Of course you can't add new parameters to existing public
> functions, for example. But changing the code inside to support new flags is
> allowed.


> > 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.
> No. It's just that the migration code in libvirt.c and the p2p code in
> qemu_migration.c are very similar since they are doing the same thing at
> different levels. You can't really refactor that and I'm not asking you to do
> so. However, since the code logic is similar in both places, it's wise to keep
> it that way and just skip Perform phase for offline migrations regardless on
> the actual type of migration. I'd much like to see that rather than hacking
> somewhere inside the code doing Perform phase to exit if it notices it should
> not have been run at all.
> Jirka

li guang  lig.fnst at cn.fujitsu.com
linux kernel team at FNST, china

More information about the libvir-list mailing list