Bug 856247
| Summary: | full RHEL 6.4 block-copy support | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Federico Simoncelli <fsimonce> | |
| Component: | libvirt | Assignee: | Eric Blake <eblake> | |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | high | |||
| Version: | 6.3 | CC: | acathrow, ajia, dallan, dyasny, dyuan, eblake, jdenemar, jpallich, juzhang, kchamart, mzhan, rwu, zpeng | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | libvirt-0.10.2-5.el6 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: RHEL 6.3 picked up an early version of block copy, prior to upstream acceptance of the feature. In the time since then, several improvements were made to the upstream feature.
Consequence: Older libvirt was unable to fully manage the block copy features present in this release of qemu.
Fix: The block copy code was finally approved upstream in both qemu and libvirt, and then libvirt was improved to work around the differences in the early implementation so that it can now work with all of RHEL 6.3, RHEL 6.4, and upstream qemu implementations.
Result: Block copy as a means of backing up the disk images of a running domain is more powerful, and has been tested to have no regressions over the support available in RHEL 6.3.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 871055 888426 (view as bug list) | Environment: | ||
| Last Closed: | 2013-02-21 07:23:25 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: | ||||
| Bug Depends On: | 772088, 837787 | |||
| Bug Blocks: | 860720, 871055, 888426 | |||
|
Description
Federico Simoncelli
2012-09-11 14:53:19 UTC
Hi Federico:
Would you help tell me whick qemu-kvm build you used? I want to reproduce this issue on rhel6.3.z, i try qemu-kvm-rhev-0.12.1.2-2.295.el6_3.2 and qemu-kvm-0.12.1.2-2.295.el6_3.2, they all not support block jobs, thanks in advance.
(In reply to comment #2) > Hi Federico: > > Would you help tell me whick qemu-kvm build you used? I want to > reproduce this issue on rhel6.3.z, i try > qemu-kvm-rhev-0.12.1.2-2.295.el6_3.2 and qemu-kvm-0.12.1.2-2.295.el6_3.2, > they all not support block jobs, thanks in advance. qemu-kvm-rhev-0.12.1.2-2.312.el6.x86_64 Hi Fedrico,
Thanks you for your quickly response, but i still have a question about this issue, as i know, issue a blockRebase need use virsh command "blockcopy",but now,this cmd can't be used in libvirt,refer this bug: https://bugzilla.redhat.com/show_bug.cgi?id=837583, so i want to know how can reproduce this ,please give me some advice for it ,very thanks. If the feature add-in build again, i will use virsh command to try this again.
# vgcreate vgtest1 /dev/mapper/1IET_00010001
# lvcreate -n lvbaseimg1 -L 1G vgtest1
# lvcreate -n lvbaseimg2 -L 1G vgtest1
# lvcreate -n lvleafimg1 -L 1G vgtest1
# lvcreate -n lvleafimg2 -L 1G vgtest1
# qemu-img create -f qcow2 -F raw -b /dev/vgtest1/lvbaseimg1 /dev/vgtest1/lvleafimg1
# qemu-img create -f qcow2 -F raw -b /dev/vgtest1/lvbaseimg2 /dev/vgtest1/lvleafimg2
# cat > vm1.xml <<EOF
<domain type="kvm">
<name>vm1</name>
<memory>131072</memory>
<devices>
<disk device="disk" type="block">
<source dev="/dev/vgtest1/lvleafimg1"/>
<target bus="ide" dev="hda"/>
<driver name="qemu" type="qcow2"/>
</disk>
</devices>
<os>
<type arch="x86_64" machine="pc">hvm</type>
</os>
</domain>
EOF
# for i in /dev/vgtest1/lv*; do chgrp -v qemu $(readlink -f $i); done
# virsh blockcopy --shallow --reuse-external --wait vm1 /dev/vgtest1/lvleafimg1 /dev/vgtest1/lvleafimg2
# virsh blockjob --pivot vm1 /dev/vgtest1/lvleafimg1
error: internal error unable to execute QEMU command '__com.redhat_drive-reopen': Could not open '/dev/vgtest1/lvleafimg2'
Hi Fedrico,
very thanks, i can reproduce this now by your steps.
build:
libvirt-0.9.10-21.el6_3.4.x86_64
qemu-kvm-rhev-0.12.1.2-2.312.el6.x86_64
> Sadly the relabeling happens at blockcopy time instead of blockjob-pivot
> time and if the lv gets deactivated before the pivoting (there's actually a
> flow in rhev where this happens) then the switch is still failing:
Yep, I realized that overnight as well - I have to label at two different points for this to work correctly - flat label at copy start, and recursive label at pivot time. Let me work up a v2 patch.
For 6.3.z: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-September/msg00561.html For 6.4, either this series will be picked up in time for 0.10.2 (in which case the rebase will move it into POST): https://www.redhat.com/archives/libvir-list/2012-September/msg01122.html or I will have to supply that series as a RHEL-only patch. I talked to Eric Blake, and his changes for bug 856247 cover the libvirt side. (In reply to comment #18) > I talked to Eric Blake, and his changes for bug 856247 cover the libvirt > side. Urgh, wrong BZ, sorry for the noise. 6.3.z will be in POST with: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-September/msg00674.html 6.4 in POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-September/msg00701.html The version in comment 23 needs a respin, moving back to assigned until I post the next version. I got another report from Federico today about a failure message of 'requires an active copy job', so there probably is a real data race that needs to be solved before the RHEL 6.4 release. I'm looking into it further today. I'll go ahead and clone a new bug tracking the 'requires an active copy job' issue, to avoid holding up validation of the rest of the block-copy feature. verify with build:
libvirt-0.10.2-14.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64
step:
# vgcreate vgtest1 /dev/mapper/1IET_00010001
# lvcreate -n lvbaseimg1 -L 1G vgtest1
# lvcreate -n lvbaseimg2 -L 1G vgtest1
# lvcreate -n lvleafimg1 -L 1G vgtest1
# lvcreate -n lvleafimg2 -L 1G vgtest1
# qemu-img create -f qcow2 -F raw -b /dev/vg_virt/lvbaseimg1 /dev/vg_virt/lvleafimg1
# qemu-img create -f qcow2 -F raw -b /dev/vg_virt/lvbaseimg2 /dev/vg_virt/lvleafimg2
# cat > vm1.xml <<EOF
<domain type="kvm">
<name>vm1</name>
<memory>131072</memory>
<devices>
<disk device="disk" type="block">
<source dev="/dev/vg_virt/lvleafimg1"/>
<target bus="ide" dev="hda"/>
<driver name="qemu" type="qcow2"/>
</disk>
</devices>
<os>
<type arch="x86_64" machine="pc">hvm</type>
</os>
</domain>
EOF
# for i in /dev/vg_virt/lv*; do chgrp -v qemu $(readlink -f $i); done
S1:
#virsh create vm1.xml
# virsh blockcopy --shallow --reuse-external --wait vm1 /dev/vg_virt/lvleafimg1 /dev/vg_virt/lvleafimg2
Now in mirroring phase
#for i in /dev/vg_virt/lv*; do ls -Z $(readlink -f $i); done
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-0
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-1
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-2
brw-rw----. root root system_u:object_r:fixed_disk_device_t:s0 /dev/dm-3
make sure blockjob in phase two
#virsh blockjob --info vm1 /dev/vg_virt/lvleafimg1
Block Copy: [100 %]
# virsh blockjob --pivot vm1 /dev/vg_virt/lvleafimg1
no error display
# for i in /dev/vg_virt/lv*; do ls -Z $(readlink -f $i); done
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-0
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-1
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c538,c961 /dev/dm-2
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c538,c961 /dev/dm-3
#virsh dumpxml vm1
.....
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2'/>
<source dev='/dev/vg_virt/lvleafimg2'/>
<target dev='hda' bus='ide'/>
.....
worked as expect
S2:
#virsh create vm1.xml
# virsh blockcopy --shallow --reuse-external --wait vm1 /dev/vg_virt/lvleafimg1 /dev/vg_virt/lvleafimg2
Now in mirroring phase
#for i in /dev/vg_virt/lv*; do ls -Z $(readlink -f $i); done
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-0
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-1
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-2
brw-rw----. root root system_u:object_r:fixed_disk_device_t:s0 /dev/dm-3
# lvchange -an /dev/vg_virt/lvbaseimg2
# lvchange -ay /dev/vg_virt/lvbaseimg2
# for i in /dev/vg_virt/lv*; do ls -Z $(readlink -f $i); done
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-0
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-1
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-2
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-3
# virsh blockjob --pivot vm1 /dev/vg_virt/lvleafimg1
no error display
# for i in /dev/vg_virt/lv*; do ls -Z $(readlink -f $i); done
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-0
brw-rw----. qemu qemu system_u:object_r:virt_content_t:s0 /dev/dm-1
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-2
brw-rw----. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c256,c359 /dev/dm-3
#virsh dumpxml vm1
.....
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2'/>
<source dev='/dev/vg_virt/lvleafimg2'/>
<target dev='hda' bus='ide'/>
.....
verification passed.
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. http://rhn.redhat.com/errata/RHSA-2013-0276.html |