Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: When creating a VM via the cockpit interface, the listening address for external SPICE and VNC viewers will always be 127.0.0.1. Setting the default listen address in qemu.conf has no effect on this, because the 127.0.0.1 address is hardcoded in machines.min.js.gz . machines.js should read get the qemu.conf configuration for vnc_listen and spice_listen if those are defined. Version-Release number of selected component (if applicable): 217-1 How reproducible: 100% Steps to Reproduce: 1. Install cockpit, libvirtd, cockpit-machines, and all other relevant packages. 2. Modify /etc/libvirt/qemu.conf to define vnc_listen and spice_listen as = "0.0.0.0" 3. Create a VM via the web interface. Actual results: A VM is created and VNC & SPICE are bound and listening to 127.0.0.1 Expected results: VNC & SPICE should be listening as per qemu.conf Additional info: It's clear that this is hardcoded in machine.js in GRAPHICS_PARAM. In the upstream repo this is defined in pkg/machines/scripts/create_machine.sh I'm unsure if this bug should be filed against the upstream git.
Confirmed. Unfortunately there is very sparse documentation about /etc/libvirt/qemu.conf -- No manpage at all, nothing on https://libvirt.org/drvqemu.html. https://insights-core.readthedocs.io/en/latest/shared_parsers_catalog/qemu_conf.html has a bit, and the upstream source does implement the parameter: https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_conf.c#L426 Spice will be obsoleted soon, but VNC will stay around -- so I see no harm in checking the config file for this value indeed.
Hi, now after a year the same bug is still there. This would be no problem if the cockpit VNC interface were any good. Sadly it isn't. The mouse is all over the place. When will this be fixed or is there a workaround to change the IP that is given to the vnc client. Also it there a way to give the vnc-clientfile a ending so windows can 'assing' the right software to it?
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug is affecting RHEL 8.3
I just updated and it's valid for RHEL 8.4
There is a PR upstream: https://github.com/cockpit-project/cockpit-machines/pull/156
In which version in EL8 the fix will be released ?
Oops! We forgot to close this, this was already released in version 249. All supported Fedoras have 251 by now. Strahil: The fix will be in RHEL 8.5. CentOS 8 stream already has it: https://centos.pkgs.org/8-stream/centos-appstream-x86_64/cockpit-machines-251-1.el8.noarch.rpm.html