Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, May 25, 2010 at 11:33:15AM -0500, Anthony Liguori wrote:
> On 05/25/2010 11:25 AM, Daniel P. Berrange wrote:
> >  With some disk locking
> >approaches we need todo a lock transfer before allowing the dest
> >to continue running.
> 
> QEMU is going to read the disk before the migration completes so the 
> lock transfer is not going to work with the current implementation (it 
> needs to read the disk to do probing).  I assume this is not something 
> that's actually been implemented.

Lock transfer upon migration is a two-phase process. When the QEMU
process for incoming migration starts a shared lock is held. Upon
completion of migration an attempt is made to upgrade this to an
exclusive lock. Only if this upgrade succeeds the dest is allowed 
to start running. 

> >  It could be optimized to avoid the -S /cont
> >in cases where those two scenarios aren't relevant, but only if
> >we can get a separate async notification of when migration starts
> >and completes on the destination, so we can notify mgmt apps that
> >need this lifecycle event.
> >   
> 
> Migration completes == guest starts running.  You'll get a notification 
> of that but you're not getting that now because you're doing -S which 
> I'd argue is a functional problem on the part of libvirt (you're 
> breaking the downtime contract).

If doing non-live migration, or restoring a saved image which was
originally in the paused state, there is no 'guest starts running'
event. You cannot reliably infer that migration completed by looking
for a RESUME event. Hence the need for an explicit notification
for the end of migration events.

> I'm not sure why you would need a notification of when migration starts 
> (since you know when you've started migration).

The destination only knows that it has started a QEMU instance ready
for incoming migration. It doesn't know when / if an incoming migration
has actually been accepted & started processing. Hence the need for an
explicit notification for the start of migration.


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|