On Fri, 19 Oct 2012 05:27:29 -0400 (EDT) Paolo Bonzini <pbonz...@redhat.com> wrote:
> > What happens is that a stop command while in INMIGRATE state will just > > be ignored. Actually, any stops while in a state that pauses vCPUs > > are ignored. > > > > Also, I don't understand what you meant by "racy", care to elaborate? > > Case 1: Case 2: > user runs qemu -incoming -S user runs qemu -incoming -S > source connects cont command received > cont command received source connects > > In case 1, the VM is resumed at the end of migration, in case 2 it > is not and an error is reported on QMP. After this patch, it is always > resumed. > > Case 1: Case 2: > user runs qemu -incoming user runs qemu -incoming > source connects stop command received > stop command received source connects > > In case 1, the VM runs for a blink of an eye and then stops. In case > 2 it just starts, with no error reported. > > > > In addition, there's nothing that really prevents the user from > > > typing the block device's passwords before incoming migration is > > > done, so we may as well allow that. > > > > Have you tried it? We seem to support that already. > > With HMP yes, with QMP no. You just get "An incoming migration is > expected before this command can be executed" and no clue that disks > are encrypted. We could move the bdrv_iterate() calls before the RUN_STATE_INMIGRATE check in qmp_cont(), but if this patch fixes all the cases you mention then let's just apply it.
