Bug 973374

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.

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).

(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 ;)

(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.

(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.

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

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.

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

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

The change is in qemu, changing the screendump command to async, no spice nor libvirt changes are required.

Updating the component to reflect that.

Alon, any news on this? Seems to still be busted with qemu 1.6

Fixed in F19 qemu-1.4.2-11.fc19