Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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 ?
(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?
(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.
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