* Adalbert Lazăr (ala...@bitdefender.com) wrote: > On Tue, 28 Apr 2020 13:24:39 +0100, "Dr. David Alan Gilbert" > <dgilb...@redhat.com> wrote: > > * Adalbert Lazăr (ala...@bitdefender.com) wrote: > > > On Mon, 27 Apr 2020 20:08:55 +0100, "Dr. David Alan Gilbert" > > > <dgilb...@redhat.com> wrote: > > > > * Adalbert Lazăr (ala...@bitdefender.com) wrote: > > > > > From: Marian Rotariu <marian.c.rota...@gmail.com> > > > > > > > > > > It is possible that the introspection tool has made some changes > > > > > inside > > > > > the introspected VM which can make the guest crash if the > > > > > introspection > > > > > connection is suddenly closed. > > > > > > > > > > When the live migration starts, for now, the introspection tool is > > > > > signaled to remove its hooks from the introspected VM. > > > > > > > > > > CC: Juan Quintela <quint...@redhat.com> > > > > > CC: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > > Signed-off-by: Marian Rotariu <marian.c.rota...@gmail.com> > > > > > Signed-off-by: Adalbert Lazăr <ala...@bitdefender.com> > > > > > > > > OK, so this isn't too intrusive to the migration code; and other than > > > > renaming 'start_live_migration_thread' to > > > > 'start_outgoing_migration_thread' I think I'd be OK with this, > > > > > > > > but it might depend what your overall aim is. > > > > > > > > For example, you might be better intercepting each migration_state > > > > change in your notifier, that's much finer grain than just the start of > > > > migration. > > > > > > Thank you, Dave. > > > > > > We want to intercept the live migration and 'block' it while the guest > > > is running (some changes made to the guest by the introspection app has > > > to be undone while the vCPUs are in certain states). > > > > > > I'm not sure what is the best way to block these kind of events > > > (including the pause/shutdown commands). If calling main_loop_wait() > > > is enough (patch [22/26] kvm: vmi: add 'async_unhook' property [1]) > > > then we can drop a lot of code. > > > > > > The use of a notifier will be nice, but from what I understand, we can't > > > block the migration from a notification callback. > > > > Oh, if your intention is *just* to block a migration starting then you > > can use 'migrate_add_blocker' - see hw/9pfs/9p.c for an example where > > it's used and then removed; they use it to stop migration while the fs > > is mounted. That causes an attempt to start a migration to give an > > error (of your choosing). > > One use case is to do VM introspection all the time the guest is running. > From the user perspective, the pause/suspend/shutdown/snapshot/migrate > commands should work regardless if the VM is currently introspected > or not. Our first option was to delay these commands for a couple of > seconds when the VM is introspected, while the introspection app reverts > its changes, without blocking the vCPUs.
Ah OK, so it's not really about blocking it completely; just delaying it a bit; in that case add_blocker is the wrong thing. > I'll see if we can mix the migrate notifier with migrate_add_blocker(), > or add a new migration state. To block the migration (with an error) > is our second option, because the user doing this might not be allowed > to stop the VM introspection. Maybe the right thing is to do something just like MIGRATION_STATUS_WAIT_UNPLUG, it's right near the start of the thread. Again it's job is just to make the migration wait while it does some stuff before it can let migration continue. Dave > Thank you, > Adalbert > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
