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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list