Bug 1031232

Summary: Console content often corrupted (overlaid on content from previous boots)
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: berrange, crobinso, kparal, 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: 2013-11-16 21:07:43 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:
Attachments:
Description Flags
screenshot of virt-manager showing the issue, booting an F20 live image
none
screenshot of spicy connected to the same VM from the v-m screenshot, seconds later - no corruption none

Description Adam Williamson 2013-11-16 01:01:13 UTC 
During F20 testing, both Kamil Paral and myself have noticed that the console output for our test VMs is often corrupted. It looks like content from the current boot is overlaid over content from previous boots, sometimes in garbled form (the old content, not the new). This is with F20 guests on F20 hosts.

If I start up a guest in virt-manager and leave it sitting at a corrupted console display - like the bootloader screen - then connect to the same VM with spicy, the corruption does not appear. So it seems like a virt-manager issue.

I'll attach screenshots.
Comment 1 Adam Williamson 2013-11-16 01:02:28 UTC 
Created attachment 824761 [details]
screenshot of virt-manager showing the issue, booting an F20 live image
Comment 2 Adam Williamson 2013-11-16 01:03:11 UTC 
Created attachment 824762 [details]
screenshot of spicy connected to the same VM from the v-m screenshot, seconds later - no corruption
Comment 3 Cole Robinson 2013-11-16 21:07:43 UTC 

*** This bug has been marked as a duplicate of bug 1017955 ***