Hide Forgot
Description of problem: Since https://gerrit.ovirt.org/#/c/57932/ the VMs are allocated only the tls port for console connection. Still, on engine side we have both Port and SecurePort. When vdsm includes that patch, the engine side keeps the "-1" for the non tls port forever as vdsm never reports back the port number because it was never allocated. Apparently this can break some clients such as IGEL, which end up interpreting "-1" as 65535 and never trying the tls port (sure, a bug on it's own). Still, what is the value of adding this "-1" in the console.vv file? It contains no useful information and perhaps should be omitted to avoid breaking setups that are already working fine. From a customer perspective, the perceived problem is that when upgrading a RHEV-H host to a later version, it breaks the console clients. Note that there might be a mix of RHEL7 hosts with different vdsm versions, so depending on which Host the VM was started, the port might be allocated or not, so it needs to be tested not just removed altogether. Perhaps a simple test here could make it more friendly to these devices? In backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/console/ConsoleDescriptorGenerator.java public class ConsoleDescriptorGenerator { public static String generateDescriptor(ConsoleOptions options) { StringBuilder configBuilder = new StringBuilder("[virt-viewer]"); configBuilder.append("\ntype=").append(graphicsTypeToString(options.getGraphicsType())) .append("\nhost=").append(options.getHost()) .append("\nport=").append(options.getPort()) <------ If it's -1, don't include it? Surely, the Client does not seem to be doing the correct thing by interpreting -1 as 65535. But -1 is not really a valid port number either. We might be "more compatible" if we simply omit this value in case it's not in use and make RHV friendlier to these devices. Unless there is a good reason to have this "-1" in the console descriptor, but I can't see it. Version-Release number of selected component (if applicable): RHEV Hypervisor - 7.2 - 20160711.0.el7ev How reproducible: - Not yet, apparently requires IGEL client. Apparently this is based on Ubuntu 14.04 LTS but even using this Ubuntu version I can't reproduce it. - Customer hits this constantly Actual results: GSpice-DEBUG: spice-session.c:2126 main-1:0: Using plain text, port 65535 GSpice-DEBUG: spice-session.c:2058 open host 172.20.176.107:65535
What will the client do when they suddenly do not receive the port at all?
(In reply to Yaniv Kaul from comment #1) > What will the client do when they suddenly do not receive the port at all? Hopefully it will do what it is supposed to do: stop misinterpreting the non secure port, since it's not there anymore, and use the tls-port. And if it still doesn't work, then the client must be fixed. We do use the -1 value in libvirt xml/vdsm/ovirt but I am not really sure if it should be presented to a console client too. Seems like adding useless information, doesn't it? Just to be clear, I don't see this as a bug on the engine, but more like something that perhaps could be improved for simplicity and better compatibility. We are actually trying to reproduce it since the IGEL client is based on Ubuntu LTS. If we do, I'll update the BZ.