Red Hat Bugzilla – Bug 1025435
VM ticket was not set upon migration
Last modified: 2015-02-27 14:45:33 EST
Created attachment 817992 [details]
Description of problem:
VM ticket was not set upon migration so the virt-viewer showed just password prompt. This error happened to me just once around 17:26 local time (16:26 UTC). The VM name is rhel6-64-33-dj and VM UUID is dc636bfb-9fd2-45f4-874b-9e997ebf0d29
Version-Release number of selected component (if applicable):
is20.1 - engine and dst host:
source host is is19:
Steps to Reproduce:
1. do back and forth migrations with client connected
client asked for password, qemu log says that the ticketing is enabled but password is not set (this is correct spice behaviour)
password is set
component is just a blind guess, the issue may be anywhere in the stack...
martin, please check in the logs, david, since it happened only once and under not really normal circumstances - moving out to 3.4
The destination logs indicate that the qemu failed to hand over the ticket:
((null):9709): Spice-Warning **: reds.c:2719:reds_handle_read_link_done: spice channels 1 should be encrypted
((null):9709): Spice-Warning **: reds.c:2820:reds_handle_ssl_accept: SSL_accept failed, error=5
((null):9709): Spice-Warning **: reds.c:1966:reds_handle_ticket: Ticketing is enabled, but no password is set. please set a ticket first
I'm not sure if anything else can be added without knowing what spice-server was thinking…
It does not look like a spice-server problem.
If the ticket was not set, spice-server can not accept connections.
The dst_libvirt_log, which is a suspect, does not contain information about the problematic VM.
The first attempt of the client to connect, just before migration
started, failed (SSL_accept failed with error 5 == SSL_ERROR_SYSCALL).
The second attempt to connect (after migration completed) failed, because
no ticket was set.
David, have you hit that issue just once, or is it still occurring for you ?
I didn't use RHEV for a while so I didn't hit it recently but it just popped up time to time. It was neither frequent, nor one-time issue. Have you had a look to code paths that Uri pointed at?
Client logs could probably help there :(
closing for now, feel free to reopen with more details on how to reproduce & logs thanks