Bug 1300165 - Block job progress for drive mirror is missing after active committing &pivoting
Block job progress for drive mirror is missing after active committing &pivoting
Status: CLOSED DUPLICATE of bug 1300209
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-20 00:45 EST by yangyang
Modified: 2016-02-01 11:29 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-01 11:29:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libvirt log (5.62 MB, text/plain)
2016-01-20 00:47 EST, yangyang
no flags Details

  None (edit)
Description yangyang 2016-01-20 00:45:31 EST
Description of problem:
After active committing and pivoting into base image, if mirroring the disk to a destination, no progress was displayed when querying block job

Version-Release number of selected component (if applicable):
libvirt-1.3.1-1.fc24_v1.3.1_rc2.x86_64
qemu-kvm-2.5.0-3.fc24.x86_64

How reproducible:
100%

Steps to Reproduce:
1. prepare a transient domain
# virsh list --transient
 Id    Name                           State
----------------------------------------------------
 12    generic                        running

# virsh domblklist generic
Target     Source
------------------------------------------------
hda        /var/lib/libvirt/images/generic.qcow2

2. take 3 external snapshots
# virsh snapshot-create-as generic --disk-only --no-metadata --diskspec hda,file=/var/lib/libvirt/images/generic.s1
Domain snapshot 1453268106 created
# virsh console generic
dd a file in guest
# dd if=/dev/urandom of=ha bs=1024 count=102400

# virsh snapshot-create-as generic --disk-only --no-metadata --diskspec hda,file=/var/lib/libvirt/images/generic.s2
Domain snapshot 1453268188 created
dd a file in guest
# dd if=/dev/urandom of=haha bs=1024 count=102400

# virsh snapshot-create-as generic --disk-only --no-metadata --diskspec hda,file=/var/lib/libvirt/images/generic.s3
Domain snapshot 1453268204 created
dd a file in guest
# dd if=/dev/urandom of=hahaha bs=1024 count=102400

# virsh domblklist generic
Target     Source
------------------------------------------------
hda        /var/lib/libvirt/images/generic.s3

# qemu-img info /var/lib/libvirt/images/generic.s3 --backing-chain
image: /var/lib/libvirt/images/generic.s3
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 248M
cluster_size: 65536
backing file: /var/lib/libvirt/images/generic.s2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: /var/lib/libvirt/images/generic.s2
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 56M
cluster_size: 65536
backing file: /var/lib/libvirt/images/generic.s1
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: /var/lib/libvirt/images/generic.s1
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 132M
cluster_size: 65536
backing file: /var/lib/libvirt/images/generic.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: /var/lib/libvirt/images/generic.qcow2
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 2.0G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true
    refcount bits: 16
    corrupt: false

3. active commit & pivot
# virsh blockcommit generic hda --active --wait --verbose
Block commit: [100 %]
Now in synchronized phase
[root@fedora_yy ~]# virsh blockjob generic hda
Active Block Commit: [100 %]

[root@fedora_yy ~]# virsh blockjob generic hda --pivot

[root@fedora_yy ~]# virsh domblklist generic
Target     Source
------------------------------------------------
hda        /var/lib/libvirt/images/generic.qcow2

4. block mirror
# virsh blockcommit generic hda --active --wait --verbose
Block commit: [100 %]
Now in synchronized phase

5. query block job 
# virsh blockjob generic hda
No current block job for hda

6. # virsh dumpxml generic | grep disk -a6
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/generic.qcow2'/>
      <backingStore/>
      <mirror type='file' file='/tmp/copy' format='qcow2' job='copy' ready='yes'>
        <format type='qcow2'/>
        <source file='/tmp/copy'/>
      </mirror>
      <target dev='hda' bus='ide'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

Actual results:
In step 5, no progress was displayed

Expected results:
Display progress when querying block job

Additional info:
Comment 1 yangyang 2016-01-20 00:47 EST
Created attachment 1116480 [details]
libvirt log
Comment 2 Han Han 2016-01-20 03:50:14 EST
After step4, I use the qmp-shell to check the blockjob
# systemctl stop libvirtd;
# ~/qemu/scripts/qmp/qmp-shell /var/lib/libvirt/qemu/domain-n1/monitor.sock
Welcome to the QMP low-level shell!
Connected to QEMU 2.5.0

(QEMU) query-block-jobs
{"return": []}

It is sure that qemu-kvm return null from blockjob query. So it's an issue on qemu-kvm not libvirt.
Comment 3 Cole Robinson 2016-01-26 19:37:10 EST
jeff, another blockjob related bit. could it be related to #1300209 ?
Comment 4 Jeff Cody 2016-02-01 11:29:21 EST
(In reply to Cole Robinson from comment #3)
> jeff, another blockjob related bit. could it be related to #1300209 ?

I was able to reproduce this bug, and it has same root cause as bz #1300209.  The posted patch for that bug, fixes this bug as well.

*** This bug has been marked as a duplicate of bug 1300209 ***

Note You need to log in before you can comment on or make changes to this bug.