Bug 697813

Description of problem:
Break migration during migrating, unexpected error is caused

Version-Release number of selected component (if applicable):
- libvirt-0.8.7-7.el6.x86_64
- kernel-2.6.32-113.el6.x86_64
- qemu-kvm-0.12.1.2-2.146.el6.x86_64


How reproducible:
always

Scenario 1: Very quickly press ctrl+c after executing migration command
Test step
1. On source
# virsh migrate --live rhel61_i386_1 qemu+ssh://10.66.65.132/system
^Cerror: Requested operation is not valid: no job is active on the domain
error: Reconnected to the hypervisor

Acutal result
1. On source host
The guest is in running status and works well
# virsh list --all
 Id Name                 State
----------------------------------
  9 6z                   running
 16 rhel61_i386_1        running

On target host
The guest is in paused status and cannot destroy it
# virsh list --all
 Id Name                 State
----------------------------------
 88 rhel61_i386_1        paused
# virsh destroy rhel61_i386_1
error: Failed to destroy domain rhel61_i386_1
error: Timed out during operation: cannot acquire state change lock

Expected result
It looks like the virsh
code gives up at this point - it should probably continue, and let the user
press Ctrl-C again, at which point we'd be in Step 2 and it would work.


Scenario 2: After executing migration command for about 2 seconds, surely
before the migration is finished, press ctrl+c
Test step
1. On source host
# virsh migrate --live rhel61_i386_2 qemu+ssh://10.66.65.132/system
^Cerror: operation failed: migration job: canceled by client
error: Reconnected to the hypervisor

Actual result
1. On source host
The guest is in running status but could see I/O error and the guest becomes a
read-only system (please refer to rhel61_i386_2.png)
# virsh list --all
 Id Name                 State
----------------------------------
  9 6z                   running
 16 rhel61_i386_1        running
 17 rhel61_i386_2        running

On target host
No this guest

Expected result
No error is caused to guest on source host

Note: 
no /var/log/message for both scenario