Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #950416 +++
Remove comments that not related this bug , make up the needinfo
--- Additional comment from time.su on 2013-10-25 03:46:34 EDT ---
Test with:
libvirt-1.1.1-10.el7.x86_64
qemu-kvm-1.5.3-10.el7.x86_64
The comments 10's steps are okay for me , also test the raw img.
But , the vol-download's speed will down to too slow when the image large enough (1G in my environment)
#time virsh vol-download --vol vol-test.img --pool default --file /home/test1/a
real 1m56.311s
user 1m24.267s
sys 0m2.743s
And the 500M's volumes time:
real 0m19.033s
virsh # vol-dumpxml vol-test.img --pool default
<volume>
<name>vol-test.img</name>
<key>/var/lib/libvirt/images/vol-test.img</key>
<source>
</source>
<capacity unit='bytes'>1048576000</capacity>
<allocation unit='bytes'>1048580096</allocation>
<target>
<path>/var/lib/libvirt/images/vol-test.img</path>
<format type='raw'/>
<permissions>
<mode>0600</mode>
<owner>0</owner>
<group>0</group>
<label>system_u:object_r:virt_image_t:s0</label>
</permissions>
<timestamps>
<atime>1382683904.221608140</atime>
<mtime>1382683904.144609566</mtime>
<ctime>1382683904.145609548</ctime>
</timestamps>
</target>
</volume>
ll /home/test1/
total 63484
-rw-r--r--. 1 root root 65005760 Oct 25 14:53 a
# ll /home/test1/a
-rw-r--r--. 1 root root 133943320 Oct 25 14:53 /home/test1/a
# ll /home/test1/a
-rw-r--r--. 1 root root 152029600 Oct 25 14:53 /home/test1/a
.........
-rw-r--r--. 1 root root 853136008 Oct 25 14:54 /home/test1/a
# ll /home/test1/a
-rw-r--r--. 1 root root 853987976 Oct 25 14:54 /home/test1/a
# ll /home/test1/a
-rw-r--r--. 1 root root 854643336 Oct 25 14:54 /home/test1/a
Is it related libvirt ?
--- Additional comment from time.su on 2013-10-30 04:25:22 EDT ---
BTW , also reproduced it on rhel6.
1.
And in the second time , the speed can be accepted if the target is same .
# time virsh vol-download --vol test.img --pool default --file /home/a
real 3m38.059s
user 3m32.044s
sys 0m2.489s
# time virsh vol-download --vol test.img --pool default --file /home/a
real 0m10.085s
user 0m1.719s
sys 0m2.323s
# time virsh vol-download --vol test.img --pool default --file /home/b ;;cancel
^C
real 1m49.476s
user 1m45.474s
sys 0m1.921s
2.
During the process , virsh will use almost 100% CPU , watched via top
KiB Mem: 7364840 total, 4982532 used, 2382308 free, 126120 buffers
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28663 root 20 0 628020 312468 4784 R 98.3 4.2 0:48.99 virsh
/*HERE*/
--- Additional comment from Osier Yang on 2013-10-30 09:58:56 EDT ---
(In reply to time.su from comment #19)
> Test with:
> libvirt-1.1.1-10.el7.x86_64
> qemu-kvm-1.5.3-10.el7.x86_64
>
>
> The comments 10's steps are okay for me , also test the raw img.
> But , the vol-download's speed will down to too slow when the image large
> enough (1G in my environment)
>
> #time virsh vol-download --vol vol-test.img --pool default --file
> /home/test1/a
>
> real 1m56.311s
> user 1m24.267s
> sys 0m2.743s
>
> And the 500M's volumes time:
> real 0m19.033s
>
> virsh # vol-dumpxml vol-test.img --pool default
> <volume>
> <name>vol-test.img</name>
> <key>/var/lib/libvirt/images/vol-test.img</key>
> <source>
> </source>
> <capacity unit='bytes'>1048576000</capacity>
> <allocation unit='bytes'>1048580096</allocation>
> <target>
> <path>/var/lib/libvirt/images/vol-test.img</path>
> <format type='raw'/>
> <permissions>
> <mode>0600</mode>
> <owner>0</owner>
> <group>0</group>
> <label>system_u:object_r:virt_image_t:s0</label>
> </permissions>
> <timestamps>
> <atime>1382683904.221608140</atime>
> <mtime>1382683904.144609566</mtime>
> <ctime>1382683904.145609548</ctime>
> </timestamps>
> </target>
> </volume>
>
>
> ll /home/test1/
> total 63484
> -rw-r--r--. 1 root root 65005760 Oct 25 14:53 a
> # ll /home/test1/a
> -rw-r--r--. 1 root root 133943320 Oct 25 14:53 /home/test1/a
> # ll /home/test1/a
> -rw-r--r--. 1 root root 152029600 Oct 25 14:53 /home/test1/a
> .........
> -rw-r--r--. 1 root root 853136008 Oct 25 14:54 /home/test1/a
> # ll /home/test1/a
> -rw-r--r--. 1 root root 853987976 Oct 25 14:54 /home/test1/a
> # ll /home/test1/a
> -rw-r--r--. 1 root root 854643336 Oct 25 14:54 /home/test1/a
>
>
>
> Is it related libvirt ?
I think it's not related with libvirt, but I also have no idea why it becomes slow in the end of the transfering (when we talked f2f, time said that for a 1G volume, it becomes slow about at the point of 800M, before that it just looks fine), Dan, I think you are the more appropriate person for this question?
Needinfo per osier's comment
"I think it's not related with libvirt, but I also have no idea why it becomes slow in the end of the transfering (when we talked f2f, time said that for a 1G volume, it becomes slow about at the point of 800M, before that it just looks fine), Dan, I think you are the more appropriate person for this question?"
(In reply to time.su from comment #0)
> And in the second time , the speed can be accepted if the target is same .
>
> # time virsh vol-download --vol test.img --pool default --file /home/a
> real 3m38.059s
> user 3m32.044s
> sys 0m2.489s
>
> # time virsh vol-download --vol test.img --pool default --file /home/a
> real 0m10.085s
> user 0m1.719s
> sys 0m2.323s
>
> # time virsh vol-download --vol test.img --pool default --file /home/b
> ;;cancel
> ^C
> real 1m49.476s
> user 1m45.474s
> sys 0m1.921s
If the cache effects make the problem go away, this is not a libvirt bug.
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