This is an ongoing pain in the hind side. All too often, when I resume my F24 system after a suspend, my QEMU is running away at 100% and my F21 image (that I use for a few apps that I like from F21) is non-responsive.
The only option, so far, has been to force the image off, then restart it, then get everything working again.
It does not matter if I Pause the image or not.
I have not been able to find any telling messages in syslog.
Other than upgrading (I am waiting for F26 to ship, but I will just port the F21 image to the new F26 system), any recommendations? I am at the IEEE 802 conference this week, so I suspend many times during the day as I move between sessions. And next week is IETF with again lots of suspend/resume activity...
Thanks
Bob
On Tue, 11 Jul 2017 13:01:48 +0200 Robert Moskowitz wrote:
The only option, so far, has been to force the image off, then restart it, then get everything working again.
There appear to be a near limitless number of things which systemd doesn't properly wait for at boot time. This may be another. If you really want a virtual machine always running, I'd change the setting to say don't restart at boot, then add something like this to rc.local:
/bin/bash -c 'sleep 20 ; virsh start fedora21' > /dev/null 2>&1 < /dev/null &
That way, it will wait a while after boot, then start the vm when it might run successfully.
My rc.local has about a half dozen things in it I find are far more reliable to start on a delay after booting :-(.
On 07/11/2017 06:15 AM, Tom Horsley wrote:
On Tue, 11 Jul 2017 13:01:48 +0200 Robert Moskowitz wrote:
The only option, so far, has been to force the image off, then restart it, then get everything working again.
There appear to be a near limitless number of things which systemd doesn't properly wait for at boot time. This may be another. If you really want a virtual machine always running, I'd change the setting to say don't restart at boot, then add something like this to rc.local:
It appears you misunderstood the question and turned it into another attack on systemd which is unlikely to be involved here at all. And if you think "systemd" isn't waiting for the right things, then file a bug and get the config files fixed. It's not a problem with systemd itself.
On 07/11/2017 04:01 AM, Robert Moskowitz wrote:
This is an ongoing pain in the hind side. All too often, when I resume my F24 system after a suspend, my QEMU is running away at 100% and my F21 image (that I use for a few apps that I like from F21) is non-responsive.
Is it qemu itself that is stuck or is it the virtual machine? If you look in virt-manager, what does it show for the CPU usage of the F21 system? Is the installed F21 fully updated? It's possible that there's an issue with the sudden time change. Can you switch to a console?
The only option, so far, has been to force the image off, then restart it, then get everything working again.
It does not matter if I Pause the image or not.
I have not been able to find any telling messages in syslog.
All of these suggest that the problem is in the virtual F21 system, not qemu itself.
There's a bug about this issue with that's lingered in a lot of forms for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=1380893
But with my testing, kernel > 4.9 inside the VM fixes the issue. So supported fedora releases in the VM aren't affected anymore. You can work around it by disabling kvmclock for the VM, but I'm not sure what other side effects that will have
- Cole
On 07/12/2017 07:40 PM, Samuel Sieb wrote:
On 07/11/2017 04:01 AM, Robert Moskowitz wrote:
This is an ongoing pain in the hind side. All too often, when I resume my F24 system after a suspend, my QEMU is running away at 100% and my F21 image (that I use for a few apps that I like from F21) is non-responsive.
Is it qemu itself that is stuck or is it the virtual machine? If you look in virt-manager, what does it show for the CPU usage of the F21 system? Is the installed F21 fully updated? It's possible that there's an issue with the sudden time change. Can you switch to a console?
The only option, so far, has been to force the image off, then restart it, then get everything working again.
It does not matter if I Pause the image or not.
I have not been able to find any telling messages in syslog.
All of these suggest that the problem is in the virtual F21 system, not qemu itself. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 07/12/2017 04:48 PM, Cole Robinson wrote:
There's a bug about this issue with that's lingered in a lot of forms for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=1380893
But with my testing, kernel > 4.9 inside the VM fixes the issue. So supported fedora releases in the VM aren't affected anymore. You can work around it by disabling kvmclock for the VM, but I'm not sure what other side effects that will have
The other option would be to try upgrading the kernel in the VM to something 4.9 or higher.
On 07/12/2017 05:03 PM, Samuel Sieb wrote:
On 07/12/2017 04:48 PM, Cole Robinson wrote:
There's a bug about this issue with that's lingered in a lot of forms for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=1380893
But with my testing, kernel > 4.9 inside the VM fixes the issue. So supported fedora releases in the VM aren't affected anymore. You can work around it by disabling kvmclock for the VM, but I'm not sure what other side effects that will have
The other option would be to try upgrading the kernel in the VM to something 4.9 or higher.
I seem to recall an issue with kernels <4.9 and resume operations--VMs or bare metal. IIRC there were two issues. One was in the i915 driver and the second was something about a boffed internal state in one of the timers that caused the slab code to run away or something like that. I sure could be wrong about that. I rarely hibernate/resume my machines so it never bit me. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - When you don't know what to do, walk fast and look worried. - ----------------------------------------------------------------------