[libvirt] libvirt commands during migration

[Daniel P. Berrange]

On Thu, May 05, 2011 at 03:50:56PM +0300, Dan Kenigsberg wrote:
> Hi,
> 
> We've noticed that most of libvirt domain-specific calls block while
> qemu is migrating.
> 
> Isn't it kind-of-a-bug? Migration can take a while; qemu allows to do it
> in the background, and accepts monitor commands. So why should a libvirt
> user be blocked from his favorite domblkstat?

Yes & no.  While QEMU allows all monitor commands, it is not safe to
use all of them. In addition, on the destination host, the QEMU monitor
is completely non-responsive as long as migration is running which is
a real PITA because it prevents us monitoring progress from the target
host :-(

In general any libvirt operation which may result in a change of VM
state, will acquire the 'job lock'. The effect is basically to
serialize monitor commands. Normally this is fine, but the migration
API is special because it is a long running command. Currently we
hold the job lock for the entire duration of migration, and have a
special case to allow certain migration related API calls (to change
bandwidth limits, max downtime, pause the VM, cancel and get migrate
status). Basically we're conservative in what we allow to be done
during migration, to try avoid unexpected consequences/failure.

So Further APIs / monitor commands have to be considered on a case by
case basis to make sure it is safe to use them. We could easily allow
the block stats call via the same special case mechanism we have since
that is clearly ok as a readonly operation. Long term it'd be desirable
to get a more general solution to mark further APIs as migration safe,
without needing special case code.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|