Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1362538 - Windows 10 Guest GUI Freezes Randomly on QEMU/KVM
Summary: Windows 10 Guest GUI Freezes Randomly on QEMU/KVM
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-02 13:06 UTC by Louis van Dyk
Modified: 2017-05-11 10:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-10 22:31:40 UTC


Attachments (Terms of Use)

Description Louis van Dyk 2016-08-02 13:06:06 UTC
Description of problem:
On Fedora 23 and now also on Fedora 24 x86_64, my Windows 10 Guest (also 64 bit) will work for a randon time, and then the GUI will freeze.  I am able to ping the Guest, and map drives to it and read and write files.  However, the GUI is completely locked up and never recovers.  I have thought it is more likely to happen when the browser is open (Edge, and also occasionally with IE), but I cannot be certain of that.

Version-Release number of selected component (if applicable):
Please note that it did this on Fedora 23 as well ...

My GUEST was originally set up as a Windows 8.1 device, and was upgraded to Windows 10.  I have not changed any VM settings.

I have installed all Guest Drivers from virtio-win-0.1.118.iso

The RPMs installed on the host are:
libvirt-client-1.3.3.2-1.fc24.x86_64
libvirt-daemon-1.3.3.2-1.fc24.x86_64
libvirt-daemon-config-network-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-interface-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-network-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-nodedev-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-nwfilter-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-qemu-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-secret-1.3.3.2-1.fc24.x86_64
libvirt-daemon-driver-storage-1.3.3.2-1.fc24.x86_64
libvirt-daemon-kvm-1.3.3.2-1.fc24.x86_64
libvirt-gconfig-0.2.3-2.fc24.x86_64
libvirt-glib-0.2.3-2.fc24.x86_64
libvirt-gobject-0.2.3-2.fc24.x86_64
libvirt-python-1.3.3-3.fc24.x86_64
qemu-common-2.6.0-5.fc24.x86_64
qemu-guest-agent-2.6.0-5.fc24.x86_64
qemu-img-2.6.0-5.fc24.x86_64
qemu-kvm-2.6.0-5.fc24.x86_64
qemu-system-x86-2.6.0-5.fc24.x86_64
virtio-win-0.1.118-2.noarch
virt-manager-1.4.0-3.fc24.noarch
virt-manager-common-1.4.0-3.fc24.noarch
virtuoso-opensource-6.1.6-10.fc23.x86_64


How reproducible:
It is random.


Steps to Reproduce:
1.
2.
3.

Actual results:
The GUI freezes.  I can map drives and access the file system via the network.  I usually have to issue the "virsh destroy" command, and restart.

Expected results:
The GUI should never freeze.


Additional info:

Comment 1 Cole Robinson 2017-03-12 17:54:03 UTC
Hi Louis, sorry this didn't receive an earlier response. Are you still seeing this with latest packages?

Comment 2 Cameron Harr 2017-03-20 20:45:39 UTC
We have seen similar issues with multiple Windows2008 VMs since some time last year. Host is running RHEL 6.7-6.8. Freezes may be hours to weeks apart. A network load seems to be a catalyst, but that's circumstantial. 

When freezes happen, there are no errors in /var/log/messages or the VM log in /var/libvirt/qemu/. Dmesg does show a number of audit messages followed by interfaces being disabled and then placed back into forwarding mode:
...
type=1305 audit(1489488122.464:465816): audit_pid=0 old=233826 auid=0 ses=65179 res=1
type=1305 audit(1489488122.544:465817): audit_enabled=0 old=1 auid=0 ses=67201 res=1
type=1305 audit(1489488122.550:465818): audit_pid=2685 old=0 auid=0 ses=67201 res=1
br1505: port 2(vnet0) entering disabled state
device vnet0 left promiscuous mode
br1505: port 2(vnet0) entering disabled state
br1400: port 2(vnet1) entering disabled state
device vnet1 left promiscuous mode
br1400: port 2(vnet1) entering disabled state
device vnet0 entered promiscuous mode
br1505: port 2(vnet0) entering forwarding state
device vnet1 entered promiscuous mode
br1400: port 2(vnet1) entering forwarding state
vnet1: no IPv6 routers present
vnet0: no IPv6 routers present
br1505: port 2(vnet0) entering forwarding state
br1400: port 2(vnet1) entering forwarding state
type=1305 audit(1489574942.232:479995): audit_pid=0 old=2685 auid=0 ses=67201 res=1
type=1305 audit(1489574942.312:479996): audit_enabled=0 old=1 auid=0 ses=69210 res=1
type=1305 audit(1489574942.319:479997): audit_pid=36710 old=0 auid=0 ses=69210 res=1
...

While the VM is frozen, I can get some ARP communication from it, but nothing else. From the host, I can ping other hosts on the same subnet, so my hypothesis is the virtual interfaces on the VM have gone out to lunch.

Comment 3 Cole Robinson 2017-03-20 20:51:25 UTC
Cameron, RHEL6 host virt is drastically different than a Fedora virt host at this point, so it's more appropriate to file a bug like that against RHEL, there's a good chance they are not the same issue

Comment 4 Cameron Harr 2017-03-20 21:02:56 UTC
Cole,
My apologies, you are right. I was looking at so many issues I didn't realize this one was Fedora-based.

Comment 5 Louis van Dyk 2017-05-11 10:15:44 UTC
Hi Cole

Somehow I missed the needinfo.  No, I haven't noticed this in so long I'd actually forgotten about it.  Thanks for all your tireless efforts!


Note You need to log in before you can comment on or make changes to this bug.