Re: [Qemu-block] [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Dr. David Alan Gilbert]

* Vladimir Sementsov-Ogievskiy (address@hidden) wrote:
> 03.08.2018 11:33, Dr. David Alan Gilbert wrote:
> > * Denis V. Lunev (address@hidden) wrote:
> > > On 08/02/2018 12:50 PM, Dr. David Alan Gilbert wrote:
> > > > * Denis V. Lunev (address@hidden) wrote:
> > > > 
> > > > 
> > > > > > I don't quite understand the last two paragraphs.
> > > > > we are thinking right now to eliminate delay on regular IO
> > > > > for migration. There is some thoughts and internal work in
> > > > > progress. That is why I am worrying.
> > > > What downtime are you typicaly seeing and what are you aiming for?
> > > > 
> > > > It would be good if you could explain what you're planning to
> > > > fix there so we can get a feel for it nearer the start of it
> > > > rather than at the end of the reviewing!
> > > > 
> > > > Dave
> > > The ultimate goal is to reliable reach 100 ms with ongoing IO and
> > > you are perfectly correct about reviewing :)
> > That would be neat.
> > 
> > > Though the problem is that right now we are just trying to
> > > invent something suitable :(
> > OK, some brain-storm level ideas:
> > 
> >    a) Throttle the write bandwidth at later stages of migration
> >       (I think that's been suggested before)
> >    b) Switch to some active-sync like behaviour where the writes
> >       are sent over the network as they happen to the destination
> >       (mreitz has some prototype code for that type of behaviour
> >       for postcopy)
> >    c) Write the writes into a buffer that gets migrated over the
> >      migration stream to get committed on the destination side.
> > 
> > As I say, brainstorm level ideas only!
> > 
> > Dave
> 
> Do you say about bitmaps migration? With current approach (postcopy) there
> should not be problems with downtime, as data can be sent after target vm
> start

The ideas above were meant to suggest ways to reduce the downtime due to
*write data* not bitmaps.

Dave

> > 
> > > Den
> > > 
> > > > > > However, coming back to my question; it was really saying that
> > > > > > normal guest IO during the end of the migration will cause
> > > > > > a delay; I'm expecting that to be fairly unrelated to the size
> > > > > > of the disk; more to do with workload; so I guess in your case
> > > > > > the worry is the case of big large disks giving big large
> > > > > > bitmaps.
> > > > > exactly!
> > > > > 
> > > > > Den
> > > > --
> > > > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 
> 
> -- 
> Best regards,
> Vladimir
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK