How can I know wich IP novncd is using to connect to the VMs ? is there some logs somewhere you said it's calling virsh, but virsh is not installed inside the docker and if I look at the running process I can see a lot of tunnels made with netcat O_o I can successfully login on the new docker and access the VM's VNC that are listen on 0.0.0.0 but still not working with the ones listening 127.0.0.1 so I cannot explain why the old docker can still access them. I then added the reverse proxy in my apache the same way i did for the other docker. The only difference is the supervisor package that is apparently not part of the new docker, so I did not put it. I installed a new docker following the tutorial, manually applied the patches from Mplx and added the missing docker instruction (the startinit.sh that set the right ports and fix few permissions). Hi, sorry for the late reply, did not had time to do it sooner. So this is exactly what I want but I don't know if it's a feature that works on the docker and not on the new webvirtcloud or if it's due to some black magic and weird routing/nating between the host and docker. So at the end, it's like the docker webvirtcloud is capable of both making directe connection to the hypervisor and tunneled connections through SSH (when the listen is 127.0.0.1). That's weird but I can imagine that the router use his internal IP instead of public IP (need to check with a tcpdump, because usually it uses his public ip.) VM4: Works from new webvirtcloud compute 1 - Makes sense - And works from both webvirtcloud compute 2.VM3: only works from docker webvirtcloud compute 1 - Makes sense and make the fact than VM2 works even weirder.VM2: the NoVNC works from docker webvirtcloud compute 1 and 2 - weird, the source ip with compute 1 should be 172.23.0.2 and from compute 2 it should be (since the source ip = private and dest = public the router will do a double nat and will make the connection using his public IP) - not working at all from new webvirtcloud.VM1: the NoVNC works from the four computes - Makes sense but don't want to expose VNC on internet so don't like that solution.On the new webvirtcloud I've added 2 computesįinally on the Hypervisor I've 4 VMs with the following settings for the VNC On docker webvirtcloud I've added 2 computes Then all the outgoing traffic (toward internet) from 192.168.10.10 is nated by the router so the source ip = public_ip (Nothing special here, default behavior of a home router/modem) but even in that case I cannot explain one situation.Īnd the second webvirtcloud I've installed on another machineĪll the trafic coming on the public_ip is forwarded to 192.168.10.10 (keeping the real source IP) Maybe it's due to a weird NAT between the docker and the host that allows VNC connection. Nevertheless, I'll try the wiki guide and apply the patch. Thanks for your support, but the question here was more how the VNC connection is handled between the webvirtcloud server and the hypervisor in case of SSH connection.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |