Bug 1018668
Summary: | screenshot command does not take effect immediately agaist a VM with UI desktop window. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | zhengqin <zsong> |
Component: | qemu-kvm | Assignee: | Virtualization Maintenance <virt-maint> |
qemu-kvm sub component: | Graphics | QA Contact: | Guo, Zhiyi <zhguo> |
Status: | CLOSED DUPLICATE | Docs Contact: | |
Severity: | medium | ||
Priority: | medium | CC: | chayang, coli, dyuan, jinzhao, juzhang, knoel, kraxel, marcandre.lureau, mzhan, nanliu, rbalakri, ribarry, tzheng, virt-maint, xfu |
Version: | 8.0 | Keywords: | Triaged |
Target Milestone: | rc | ||
Target Release: | 8.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-12-15 06:01:14 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: | |||
Bug Depends On: | 1230527 | ||
Bug Blocks: |
Description
zhengqin
2013-10-14 07:00:52 UTC
I get the same error using this command (that is what the virsh screenshot command does behind the scenes): virsh send-key $VM_NAME KEY_E KEY_C KEY_H KEY_O KEY_SPACE KEY_A KEY_ENTER; sleep 30; virsh qemu-monitor-command $VM_NAME '{"execute":"screendump", "arguments": { "filename": "/tmp/foo.ppm"}}' I am reassigning to qemu for further probing of this issue. Test case isn't valid. There is no guarantee that the guest has successfully processed the key presses by the time the screenshot command is executed. Nevertheless there is a known issue with qxl due to spice-server doing local rendering asynchronously. stdvga and cirrus don't have this problem. Fix is non-trivial because monitor can't sleep & wait. Marc-André kicked async monitor discussion upstream recently: https://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg05825.html Adding him to Cc: not solved yet upstream -> defer to 7.4 > not solved yet upstream -> defer to 7.4
same again. Not solved, nobody working on it, very unlikely to make 7.4
Looks like we have async monitor some progress upstream, block-jobs evolving into generic jobs. Need to check whenever this actually helps with this issue. Also merged upstream after 2.12, so not available for 7.6. Most likely this will be deferred again ... *** Bug 1651843 has been marked as a duplicate of this bug. *** Moving to advanced virt. QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks Not sure how to classify this one, picked graphics for now, but maybe qmp fits better ... Upstream status: seems we are pretty close to actually getting async monitor commands (using coroutines). With some good luck 5.1 will finally fix this one. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. Hi Gerd, I see the fix of this problem has been already addressed by Bug 1230527 - For a windows guest using spice, sceenshot has to be taken twice continually to get the current screen. The fix: commit 0d9b90ce5c73505648909a89bcd5272081b9c348 Author: Marc-André Lureau <marcandre.lureau> Date: Tue Oct 27 17:36:02 2020 +0400 console: make QMP/HMP screendump run in coroutine Thanks to the monitors' coroutine support (merge commit b7092cda1b3), the screendump handler can trigger a graphic_hw_update(), yield and let the main loop run until update is done. Then the handler is resumed, and ppm_save() will write the screen image to disk in the coroutine context. The IO is still blocking though, as the file is set blocking so far, this could be addressed by some future change (with other caveats). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1230527 Signed-off-by: Marc-André Lureau <marcandre.lureau> Reviewed-by: Gerd Hoffmann <kraxel> Reviewed-by: Markus Armbruster <armbru> Message-id: 20201027133602.3038018-4-marcandre.lureau Signed-off-by: Gerd Hoffmann <kraxel> Can I mark this bug as a dup of Bug 1230527? Thx! Zhiyi >
> Can I mark this bug as a dup of Bug 1230527? Thx!
>
yes, it is the same underlying issue.
*** This bug has been marked as a duplicate of bug 1230527 *** |