Hide Forgot
Description of problem: start the VM ,then in the qemu-monitor change the password of spice protocol ,the spice client disconnected. After that then repeat change the passord of spice protocol ,spice client still connected. Version-Release number of selected component (if applicable): # uname -r 2.6.32-125.el6.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.152.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1.Start VM with spice 2.change the spice passord {"execute":"set_password",arguments":{"protocol":"spice"，"password":"mike"}} 3.connect the spice client with password 4.Repeat step 2. Actual results: After step 2, spice client disconnected. After step 4, spice client still connected.After that then conninue change passord of spice protocol .spice client still connected. Expected results: after step 4, spice client will disconnected default Additional info: 1.Tried both qemu-monior and qmp monitor ,both hit this issue 2.Tried both set_password & __com_redhat_set_password ,both hit this issue 3.workround ,add connected value to keep or disconnect manully eg :{"execute":"set_password",arguments":{"protocol":"spice"，"password":"mike","connected":"disconnect"}}
(In reply to comment #0) IIUC, this is a feature request, asking to disconnect the client by default upon setting a new password. I do not see anything wrong with the current behavior. Changing the password of the following connection does not affect the current connection, unless specifically requested by the user (as a parameter to the monitor command).
(In reply to comment #2) > (In reply to comment #0) > IIUC, this is a feature request, asking to disconnect the client by default > upon setting a new password. > I do not see anything wrong with the current behavior. Changing the password of > the following connection does not affect the current connection, unless > specifically requested by the user (as a parameter to the monitor command). hi ,Uri referring to step2 ,Why the first time change password ,spice client dis-connected ?
Sorry, I missed the inconsistency reported. So are the steps: 1. start a VM 1.2 set_password (?) 1.5 connect with spice-client 2. set_password -> spice-client disconnects 3. connect again with spice-client 4. set_password -> spice-client stays connected I'll need to check the inconsistency (or why on 2 it disconnects).
(In reply to comment #4) > Sorry, I missed the inconsistency reported. > So are the steps: > 1. start a VM > 1.2 set_password (?) > 1.5 connect with spice-client > 2. set_password -> spice-client disconnects > 3. connect again with spice-client > 4. set_password -> spice-client stays connected > no step 1.2 and after the first time changing password .spice-client always says connected.
I think this is not a bug. I think the seemed-to-be inconsistency is due to a change in ticketing policy. At the beginning the policy is "disable-ticketing" and any spice-client connecting is welcome. The first "set_password" changes this policy to enable ticketing (and sets a specific password) which disconnects the client that was connected with no password. The second set ticket does not change that policy, and the client that got connected using a ticket is not disconnected. Please try starting qemu-kvm with no "disable-ticketing" spice option.
Tested with disable-ticketing: 1. boot up guest with ... -spice port=8000,disable-ticketing ... 2. connect to guest in client #spicec -h $ip -p 8000 3. change password for spice after step3, the spice window disconnected automatically Tested no disable-ticketing: 1. boot up guest with ... -spice port=8000 ... , the qemu monitor remind : "reds_handle_ticket: Ticketing is enabled, but no password is set. please set a ticket first", so I must set the password in monitor, then can connect to guest in clinet with #spicec -h $ip -p 8000 -w $pw. if I change the password, will not disconnects the client spice windows. 2. boot up vm with -spice port=8000,password=$pw the same result with step1
According comment #7 & #8, this is not a bug, like a feature request.
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.