Bug 973374 - qemu screenshots broken for F19 Beta guests
qemu screenshots broken for F19 Beta guests
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alon Levy
Fedora Extras Quality Assurance
RejectedBlocker RejectedFreezeException
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-11 15:33 EDT by Zeeshan Ali
Modified: 2016-09-19 21:42 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-03 10:30:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 64714 None None None Never

  None (edit)
Description Zeeshan Ali 2013-06-11 15:33:45 EDT
Downstream bug for: https://bugs.freedesktop.org/show_bug.cgi?id=64714

There doesn't seem to be a component for QXL here so filing it on spice.
Comment 1 Adam Williamson 2013-06-11 19:24:28 EDT
For blocker voting purposes: there's some rationale in the upstream bug, apparently without a client side fix for this, Boxes and virt-screenshot won't ever be able to take proper screenshots of F19-stable-release package set guests (so, for e.g., a VM running the F19 live image). It can't be fixed fully with an update.

Zeeshan, can you take a screenshot of a Boxes VM just by pressing 'print screen'? Or does that not work? I usually just use 'alt+prtscr' to get screenshots of virt-manager guests.

My vote would probably be -1/+1 (not a blocker, but a freeze exception issue), but we'll kick it around at the meeting tomorrow.
Comment 2 Christophe Fergeau 2013-06-12 04:11:36 EDT
Zeeshan's rationale for pushing this as a blocker is that he thought this was a guest-side issue with the qxl driver. If a buggy driver is shipped on the final live ISOs, this means the F19 live isos will show broken thumbnails in Boxes, hence his proposal as a blocker to make sure this gets fixed before the final ISOs are generated.

However, Dave's latest comment in the upstream bug report ( https://bugs.freedesktop.org/show_bug.cgi?id=64714 ) indicates this is a host-side bug, not a guest bug. If this is confirmed, this makes it possible to fix the issue even post-f19 release through a regular update (unless the livecd is used as a host system, which I assume is quite unusual).
Comment 3 Christophe Fergeau 2013-06-12 04:14:04 EDT
(In reply to Zeeshan Ali from comment #0)
> There doesn't seem to be a component for QXL here so filing it on spice.

Everything that is packaged in fedora has a corresponding fedora bugzilla component, in this case you were looking for the xorg-x11-drv-qxl component.
However, in the end this looks like a spice-server bug, so we can keep that one filed here ;)
Comment 4 Zeeshan Ali 2013-06-12 10:02:23 EDT
(In reply to Christophe Fergeau from comment #2)
> Zeeshan's rationale for pushing this as a blocker is that he thought this
> was a guest-side issue with the qxl driver. If a buggy driver is shipped on
> the final live ISOs, this means the F19 live isos will show broken
> thumbnails in Boxes, hence his proposal as a blocker to make sure this gets
> fixed before the final ISOs are generated.

Correct.
Comment 5 Zeeshan Ali 2013-06-12 10:05:17 EDT
(In reply to Adam Williamson from comment #1)
> For blocker voting purposes: there's some rationale in the upstream bug,
> apparently without a client side fix for this, Boxes and virt-screenshot
> won't ever be able to take proper screenshots of F19-stable-release package
> set guests (so, for e.g., a VM running the F19 live image). It can't be
> fixed fully with an update.
> 
> Zeeshan, can you take a screenshot of a Boxes VM just by pressing 'print
> screen'? Or does that not work? I usually just use 'alt+prtscr' to get
> screenshots of virt-manager guests.

Boxes takes screenshots automatically for running VMs and thats what it uses to show the icons in the main view. So for Boxes this is a lot more than just a broken isolated feature.
Comment 6 Alon Levy 2013-06-12 12:48:06 EDT
Just noting that I am working on this. It is a spice server issue like Dave Airlie noted at https://bugs.freedesktop.org/show_bug.cgi?id=64714

My plan requires a libvirt update:

qemu gains:
 new command: screendump-async
 new event: QEVENT_SCREENDUMP_COMPLETED

libvirt gains:
 new cap: QEMU_CAPS_SCREENDUMP_COMPLETED_EVENT
 updated implementation of qemuDomainScreenshot:
  if qemu has the new cap, issue a screendump-async, and wait for the event before completing the command.

I'm hoping the existing Async Job framework in libvirt is good enough for this. Daniel, could you comment on this?

Alon
Comment 7 Adam Williamson 2013-06-12 13:01:43 EDT
Discussed at 2013-06-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final-blocker-review-5.2013-06-12-16.01.log.txt .

This is now pretty clearly established as a host-side issue, and the impact isn't too terrible, so we were pretty clear in rejecting it as a blocker: the only criterion it might impact is "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use.", but we didn't think slightly corrupted screenshots in the overview really count as failing a 'basic functionality test'.

As for freeze exception status, we noted that using a live image as a VM host is a pretty minority pursuit, and that's the only case that can't be fixed with a post-release or 0-day update. As the proposed fix involves touching qemu and libvirt, which has implications for all other supported virt paths, we really felt the benefit/danger tradeoff on this wasn't sufficient to accept it as a freeze exception issue, so that's rejected too.

So if you want this fixed for the final release, get it in by the freeze deadline :) Otherwise it can go in as a zero-day.
Comment 8 Alon Levy 2013-06-12 13:03:26 EDT
Daniel, some additional notes:
 A more specific link to David's comment which you should read first:
  https://bugs.freedesktop.org/show_bug.cgi?id=64714#c4

 I believe *both* screendump & screendump-async should be allowed to proceed while other jobs are done, since they both don't change the state of the vm. (well, technically they do force rendering for qxl, but that is not relevant to the guest - it cannot rely on it anyway)

 Looking at JOB_MASK I am not sure this is how it works right now.

Alon
Comment 9 Alon Levy 2013-06-13 13:29:22 EDT
OK, sorry for the noise - I completely misunderstood. There are no needed changes for libvirt. Still working on the patch (at least now I'm not trying to work on libvirt too).

Alon
Comment 10 Alon Levy 2013-06-13 13:30:50 EDT
The change is in qemu, changing the screendump command to async, no spice nor libvirt changes are required.

Updating the component to reflect that.
Comment 11 Cole Robinson 2013-09-03 13:33:43 EDT
Alon, any news on this? Seems to still be busted with qemu 1.6
Comment 12 Cole Robinson 2013-10-03 10:30:05 EDT
Fixed in F19 qemu-1.4.2-11.fc19

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