Description of problem: Using Windows 2008 Server R2 client, the Windows 7x64 guest video is migrated. During the migration the YouTube video, the graphics stop while the audio is paused slightly. The audio and the video counter (In the lower-left corner of video) keep going until the end while the graphic is halted. At the end, the screen is then refreshed with a new display of videos to see. To see this, you should migrate a few times. There was one time I restarted VM and saw this on the first migration. There are other times I had to migrate 2-5 times before I saw this bug. Version-Release number of selected component (if applicable): RHEV-M 3.2 (sf13.1) 3.2.0-10.19.beta2.el6ev rhevm-spice-client-x64-cab-3.2-9.el6ev.noarch rhevm-spice-client-x86-cab-3.2-9.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1. See above. 2. 3. Actual results: Graphics hang during migration. Expected results: Graphics don't hang during migration. Additional info:
Same behavior (graphics of a youtube video stays frozen, while the audio continues) seen with Win7 x86_64 client with Windows7 x86_64 guest. RHEV-M 3.2(sf13.1) client: rhevm-spice-client-x64-cab-3.2-9.el6ev.noarch guest: RHEV-Tools-Setup 3.2-5
Tested the migration with the same setup, only changed to a rhel 6.4 client, and the migration works fine with the rhel 6.4 client, so the issue is with the windows client.
Same with Client Windows7 32 Guest Windows XP 32
I believe this is a Regression from Beta 1.
Created attachment 736986 [details] DST
Created attachment 736987 [details] SRC
Created attachment 736988 [details] virt-viewer I have no idea how to get debug log when it is logging into event viewer on windows.
Thanks Marian for attaching the logs. Marc-Andre, can you please explain how the spice-gtk debug log can be obtained on Windows? Since this bug occurs only on Windows, I assume it is something related to the gstreamer audio playback, preceding the video frames, which leads to dropping the frames. But I can't say for sure without the detailed log. Still, has something changed in this code since beta 1? Bill, or someone else, can you make sure that when you downgrade to the beta1 client, the playback is ok? (downgrade only the client, the rest of the environment should stay the same).
Created attachment 737004 [details] remote-viewer debug log I got edbug log from mingw-virt-viewer somehow, There are two migrations of one VM, back and forth, the second one ended up in playback pause.
(In reply to comment #14) > Marc-Andre, can you please explain how the spice-gtk debug log can be > obtained on Windows? With recent mingw-virt-viewer builds, you should be able to get the log from the Windows Event log see rhbz#874499
In the log file Marian attached, there are 6 frames dropped after migration. The mm time changed after migration, and before the video stream started, the audio playback started with time 11989294 (playback-5:0: playback_handle_start: fmt 1 channels 2 freq 44100 time 11989294) However, the session's mm_time wasn't updated (the update_mmtime_timeout_cb in gtk/spice-gstaudio.c wasn't called?). In any case, the session mm_time should probably be updated when audio frames arrives, according to the latest delay we got from the audio backend, even if it is not the most updated one. In addition, if a playback has not started after migration, we should resend the mm_time via the main_channel. (on non-migration session, the mm-time is sent over the main-channel on startup and when audio playback is stopped). Notice that the log file is organized from latest to earliest.
I just reinstalled RHEV-M 3.2 (sf9) and migration works. I see a half or quarter second of a video pause in the migration but everything is fully functional.
(In reply to comment #18) > I just reinstalled RHEV-M 3.2 (sf9) and migration works. I see a half or > quarter second of a video pause in the migration but everything is fully > functional. When you say "I just reinstalled RHEV-M 3.2 (sf9)", do you mean the whole environment or just the client? We are only interested in the client. It will also be helpful if you attach the logs for the spice-servers (qemu), and client, so that we can see if with sf9 seamless migration took place.
Created attachment 739511 [details] Libvirt logs of the good hosts using sf9
The RHEV-M 3.2 (sf9) was using: rhevm-spice-client-x64-cab-3.1-8.el6.noarch spice-vdagent-0.12.0-4.el6_4.1.x86_64 rhevm-spice-client-x86-cab-3.1-8.el6.noarch
(In reply to comment #21) > The RHEV-M 3.2 (sf9) was using: > > rhevm-spice-client-x64-cab-3.1-8.el6.noarch > spice-vdagent-0.12.0-4.el6_4.1.x86_64 > rhevm-spice-client-x86-cab-3.1-8.el6.noarch Hi Bill, You used spice-client, and not virt-viewer. spice-client doesn't support seamless migration. And not-seamless migration doesn't have this bug.
(In reply to comment #22) > (In reply to comment #21) > > The RHEV-M 3.2 (sf9) was using: > > > > rhevm-spice-client-x64-cab-3.1-8.el6.noarch > > spice-vdagent-0.12.0-4.el6_4.1.x86_64 > > rhevm-spice-client-x86-cab-3.1-8.el6.noarch > > Hi Bill, > You used spice-client, and not virt-viewer. spice-client doesn't support > seamless migration. And not-seamless migration doesn't have this bug. Maybe I'm wrong about using spice-client, and the cab contains remote-viewer. But in any case, for some reason, seamless migration didn't work. Getting the client log would help understand why. Though it is no longer relevant.
Created attachment 739543 [details] Screenshots of executables
Yonit, I can easily find the virt-viewer executable and there is no spice executable. There is a spicex, but no spicec.exe anywhere. The screenshots will show you this.
(In reply to comment #25) > Yonit, I can easily find the virt-viewer executable and there is no spice > executable. There is a spicex, but no spicec.exe anywhere. The screenshots > will show you this. Bill, I already corrected myself on comment #23. In any case, in this setup, seamless migration doesn't work, and it is not comparable to the discussed environment.
I have verified that the sf9 install and RHEV-M client works. My next step was have the client attach to a sf 13.1 build, download the 0.5.3-24 virt-viewer and try to migrate a VM on the sf9 install. With the new client from sf13.1 and the Beta 1 RHEV-M (sf9) and hosts, the video stops during migration.
(In reply to comment #27) > I have verified that the sf9 install and RHEV-M client works. My next step > was have the client attach to a sf 13.1 build, download the 0.5.3-24 > virt-viewer and try to migrate a VM on the sf9 install. > > With the new client from sf13.1 and the Beta 1 RHEV-M (sf9) and hosts, the > video stops during migration. What is sf9 or sf13? I have been able to reproduce some video stops during migration. Though the issue was related to qemu networking that breaks the video stream in youtube, and the Flash video stops or "hangs", and need to be resumed manually by seeking/play. I couldn't reproduce any server or client issue after ~20 migrations tests.
My testing was current RHEL6.4 host (spice-server-0.12.0-12.el6.x86_64 & qemu-kvm-0.12.1.2-2.355.el6_4.2.x86_64), src and dst migration on same machine. The guest is Windows XPSP3 with latest firefox/youtube playing a clip of 1h. The client is Windows XP on a very old laptop, on bare metal, with mingw-virt-viewer-0.5.3-24.el6ev installed, started from command line with SPICE_DEBUG enabled. After removing a few assert/error from spice server code which I can hit regularly (!) during my first dozen of tests..., I did about 10 consecutive seamless migrations. I could observe sometime that the youtube player "stopped", but this wasn't spice responsability, but rather some kind of network layer issue. Thus I ask the reporter to verify that the playback really continues after migrations (for example, is the sound still playing?). Of course, I get some frames dropped, and the video freezes for a few seconds. But this is something we can't easily improve and in no way a real bug.
The reproducer is in the original bug report, before the comments. You are doing command line migrations from one port to another on the same box. I have installed RHEV-M 3.2, added two 6.4 hosts and created a VM and taken a YouTube video and used RHEV-M to physically migrate the VM from one host to another, while the video was playing on a W2K8R2 client. I just showed Yonit my setup and the fail with sf14.
assigning to Yonit, who is working on it
moving to 3.3 and propose to 3.2.z. no way can it be solved before the last build of the win client
moving to 3.2.z
Posted a patch (http://patchwork.freedesktop.org/patch/13602/) Several comments about the bug: - In order to reproduce the bug you need to perform migration between hosts with different uptime (the duration of the video freeze is proportional to the time difference between the hosts). The bug is more likely to occur when migrating from the host with the shorter uptime to the host with the longer uptime. - reopening the video will recover it (or pausing and then replaying). - The bug results from a race between setting the multi-media time after migration, and arrival of frames with the updated multi-media time. The race exists in the Linux spice-gtk as well. It is less likely to happen there due to a small difference in the timing of setting the mm-time. Should the bug be opened for spice-gtk rhel6.4z as well? - I opened a similar bug for video without audio packets (in spice-server): bug #958276
This bug is currently attached to errata RHEA-2013:15512. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0034.html