[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 524447] Re: virsh save is very slow
From: |
Nikola Ciprich |
Subject: |
Re: [Qemu-devel] [Bug 524447] Re: virsh save is very slow |
Date: |
Wed, 7 Jul 2010 19:40:13 +0200 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
Hi, just wanted to report, I just tried libvirt-0.8.2 which should use larger
dd blocksize.
save is still painfully slow, about 1MB/s while host is totally
idle...
regards
nik
On Tue, Jun 22, 2010 at 07:02:08PM -0000, Serge Hallyn wrote:
> Just a note that the 0.8.1 release available in maverick gives me about
> a 50-second save for a 512M memory image (producing 100M outfile). The
> patch listed above and suspected of speeding the saves is not in 0.8.1.
> When I hand-apply just that patch, saves take about 8 seconds, but
> restore fails. Presumably taking the whole of latest git (or 0.8.2
> whenever it is released) will result in both working and fast
> save/restore.
>
> --
> virsh save is very slow
> https://bugs.launchpad.net/bugs/524447
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
>
> Status in libvirt virtualization API: Unknown
> Status in QEMU: Invalid
> Status in “libvirt” package in Ubuntu: Confirmed
> Status in “qemu-kvm” package in Ubuntu: Confirmed
>
> Bug description:
> As reported here:
> http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html
>
> "virsh save" is very slow - it writes the image at around 1MB/sec on my test
> system.
>
> (I think I saw a bug report for this issue on Fedora's bugzilla, but I can't
> find it now...)
>
> Confirmed under Karmic.
>
>
>
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: address@hidden
-------------------------------------
- Re: [Qemu-devel] [Bug 524447] Re: virsh save is very slow,
Nikola Ciprich <=