Description of problem: virsh screenshot <domain> could not take effect immediately Version-Release number of selected component (if applicable): virt-manager-0.10.0-4.el7.noarch libvirt-1.1.1-8.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create and open a RHEL6.5 VM with Graphic Interface UI from virt-manager, and then open a gnome-terminal window in this VM. 2. From the host machine, issue following command to check screenshot function: #virsh send-key <domainVM> KEY_E KEY_C KEY_H KEY_O KEY_SPACE KEY_F KEY_I KEY_R KEY_S KEY_T KEY_ENTER ; virsh screenshot <domainVM> first.ppm Actual results: Empty gnome-terminal window display in screenshot first.ppm Expected results: The key "echo first" and a new line with "first" should be displayed in screenshot first.ppm Additional info: 1. This issue does not occur on latest RHEL6.5 Host environment; 2. This issue does not occur with button "Take Screenshot" from VM Windows in Virtual Manager; 3. This issue also occurs if you wait some times before taking screenshot in reproduce step 2 just like issue following command: #virsh send-key <domainVM> KEY_E KEY_C KEY_H KEY_O KEY_SPACE KEY_F KEY_I KEY_R KEY_S KEY_T KEY_ENTER ; sleep 30 ; virsh screenshot <domainVM> first.ppm 4. This issue occurs agaist both on a VM with KDE and GNOME desktop environment. 5. This issue does not occur agaist a VM without graphic interface.
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.
https://patchwork.ozlabs.org/patch/1222167/
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 ***