Bug 1320331

Sort of the same issue, if I change the Spice graphics device to listen on all interface and not only loopback, virt-manager will try to do a direct connection to the none-TLS port.

I think that Virt-manager should try, in order, direct TLS, direct none-TLS, none-TLS over SSH and finally TLS over SSH. This would make it possible to use the TLS port with remote-viewer but still having a working console in virt-manager.

Thanks for the report. But i'm  confused... what does none-TLS mean? what are you actually changing?

Can you provide the following:

virt-manager --debug when reproducing the issue
when the VM is running, grab the runtime XML with 'sudo virsh dumpxml $VMNAME'

Created attachment 1157883 [details]
virt-manager --debug showing first issue

Created attachment 1157884 [details]
Dump of virsh xml

none-TLS is the default way to communicate without any changes. With defaultMode=secure TLS is enabled instead on the same port, 5900 by default.

I've attached the logs and the machine XML. The logs shows how I connect to the running machine with the default config, it works fine. Then I change the configuration and run "virsh define Windows7_VOLVO.xml" to change the defaultMode parameter, it still works. Restart the virtual machine and there is the error.

Thanks for the info, I can reproduce now. The 'None' error is because we aren't handling the fact that port=None in this case, since only tlsPort is set.

But once I fix that it still doesn't work. Can you describe the setup you used to get remote-viewer working? So I can figure out why that works, but not what I'm trying locally

I connect with remote-viewer spice://remote-host.example.net?tls-port=5901.

I disable the auto-port for TLS and set it to 5901. The Address was changed to all interfaces. All this was done using the virt-manager UI.

I've also opened the port in my local firewall using firewall-cmd --add-port=5901/tcp.

It seems that both remote-viewer and virt-manager tries to do a direct connection if it uses the TLS port. I suspect that is why it doesn't work in your case.

Ah okay so you were directly connecting, not using SSH forwarding. That makes more sense. SSH likely won't work for most (any?) TLS setups, because the hostname you are connecting to is important for the TLS verification. So on my host machine, the TLS cert is valid for 'colepc' but doesn't work if connecting to 127.0.0.1/localhost. And in the ssh tunnel case the address that is relevant here is not the hostname in the libvirt URI but the address in the VM XML graphics listen= attribute

So the SSH case basically requires that 1) the physical machine hosting the VM is configured to be a TLS client, and 2) the listen address advertised in the XML is the valid TLS hostname for the VM, but even when I tried to force that config it wasn't working for some reason. Even if it did work it would be a pretty esoteric setup

So instead I changed virt-manager to error explicitly in this case and try to give a bit of info about what's going on:

commit 8c2adb83aefb6e1a42e0eaa75c9903faa24a6bc3
Author: Cole Robinson <crobinso>
Date:   Wed May 18 16:57:38 2016 -0400

    console: Error for more non-working graphical configs
    
    - If connecting remotely but graphics has no listen address,
        like the spice GL case.
    - Trying to connect to a TLS using VM over an ssh tunnel, it doesn't
        seem to work: https://bugzilla.redhat.com/show_bug.cgi?id=1320331

I agree that running TLS over SSH is a bit of a corner case that is probably not worth supporting.

However, the mismatching hostname issue isn't that simple. The listen attribute can be set to 127.0.0.1 or 0.0.0.0 (using the GUI that is). This mean that for a TLS connection, this attribute would be 0.0.0.0. To be able to verify the certificate it must get the hostname from somewhere else, i.e. the URI of the remote libvirt instance.

My simple test with a made up hostname in /etc/hosts and connecting via that name using virt-manager gives me a TLS certificate error and the logs also indicates that it tries to do a direct connection to the made up name.

From a TLS perspective, I don't see why this wouldn't work. You are connecting to a machine called 'colepc' via SSH and the TLS certificate it presents is for a host called 'colepc'. The communication with SSH happens over stdin/stdout due to the use of nc, not a port forwarding involving TCP connections on your local machine.

Anyway, I've tried the latest git commit 8c2adb8 and it gives a much better error message so I think it's good for now.

Yeah I'm not really sure why it failed either. If you can come up with a working scheme over ssh I'm happy to revisit this

These patches are being built for f24+ with the new virt-manager release. Not sure if I'm going to pull the new virt-manager in f23 yet, maybe give it some time to bake in f24/rawhide. Just closing this bug against F24 virt-manager. If you come up with a working config for comment #9/#10 please open a separate bug to discuss