Bug 731685

Summary: Can not update VNC/Spice password on a running guest
Product: Red Hat Enterprise Linux 7 Reporter: zhpeng
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 7.0CC: cwei, dyuan, jsuchane, mprivozn, mshao, mzhan, rbalakri, sathnaga86, tzheng, vbian, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 768423 (view as bug list) Environment:
Last Closed: 2016-02-17 10:01:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 768423    
Bug Blocks:    

Description zhpeng 2011-08-18 11:07:19 UTC
Hi all,

Description of problem:
1. Add/change/delete VNC password when guest is running Will not work.
2. Delete Spice password when guest is running Will not work


Version-Release number of selected component (if applicable):
libvirt-0.9.4-4.el6.x86_64
qemu-kvm-0.12.1.2-2.184.el6.x86_64
kernel-2.6.32-191.el6.x86_64

How reproducible:
always

Steps to Reproduce:

UPDATE VNC PASSWORD:

1. prepare vnc-new.xml
<graphics type='vnc' port='5900' autoport='yes' listen='0' keymap='en-us' password='aaaaaa'>
<listen type='address' address='0'/>
</graphics>

2. a running guest without VNC password.
# virsh update-device test1 vnc-new.xml      (add password)
  Device updated successfully
But still do not need password

3. edit test1.xml set VNC password to "bbbbbb".reboot the guest ensure the password set success.then:
  # virsh update-device test1 vnc-new.xml    (change password)
   Device updated successfully  
Can login in with new password.

But on some machine, it's failed. the machine information is in next common.


4. delete "password='aaaaaa'" of vnc-new.xml, then:
  # virsh update-device test1 vnc-new.xml     (delete password)
 Device updated successfully
But still need password.

UPDATE SPICE PASSWORD:

1. prepare spice-new.xml
<graphics type='spice' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>

2. a running guest with Spice password.
   # virsh update-device test2 spice-new.xml (delete password)
     Device updated successfully
 
but open virt-manager, the guest Spice console still need password. Input old password, it works.

in debug info:

Actual results:
In UPDATE VNC PASSWORD step 2,3,4 update VNC password is not work.
In UPDATE SPICE PASSWORD step 2 update Spice password is not work.


Expected results:
1. Add/change/delete VNC password when guest is running Will  work.
2. Delete Spice password when guest is running Will  work

Comment 5 Vivian Bian 2011-08-22 10:31:27 UTC
chatted with kvm qe member , and we got the following info :

from the qemu-kvm monitor :
1. set_password doesn't work if we started the guest without vnc/spice password
2. set_password requires password string ,otherwise , set_password can't be performed successfully

In order to keep the virtualization products consistent 
1. if we don't set password to a guest started without vnc/spice passwd , please prompt the info "The requested feature is not supported"
2. if we don't support clear password from the guest started with vnc/spice passwd, please prompt the info "The requested feature is not supported". Then we can file the virt-manager bug to make the GNU tools have the same response . 

What do you think of it ?

Comment 7 Michal Privoznik 2011-12-13 11:21:41 UTC
(In reply to comment #5)
> chatted with kvm qe member , and we got the following info :
> 
> from the qemu-kvm monitor :
> 1. set_password doesn't work if we started the guest without vnc/spice password
> 2. set_password requires password string ,otherwise , set_password can't be
> performed successfully
> 
> In order to keep the virtualization products consistent 
> 1. if we don't set password to a guest started without vnc/spice passwd ,
> please prompt the info "The requested feature is not supported"
> 2. if we don't support clear password from the guest started with vnc/spice
> passwd, please prompt the info "The requested feature is not supported". Then
> we can file the virt-manager bug to make the GNU tools have the same response . 
> 
> What do you think of it ?

I don't think I can see why is that. Shouldn't qemu allow to set password regardless if it was started with password or not? And vice versa - shouldn't qemu allow removing already set password? The spice function spice_server_set_ticket() which qemu use to set password does support password setting/removing. Is there any reason why qemu forbids that?

Comment 8 Dave Allan 2011-12-16 16:02:59 UTC
(In reply to comment #5)
> chatted with kvm qe member , and we got the following info :
> 
> from the qemu-kvm monitor :
> 1. set_password doesn't work if we started the guest without vnc/spice password
> 2. set_password requires password string ,otherwise , set_password can't be
> performed successfully
> 
> In order to keep the virtualization products consistent 
> 1. if we don't set password to a guest started without vnc/spice passwd ,
> please prompt the info "The requested feature is not supported"
> 2. if we don't support clear password from the guest started with vnc/spice
> passwd, please prompt the info "The requested feature is not supported". Then
> we can file the virt-manager bug to make the GNU tools have the same response . 
> 
> What do you think of it ?

That seems very strange to me.  IMO, it's a completely valid use case to start a VM with no password and then later decide that it requires one.  The user should not be forced to shut the VM down in order to set a password.

Comment 19 Jiri Denemark 2014-04-04 21:36:35 UTC
This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.

Comment 26 Michal Privoznik 2016-02-17 10:01:55 UTC
Seems like nobody actually needs this use case. I'm closing this one. If you disagree, please reopen.