qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* dirty bitmap migration refactor
@ 2020-04-29 13:29 John Snow
  2020-04-30  4:53 ` Vladimir Sementsov-Ogievskiy
  0 siblings, 1 reply; 2+ messages in thread
From: John Snow @ 2020-04-29 13:29 UTC (permalink / raw)
  To: Vladimir Sementsov-Ogievskiy
  Cc: Peter Krempa, qemu-devel, Qemu-block, Dr. David Alan Gilbert

Hi all,

as you are probably aware I haven't been paying attention to dirty
bitmap work very much for the past month.

Around KVM Forum, we had a giant thread dedicated to discussing the
problems with dirty bitmap migration, which in a nutshell, are that it
migrates using the node name with no option for re-routing or re-naming
nodes.

IIRC, there was a patchset to fix this quickly sent by Virtuozzo, but
the series stalled because it was quite close to a release and was
deemed too risky.

What is the status of those patches, if any? Do we need to start from
scratch to implement the functionality that libvirt wants here?

--js



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: dirty bitmap migration refactor
  2020-04-29 13:29 dirty bitmap migration refactor John Snow
@ 2020-04-30  4:53 ` Vladimir Sementsov-Ogievskiy
  0 siblings, 0 replies; 2+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2020-04-30  4:53 UTC (permalink / raw)
  To: John Snow; +Cc: Peter Krempa, qemu-devel, Qemu-block, Dr. David Alan Gilbert

29.04.2020 16:29, John Snow wrote:
> Hi all,
> 
> as you are probably aware I haven't been paying attention to dirty
> bitmap work very much for the past month.
> 
> Around KVM Forum, we had a giant thread dedicated to discussing the
> problems with dirty bitmap migration, which in a nutshell, are that it
> migrates using the node name with no option for re-routing or re-naming
> nodes.
> 
> IIRC, there was a patchset to fix this quickly sent by Virtuozzo, but
> the series stalled because it was quite close to a release and was
> deemed too risky.
> 
> What is the status of those patches, if any? Do we need to start from
> scratch to implement the functionality that libvirt wants here?
> 

Hi!

There are two series now in list:

"[PATCH v2 0/5] fix migration with bitmaps and mirror" - the series you are saying about

I made some changes to it downstream, to restrict migration by generated node names at all, as we had a bug. I can resend, if needed.

What the series does? It just tries to migrate by blk name even for filtered nodes. This fixes migration of bitmaps during mirror. But it doesn't apply to blockdev-era (doesn't hurt still). So can someone analyze, do we need this fix in current Qemu? Or is it for downstream only? Or should we take it just to make downstreaming cleaner?

===

The second is "[PATCH v2 00/22] Fix error handling during bitmap postcopy"

- it fixes, how postcopy bitmap migration behaves on errors, and we need it anyway.

===

What to do next? I have a plan to post series to implement new API, discussed on list, to make mapping from bitmaps on source to bitmaps on target by hand.

-- 
Best regards,
Vladimir


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-30  4:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-29 13:29 dirty bitmap migration refactor John Snow
2020-04-30  4:53 ` Vladimir Sementsov-Ogievskiy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).