1:56 p.m.
Can you please provide the engine and vdsm logs? It might shed some light on why it took
so long.
On Jan 30, 2015 12:43 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
Hello,
Suspending one vm (2 GB RAM) is quite short (about 1 minute) while
restoring it is over 20 minutes... This make the suspend feature unusable.
Is it a regular work?
ovirt 3.5, el6 vdsm 4.16.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:36 p.m.
New subject: restore state is very long after suspending
not very convinient to read the log file...
The vm name is garbin.
Thank you for your help
Le 30/01/2015 11:56, Oved Ourfali a écrit :
Can you please provide the engine and vdsm logs? It might shed some
light on why it took so long.
On Jan 30, 2015 12:43 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
> Hello,
>
> Suspending one vm (2 GB RAM) is quite short (about 1 minute) while
> restoring it is over 20 minutes... This make the suspend feature unusable.
> Is it a regular work?
>
> ovirt 3.5, el6 vdsm 4.16.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
2:04 p.m.
New subject: restore state is very long after suspending
Hi,
----- Original Message -----
From: "Nathanaël Blanchet" <blanchet(a)abes.fr>
To: "Oved Ourfali" <oourfali(a)redhat.com>
Cc: users(a)ovirt.org, "Michal Skrivanek" <mskrivan(a)redhat.com>,
fromani(a)redhat.com
Sent: Friday, January 30, 2015 2:36:49 PM
Subject: Re: [ovirt-users] restore state is very long after suspending
not very convinient to read the log file...
The vm name is garbin.
Thank you for your help
First thing, sorry for long delay, I was traveling last week.
Indeed the VDSM log file seems messed up and somehow tampered (maybe bad copy/paste?)
I can tell that
- reconstructing from the VDSM log, nothing obviously wrong seems there. But we need
a complete clean log to be sure.
- if the operation eventually succeeds, to understand the slowness we must inspect
the QEMU logs (most likely will be unhelpfully terse) and/or investigate QEMU
to understand the behaviour
Bests,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
3573
days inactive
3584
days old
2 comments
3 participants
participants (3)
-
Francesco Romani -
Nathanaël Blanchet -
Oved Ourfali