Hi Kevin, Ok thanks for the feedback.
Do you have experience with kernel panics and more specifically how to get any meaningful message if this is happening? According to syslog on the guest, at least after reboot, there's no information that something went wrong. Since this seems to leave the qemu world, I'm now not sure where to ask for support in this :( Kind regards, -- Christophe Sent from my iPhone > On 30 Mar 2016, at 14:14, Kevin Wolf <kw...@redhat.com> wrote: > > Hi Christophe, > > Am 30.03.2016 um 13:45 hat Christophe TREFOIS geschrieben: >> Another host went down, so I have to prepare info for this one. >> >> I could not SSH to it anymore. >> Console would show login screen, but no keystrokes were registered. >> >> I could “suspend” the VM and “run” it, but still can’t SSH to it. >> Before suspension, all QEMU threads were around 0%, after resuming, 3 of >> them hover at 100%. >> >> Attached you could find the gdb, core dump, and other logs. >> >> Logs: https://dl.dropboxusercontent.com/u/63261/ubuntu2-logs.tar.gz >> >> Core Dump: https://dl.dropboxusercontent.com/u/63261/core-ubuntu2.tar.gz >> >> Is there anything else we could provide? > > This sounds much like it's not qemu that hangs (because then stopping > and resuming wouldn't work any more), but just the guest OS that is > running inside the VM. > > We've had cases before where qemu was reported to hang with 100% CPU > usage and in the end it turned out that the guest kernel had panicked. > Can you check whether a guest kernel crash could be the cause? If this > is reproducible, maybe the easiest way would be to attach a serial > console to the VM and let the kernel print its messages there. > > Kevin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
