On 03/23/2013 06:42 AM, Thomas Knauth wrote:
> Hi Eric,
>
> thanks for the reply. This indeed solved my issue. Suspending is much
> faster without the artificial throttle.
>
> On a related note: I'm curious about the baseline resume latency. It takes
> about 5 seconds to resume an instance with a
Hi Eric,
thanks for the reply. This indeed solved my issue. Suspending is much
faster without the artificial throttle.
On a related note: I'm curious about the baseline resume latency. It takes
about 5 seconds to resume an instance with a tiny amount of state (500 MB
dump size). The data is all i
On 03/20/2013 04:44 PM, Thomas Knauth wrote:
> Hi Stefan,
>
> thanks for taking the time to reply.
>
> On Wed, Mar 20, 2013 at 9:11 AM, Stefan Hajnoczi wrote:
>
>> Which QEMU or libvirt command are you using to suspend the guest to
>> disk?
>>
>
> virsh save
Then this is as much a libvirt q
Hi Stefan,
thanks for taking the time to reply.
On Wed, Mar 20, 2013 at 9:11 AM, Stefan Hajnoczi wrote:
> Which QEMU or libvirt command are you using to suspend the guest to
> disk?
>
virsh save
> Why do you say it is CPU-bound? Did you use a tool like vmstat or
> simply because it does 3
On Tue, Mar 19, 2013 at 05:24:59PM +0100, Thomas Knauth wrote:
> lately I've been playing around with qemu's/kvm's suspend (to disk) and
> resume. My initial expectation was that both operations are I/O bound. So
> it surprised me to see that suspend to disk seems to be CPU-bound.
> Suspending a VM
Dear all,
lately I've been playing around with qemu's/kvm's suspend (to disk) and
resume. My initial expectation was that both operations are I/O bound. So
it surprised me to see that suspend to disk seems to be CPU-bound.
Suspending a VM with 1.5 GB memory takes 55 seconds. This works out to less
