Bug 860953
Summary: | F17 + virt-manager + win2008 + qxl drivers + spice = frequent freezes | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Hatton <bugzilla> | ||||||||||
Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 17 | CC: | alevy, amit.shah, berrange, cfergeau, crobinso, dwmw2, hbrock, itamar, jforbes, knoel, pbonzini, rjones, scottt.tw, virt-maint | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | x86_64 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2012-10-17 16:08:11 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Dave Hatton
2012-09-27 07:50:06 UTC
Hi Dave, thanks for the report. Can you post the VM config? sudo virsh dumpxml $vmname What windows version is the guest? Are you using qxl drivers in the guest? Hi Cole, I was using qxl and after finding Bug 750773 I tried using this ... <clock offset="utc"> (change 'utc' to 'localtime' for Windows) <timer name="rtc" tickpolicy="catchup"/> <timer name="pit" tickpolicy="delay"/> </clock> but unfortunately, I still experienced the same freezes. I have recently switched to vmvga which (unscientifically) seems to have improved the situation,but I would rather use qxl as it allows for a higher screen resolution. The windows version is Windows 2008 server R2 Here is the dumpxml <domain type='kvm'> <name>Dave</name> <uuid>e6961d05-dc8f-c67e-6527-3006c37d1d3c</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu current='1'>2</vcpu> <os> <type arch='x86_64' machine='pc-0.14'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/data/VMs/storage-pool-01/Dave-1.img'/> <target dev='hda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='direct'> <mac address='52:54:00:bb:aa:f5'/> <source dev='em1' mode='vepa'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='spice' autoport='yes'/> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </sound> <video> <model type='qxl' vram='65536' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain> Yeah this is likely a qxl related issue, we've had similar problems in the past. Did you install the windows QXL drivers inside the guest, or is it a stock windows 2008 install? Its the QXL driver Red Hat 6.1.0.10012 5/10/2011 I got these from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win-0.1-30.iso I have looked for new versions but couldn't find any. Just for completeness the Guest OS is Windows 2008 server R2 SP1 64bit. Okay, thanks for the info Dave. Reassigning to qemu which is basically what we use for virtio-win issues, as this is either a bug there or in qemu. Alon, heard any reports like this? Sounds similar to the xorg qxl + qemu + virt-manager hangs we had a while back. (In reply to comment #5) > Okay, thanks for the info Dave. Reassigning to qemu which is basically what > we use for virtio-win issues, as this is either a bug there or in qemu. > > Alon, heard any reports like this? Sounds similar to the xorg qxl + qemu + > virt-manager hangs we had a while back. It seems to be the same thing, although without a stacktrace of qemu I can't confirm. But it is supported by the Machine being pc-0.14 which sets the qxl device revision to 2, which is too low and would cause the known freeze because of a deadlock between virt-viewer, qemu & libvirtd. Please: 1. provide a stacktrace of qemu when a freeze happens, before closing virt-viewer. 2. provide version of windows qxl driver used in guest. 3. change machine type to pc-0.15 or manually add to the vm definition (maybe you need this machine type): change the first line to include the qemu namespace: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> add later a qemu:commandline section: <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='qxl-vga.revision=3'/> </qemu:commandline> Alon Created attachment 627235 [details]
qemu stack trace 1
stack trace of qemu during freeze
Created attachment 627237 [details]
qemu stack trace 2
qemu stack trace of freeze
Created attachment 627238 [details]
qemu stack trace 3
qemu stack trace of freeze
Hi Alon, 1. I have attached a some track traces generated during these freezes. 2. The version of the driver is QXL Red Hat 6.1.0.10012 5/10/2011 I got it from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win-0.1-30.iso. 3. I have no reason that I know to use a certain machine type. I wasn't aware that the guest OS (Win Server 2008 R2 SP1 64bit) required a certain machine. I guess this hasn't updated over the years I have used this guest. I'll try the changes in your point three later today. Dave (In reply to comment #10) > Hi Alon, Hi Dave, > > 1. I have attached a some track traces generated during these freezes. > Thanks for that. Only the second matches bug 747011, the third (read()) is not clear to me if it's blocked, and if so I don't know why, and the first looks like the normal state of affairs (epoll & select & kvm ioctl) so I don't understand if you took it in a freeze or just as reference. > 2. The version of the driver is > > QXL Red Hat 6.1.0.10012 5/10/2011 OK, this is new enough to not get freeze for bug 747011 (if this is in fact that one, which I'm not sure yet - at least it is definitely that as well, but maybe you have other issues, we first have to fix 747011 for you by upgrading the versions of the components). > > I got it from > > http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win- > 0.1-30.iso. > > 3. I have no reason that I know to use a certain machine type. It is just the machine type definition in the libvirt xml file, from comment 2 dumpxml: <os> <type arch='x86_64' machine='pc-0.14'>hvm</type> <boot dev='hd'/> </os> > I wasn't aware that the guest OS (Win Server 2008 R2 SP1 64bit) required a > certain machine. I guess this hasn't updated over the years I have used this > guest. > I'll try the changes in your point three later today. OK, great, thanks. > > Dave Hi Alon, 1. All three of the traces were taken whilst the freeze was occurring. For me not only was the guest frozen, but so was the gnome3 desktop. I couldn't type into a terminal on the same workspace or change workspacee, although the ripple effect of Activities was functioning. I had to ALT-CTRL-F2 to take the stack trace. Interestingly, I think the 1st trace had become unfrozen by the time I had taken the stack trace and switched back to gnome3. 3.I carried out the changes and will attach a new dumpxml of the guest. I switched to pc-0.15 and and then switched to pc-1.0 (I assume this was ok to do). At the moment I have yet to have a freeze, so I'm hopeful this is the fix. I'll continue to use the guest today to see if the freeze reoccurs. Can I ask? This is a guest I created some time ago - maybe a year ago. How should I normally update these configuration files as newer versions of qemu/kvm/libvirtd are released? Is there a tool to migrate the machine type that I'm not aware of? Are there other stanzas in the xml that should be altered since I have moved from pc-0.14 to pc-1.0? Thanks Daveh Created attachment 627355 [details]
Dave.xml altered to use pc-1.0
>
> Can I ask? This is a guest I created some time ago - maybe a year ago. How
> should I normally update these configuration files as newer versions of
> qemu/kvm/libvirtd are released? Is there a tool to migrate the machine type
> that I'm not aware of?
> Are there other stanzas in the xml that should be altered since I have moved
> from pc-0.14 to pc-1.0?
>
There is no such tool, we specifically maintain those values in the XML because changing them can cause problems with existing windows installs, like requiring a reactivation. Unfortunately pc-0.14 had a nasty bug which people may carry forever.
I suppose some sort of prompt to fix the machine type could be included in a tool like virt-manager but we would need to fully inform the user about the caveats, not to mention do a lot of testing to figure out exactly what those caveats are.
Hi Cole, Alon, I've been using the guest successfully for a couple of days now and I believe the change to use pc-1.0 has resolved my problem. (I would have expected a freeze by now if it hadn't). Thank you very much for the help. Daveh Thanks Dave, closing as CURRENTRELEASE. (and thanks for chiming in Alon, I hadn't realized that the qxl fix was dependent on machine type). |