Description of problem:
Fresh, unaltered install (except for updates) of Fedora 13. It is taking me over 20 hours to install a RHEL 5.4 guest with the ISO file on the same system as where the image is being installed. I am using a preallocated disk. I am also using SELinux (I am not getting any AVC errors) and BTRFS for my filesystem.
I have verified that kvm_intel.ko is loaded, and that I am using kvm as the hypervisor and not qemu.
I've used kvm before on this very machine under Fedora 11 and had no performance issues with VMs. However, I was also using EXT4 as my filesystem then, so I'm not sure if this is what's causing the bad drop in performance.
Version-Release number of selected component (if applicable):
Every install that I've tried, using RHEL 5.5 and RHEL 5.4 with virtio block devices, performance is terrible. Trying to install takes longer than 20 hours, and after the install is done, trying to run the VM's is painfully slow.
Steps to Reproduce:
1. Install Fedora 13 on a Dell Vostro 1500 laptop with an intel Core 2 Duo processor with 4GB of RAM and a 100GB SATA hard drive
2. Attempt to install a VM in virt-manager
3. Go to bed so that you can sleep while the VM installs.
Extremely slow VM installs and performance after they have installed.
VMs should be much quicker than this.
I'm willing to run any tests or anything, as I'm using this to study for my RHCE.
I reinstalled and chose ext4 as my filesystem, my performance has been greatly improved. Apparently there is something within btrfs that doesn't work too well with raw .img files.
It'd be really good to find out if btrfs is the pertinent factor here.
Same for me, host fedora 13 btrfs, quest fedora 13 minimal img.raw, install takes aprox 45 min (heavy IO in iotop aprox 15MB/s all time). On VirtualBox 5 min.
OK, on host with ext4 install takes 3 min. So it is probably btrfs fault.
I see 99% device utilization on a four disk RAID5 with ~1MB/s writes. This is btrfs on F13 latest patches/kernel as of today. It's affecting others but appears to at least be now, a known issue.
I have terrible disk i/o (no more than 6 MB/s) after upgrading Fedora-12 ->
Fedora13. It is workaround to set cache='none' parameter, but speed is not so good as old one.
Disk performance is not related to used FS: it is the same on ext3/4, UFS, NTFS
on guests. All guest images is located on LVs:
<driver name='qemu' type='raw' cache='none'/>
I suspect this BZ is now superseded by https://bugzilla.redhat.com/show_bug.cgi?id=689127
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.