|Summary:||Windows 10 Guest GUI Freezes Randomly on QEMU/KVM|
|Product:||[Fedora] Fedora||Reporter:||Louis van Dyk <louis>|
|Component:||virt-manager||Assignee:||Cole Robinson <crobinso>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||24||CC:||berrange, charr, crobinso, louis, virt-maint|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-05-10 22:31:40 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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-220.127.116.11-1.fc24.x86_64 libvirt-daemon-18.104.22.168-1.fc24.x86_64 libvirt-daemon-config-network-22.214.171.124-1.fc24.x86_64 libvirt-daemon-driver-interface-126.96.36.199-1.fc24.x86_64 libvirt-daemon-driver-network-188.8.131.52-1.fc24.x86_64 libvirt-daemon-driver-nodedev-184.108.40.206-1.fc24.x86_64 libvirt-daemon-driver-nwfilter-220.127.116.11-1.fc24.x86_64 libvirt-daemon-driver-qemu-18.104.22.168-1.fc24.x86_64 libvirt-daemon-driver-secret-22.214.171.124-1.fc24.x86_64 libvirt-daemon-driver-storage-126.96.36.199-1.fc24.x86_64 libvirt-daemon-kvm-188.8.131.52-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!