Opened 9 years ago
Last modified 8 years ago
#15691 new defect
VM stuck when restoring the session
Reported by: | Panos Kavalagios | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 5.1.2 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Linux |
Description
A session that was restored has stuck the entire VM.
Attachments (4)
Change History (22)
by , 9 years ago
comment:1 by , 9 years ago
by , 8 years ago
Attachment: | VBox.2.log added |
---|
by , 8 years ago
Attachment: | VBox.3.log added |
---|
comment:3 by , 8 years ago
Core file obtained. It is currently 2GB. I would need preferably an HTTP way to upload it somewhere.
comment:4 by , 8 years ago
Sorry, I cannot provide you a server for uploading. If you can provide me a URL where to download the core dump from (please compress the file!) then you can contact me via private e-mail at frank _dot_ mehnert _at_ oracle _dot_ com.
comment:5 by , 8 years ago
I have sent you an e-mail with a URL where you can obtain the requested core file. Let me know if that helps.
comment:6 by , 8 years ago
Hi Panos, do you also have the corresponding VBox.log file available? If so, could you attach it to this ticket? Also, on which Linux distribution are you and which version of VBox are you using? Thank you!
comment:7 by , 8 years ago
It is already attached on Dec 29 2016 twice as VBox.2.log and VBox.3.log. I am using Fedora 24 and VirtualBox-5.1-5.1.12_112440_fedora24-1.x86_64.
comment:8 by , 8 years ago
Thank you. I could interprete the core dump. It looks like all 4 VCPUs are executing guest code. In the VM sessions you logged into VBox.log.2 and VBox.log.3 it seems that you started the VM from a saved state, then paused+resumed the VM a few times and finally you powered the VM off -- but the power-off operation did never complete. Is that correct?
comment:9 by , 8 years ago
Somehow the core dump does not fit to VBox.log.2 / VBox.log.3. I think it cannot happen that all 4 VCPUs are executing guest code when the VM is already suspended and powering off.
comment:10 by , 8 years ago
You are right. I have saved the session and when I tried to restore it after a while, the VM stuck. I tried to save it and restore it again to no avail and then I have decided to power it off. The power off succeeded and I was able to boot again the VM.
comment:11 by , 8 years ago
So in other words the core dump is from the state when the VM was stuck but the VBox.log.2/3 files are from the state when you powered-off the VMs, is that correct?
comment:12 by , 8 years ago
The VM was stuck, I generated the core file, power it off and gathered the log file. That was the steps. Does it also create log file during save/restore? If yes, those log file are missing.
I have only uploaded the current VBox.log twice that was translated to VBox.2.log and VBox.3.log in the ticket, hence the confused, because I thought it didn't get uploaded since the current VBox.log in the ticket was old.
comment:13 by , 8 years ago
I have uploaded a new core file with all the related log files. I hope now to be OK.
The scenario was:
- Save state of VM.
- Restore VM.
- The VM stuck and occupies 100% of CPU (all four host CPUs were occupied).
- gcore on VM PID
- Send power off singal
- Collect core and log files and sent them to Frank
comment:14 by , 8 years ago
Thanks again. The core dump shows similar content as the previous one. All 4 VCPUs are executing guest code.
When you say the VM is stuck: Is it possible that you rather see the guest stuck hogging all (virtual) CPUs? The line VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago seems to confirm this assumption.
Please try the following: Disable paravirtualization for this VM (VM setting paravirtualization = None). You need to change this setting when you don't have a saved state for this VM. Any difference?
Also, the log contains information about Guest Additions but I don't see the version mentioned in the log file. Which version is installed in your guest?
comment:15 by , 8 years ago
I confirm that the guest VM is unresponsive by occupying all virtual (probably I can't check that) and host CPUs. Any click on the VM has no effect. Only the Power Off signal from the Close window (x) menu can be used as a workaround to restore the VM (hard reset).
I will try the proposed setting and I will let you know.
I always align the Guest Additions version and they are the same version 5.1.12.
comment:16 by , 8 years ago
I have tried VM setting paravirtualization = None to no avail. The issue still occurs with that setting. The save state feature is not useful if you can't restore the VM and it requires to power it off.
comment:17 by , 8 years ago
This is a serious regression bug, as a whole functionality of Save/Restore is not working in the latest releases.
comment:18 by , 8 years ago
Agreed ... I have several issues when saving / restoring an Ubuntu 16.04 Guest on an Ubuntu 16.04 Host.
Either the mouse cursor becomes invisible on resume (see bug #16380)
Or the whole VM appears frozen ... CPUs are all idle, I have a cursor, but the VM doesn't "do" anything when I move the cursor around.
If I re-suspend / resume the issue remains.
I always have to resort to a VM reset, which is not good :(
Host system CPU also suffers: