* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote: > 03.08.2018 11:33, Dr. David Alan Gilbert wrote: > > * Denis V. Lunev (d...@openvz.org) wrote: > > > On 08/02/2018 12:50 PM, Dr. David Alan Gilbert wrote: > > > > * Denis V. Lunev (d...@openvz.org) 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 / dgilb...@redhat.com / Manchester, UK > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > -- > Best regards, > Vladimir > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
