Bug 1196711
Summary: | block job status is missing when zero-length copy job is in mirroring phase | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Shanzhi Yu <shyu> |
Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | dyuan, eblake, gsun, juzhang, mzhan, pkrempa, rbalakri, yanyang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.3.1-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-03 18:13:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Shanzhi Yu
2015-02-26 15:08:20 UTC
Well, after some debug, seem this is a qemu issue. When guest is in mirror phase, # rpm -q qemu-kvm-rhev libvirt qemu-kvm-rhev-2.2.0-5.el7.x86_64 libvirt-1.2.8-16.el7_1.1.x86_64 # virsh qemu-monitor-command test '{"execute":"query-block-jobs"}' {"return":[{"io-status":"ok","device":"drive-virtio-disk0","busy":false,"len":0,"offset":0,"paused":false,"speed":0,"ready":true,"type":"mirror"}],"id":"libvirt-10"} Both len and offset is 0, which means both info.end and info.cur is 0. so vshPrintJobProgress will print nothing out. .. vshPrintJobProgress(vshDomainBlockJobToString(info.type), info.end - info.cur, info.end); .. static void vshPrintJobProgress(const char *label, unsigned long long remaining, unsigned long long total) { int progress; if (total == 0) /* migration has not been started */ return; .. Try with qemu directly {"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","mode":"absolute-paths","format":"qcow2","target":"/var/lib/libvirt/images/test.copy","sync":"full"}} {"return": {}} {"timestamp": {"seconds": 1425882693, "microseconds": 587594}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-disk0", "len": 0, "offset": 0, "speed": 0, "type": "mirror"}} {"execute":"query-block-jobs"} {"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 0, "offset": 0, "paused": false, "speed": 0, "ready": true, "type": "mirror"}]} (qemu) info block drive-virtio-disk0: /var/lib/libvirt/images/vm3.img (qcow2) {"execute": "block-job-complete", "arguments": { "device": "drive-virtio-disk0"}} {"return": {}} {"timestamp": {"seconds": 1425883294, "microseconds": 349647}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 0, "offset": 0, "speed": 0, "type": "mirror"}} {"execute":"query-block-jobs"} {"return": []} (qemu) info block drive-virtio-disk0: /var/lib/libvirt/images/test.copy (qcow2) Test with qemu-kvm-rhev-2.2.0-5.el7.x86_64 on my local host, did not hit the problem, the most common mirror works correctly: { "execute": "drive-mirror", "arguments": { "device": "drive-virtio-disk0", "target": "/root/sn1", "format": "qcow2", "mode": "absolute-paths", "sync": "full" } } {"return": {}} { "execute" : "query-block-jobs", "arguments" : {} } {"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": true, "len": 5136515072, "offset": 147718144, "paused": false, "speed": 0, "ready": false, "type": "mirror"}]} { "execute" : "query-block-jobs", "arguments" : {} } {"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": true, "len": 5136711680, "offset": 695599104, "paused": false, "speed": 0, "ready": false, "type": "mirror"}]} after steady state, block_job_complete, guest works correctly. Please notice, I use empty qcow2 format file for guest I think I've dabbled with patching this upstream (although the conversation has died down with me still not committing anything yet...): https://www.redhat.com/archives/libvir-list/2015-February/msg00053.html Re-assigning to Eric since he already posted a patch for this. I'll have to see if the situation is still present after Peter's work at: commit faa143912381aa48e33839b194b32cc14d574589 Author: Peter Krempa <pkrempa> Date: Mon Jul 13 17:04:49 2015 +0200 virsh: Refactor block job waiting in cmdBlockCopy Similarly to the refactor of cmdBlockCommit in a previous commit this does the same change for cmdBlockCopy. If so, I'll try and revive my earlier patch. (In reply to Eric Blake from comment #7) > I'll have to see if the situation is still present after Peter's work at: > commit faa143912381aa48e33839b194b32cc14d574589 > Author: Peter Krempa <pkrempa> > Date: Mon Jul 13 17:04:49 2015 +0200 > > virsh: Refactor block job waiting in cmdBlockCopy > > Similarly to the refactor of cmdBlockCommit in a previous commit this > does the same change for cmdBlockCopy. > > If so, I'll try and revive my earlier patch. Eric, This still happen with v1.2.18-33-g6da3b69. So need your earlier patch. It's still not fixed since the bug is only in the percentage display function in virsh which wasn't touched. The function expects some progress to display the state so we will need to work it around. commit 7acfb940f712980415e82a46a7de7adb11163a10 Author: Peter Krempa <pkrempa> Date: Fri Sep 11 21:34:24 2015 +0200 virsh: Fix job status indicator for 0 length block jobs Although 0 length block jobs aren't entirely useful, the output of virsh blockjob is empty due to the condition that suppresses the output for migration jobs that did not start. Since the only place that actually uses the condition that suppresses the output is in migration, let's move the check there and thus add support for 0 of 0 equaling to 100%. Verified on libvirt-1.3.1-1.el7.x86_64 Steps 1. Prepare a transient guest # virsh create r7.xml Domain r7 created from r7.xml 2. Do blockcopy job # virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --verbose --wait Now in mirroring phase Note: vda is an empty disk 3. Check job status by blockjob # virsh blockjob r7 vda Block Copy: [100 %] Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2577.html |