Am 10.04.2018 um 16:22 hat Dr. David Alan Gilbert geschrieben: > * Kevin Wolf (kw...@redhat.com) wrote: > > Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben: > > > Hmm; having chatted to Jiri I'm OK with reverting it, on the condition > > > that I actually understand how this alternative would work first. > > > > > > I can't currently see how a block-inactivate would be used. > > > I also can't see how a block-activate unless it's also with the > > > change that you're asking to revert. > > > > > > Can you explain the way you see it working? > > > > The key is making the delayed activation of block devices (and probably > > delayed announcement of NICs? - you didn't answer that part) optional > > instead of making it the default. > > NIC announcments are broken in similar but slightly different ways; we > did have a series on list to help a while ago but it never got merged; > I'd like to keep that mess separate.
Okay. I just thought that it would make sense to have clear migration phases that are the same for all external resources that the QEMU processes use. > > We can use Jirka's suggestion of adding a migration capability that > > enables it, or I suppose a new option to -incoming could work, too. It > > doesn't really matter what the syntax is, but the management tool must > > request it explicitly. > > A new capability is easy to gate the change in behaviour that this patch > added; I'll do that first thing for 2.13 (given today is rc3 tag it's > too late). > > However, once we turn this on, to cope with the situation of a block user > that must start prior to the 'cont' when this behaviour is active, we'd > also need the 'block-activate' command. Yes, that's right. Kevin