Could you point out some docs about it?
See nova.virt.libvirt.driver:LibvirtDriver.pre_live_migrate - the code path for "if not is_shared_storage".
http://www.sebastien-han.fr/blog/2012/07/12/openstack-block-...
Note that there are some reliability issues using versions prior to qemu-1.4 and libvirt 1.0.2
To enable "true" block migration where the server remains live the whole time instead of being paused, you need to modify a config option:
block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC,VIR_MIGRATE_LIVE
(this adds VIR_MIGRATE_LIVE to the default flags)
Also, keep in mind the same caveats to regular live migration with this flag in that there are edge cases where the i/o in the guest is so great that the migration will never complete.
You could also put the instances directory on a shared network drive - you don't have to wait for the copy then.
MAC doesn't have to change, but the upstream router still needs to be notified about the new location of your instance. That's why nova sends the gratuitous arp packet (more than one actually since they are not guaranteed). At least that's the case for the old networking model. Not sure what's needed for quantum updates, but that will require at least one RabbitMQ message on Nova's side and an HTTP request to Quantum.
Another way to explain the problem: you can write to local memory faster than you can move those changes to another host over the network. Any application heavily processing the data and using all available memory will make memory pages dirty faster than it takes qemu to move them across to the next host. The result is that your instance has to be paused until the copying process completes (unless you're running on a non-standard architecture). Otherwise the copy would never complete.