Hello, Management server and KVM host are running on the same machine and CPVM is running on the same machine as the management server is running on. IP 192.168.1.1 which is the pod's gateway is assigned to cloudbr0 bridge on the host and is reachable from CPVM. I'm wondering why host does not act as gateway and trafsourcing from subnet 192.168.1.0/24 is flowing through the default gateway.
Any idea? Thanks. On Mon, Aug 12, 2024 at 1:31 PM Jayanth Babu A <[email protected]> wrote: > Hello, > So I believe that the physical network where the “Management” traffic > flows has the gateway set as your Management Server IP. You can either > enable MASQUERADE (NAT) on your management server assuming your management > server has access to the Internet or specify a valid next hop which has > access to the public DNS. Please visit your Zone settings, specifically the > physical network which has the “Management” traffic label. > > Regards, > Jayanth Reddy > > From: Fariborz Navidan <[email protected]> > Date: Monday, 12 August 2024 at 3:14 PM > To: [email protected] <[email protected]> > Subject: Re: Long time to load noVNC > Hello, > > I found the reason :) The reason for this behaviour is that CPVM is unable > to resolve the console domain name (console.r9host.com). The issue is that > it can reach all the Internet except it's resolvers which are 8.8.8.8 and > 8.8.4.4 which are DNS servers set for the zone. I just checked the routes > on CPVM and I found that there are static routes for 8.8.8.8 and 8.8.4.4 to > be reachable via 192.168.1.1 which is private IP address of management > server (same as the host machine). I just deleted these routes and > everything started to work fine. I had the following routes inside CPVM: > > 8.8.4.4 via 192.168.1.1 dev eth1 > 8.8.8.8 via 192.168.1.1 dev eth1 > > Note that 192.168.1.1 is reachable from CPVM but no DNS server is running > on 192.168.1.1 to resolve DNS. > > If I reboot the CPVM those routes for resolvers comes back. How do I avoid > these route ro be created inside CPVM? > > Thanks. > > On Mon, Aug 12, 2024 at 12:29 PM Jayanth Babu A > <[email protected]> wrote: > > > Would you please recreate the CPVM like Wei suggested? > > > > Regards, > > Jayanth Reddy > > > > From: Fariborz Navidan <[email protected]> > > Date: Monday, 12 August 2024 at 1:59 PM > > To: [email protected] <[email protected]> > > Subject: Re: Long time to load noVNC > > Hi, > > > > Dear Jayan, I tested ping from console VM with size 1472 and I get > replies > > from gateway. There is no network issue as other VM instances are working > > fine with SSL installed on their web servers. I have also tested with > > another cert issuer, ZeroSSL and I get the same result. It looks like > CPVM > > v4.18.2.1 has problems with handling SSL/TLS. > > > > Please advise. > > > > Thanks. > > > > On Sun, Aug 4, 2024 at 5:53 PM Wei ZHOU <[email protected]> wrote: > > > > > It looks like a configuration issue. > > > > > > After changing the global setting, it would be better to restart the > > > management server and destroy the CPVM. > > > > > > -Wei > > > > > > On Sun, Aug 4, 2024 at 1:43 AM Fariborz Navidan <[email protected] > > > > > wrote: > > > > > > > > Hi, > > > > > > > > I have double checked resources and network status on both the host > and > > > > CPVM. The host's CPU/RAM utilisation is under 20% and CPU usage of > > > console > > > > VM during the long response time is around 0.3%. > > > > > > > > I just reverted the "'consoleproxy.sslEnabled" setting back to false > > and > > > > then restarted console VM and it responds immediately. In other hand, > > > when > > > > above setting is set to true, CPVM struggled with SSL connection. > > > > > > > > The uploaded cert is a valid Let's Encrypt one along with unencrypted > > > PKCS8 > > > > private key. > > > > > > > > Any idea on what's happening? > > > > > > > > Regards. > > > > > > > > On Sat, 3 Aug 2024, 18:13 Jayanth Babu A, <[email protected] > > > .invalid> > > > > wrote: > > > > > > > > > Hi, > > > > > It may indicate a resource or network issue. Just in case, have you > > > > > already checked the CPU & memory utilization on the CPVM & on the > > host? > > > > > The below trace shows that the TLS handshake is taking time. > > > > > > > > > > > > > > > $ curl -vIL --trace-time https://console.r9host.com > > > > > > > > > > 14:37:46.203639 * Trying 149.50.127.131:443... > > > > > > > > > > 14:37:46.203710 * TCP_NODELAY set > > > > > > > > > > 14:37:46.464621 * Connected to console.r9host.com (149.50.127.131) > > > port > > > > > 443 (#0) > > > > > > > > > > 14:37:46.465004 * ALPN, offering h2 > > > > > > > > > > 14:37:46.465165 * ALPN, offering http/1.1 > > > > > > > > > > 14:37:46.470305 * successfully set certificate verify locations: > > > > > > > > > > 14:37:46.470389 * CAfile: /etc/ssl/certs/ca-certificates.crt > > > > > > > > > > CApath: /etc/ssl/certs > > > > > > > > > > 14:37:46.470604 * TLSv1.3 (OUT), TLS handshake, Client hello (1): > > > > > > > > > > 14:38:14.752752 * TLSv1.3 (IN), TLS handshake, Server hello (2): > > > > > > > > > > 14:38:14.752950 * TLSv1.2 (IN), TLS handshake, Certificate (11): > > > > > > > > > > 14:38:14.754551 * TLSv1.2 (IN), TLS handshake, Server key exchange > > > (12): > > > > > > > > > > 14:38:14.754989 * TLSv1.2 (IN), TLS handshake, Server finished > (14): > > > > > > > > > > 14:38:14.755663 * TLSv1.2 (OUT), TLS handshake, Client key exchange > > > (16): > > > > > > > > > > 14:38:14.756040 * TLSv1.2 (OUT), TLS change cipher, Change cipher > > spec > > > (1): > > > > > > > > > > 14:38:14.756446 * TLSv1.2 (OUT), TLS handshake, Finished (20): > > > > > > > > > > 14:38:15.279001 * TLSv1.2 (IN), TLS handshake, Finished (20): > > > > > > > > > > 14:38:15.279063 * SSL connection using TLSv1.2 / > > > > > ECDHE-RSA-AES256-GCM-SHA384 > > > > > > > > > > 14:38:15.279096 * ALPN, server did not agree to a protocol > > > > > > > > > > 14:38:15.279131 * Server certificate: > > > > > > > > > > 14:38:15.279177 * subject: CN=console.r9host.com > > > > > > > > > > 14:38:15.279227 * start date: Aug 3 07:42:27 2024 GMT > > > > > > > > > > 14:38:15.279270 * expire date: Nov 1 07:42:26 2024 GMT > > > > > > > > > > 14:38:15.279312 * subjectAltName: host "console.r9host.com" > matched > > > > > cert's "console.r9host.com" > > > > > > > > > > 14:38:15.279349 * issuer: C=US; O=Let's Encrypt; CN=R10 > > > > > > > > > > 14:38:15.279396 * SSL certificate verify ok. > > > > > > > > > > 14:38:15.279499 > HEAD / HTTP/1.1 > > > > > > > > > > 14:38:15.279499 > Host: console.r9host.com > > > > > > > > > > 14:38:15.279499 > User-Agent: curl/7.68.0 > > > > > > > > > > 14:38:15.279499 > Accept: */* > > > > > > > > > > 14:38:15.279499 > > > > > > > > > > > 14:38:15.540409 * Mark bundle as not supporting multiuse > > > > > > > > > > 14:38:15.540539 < HTTP/1.1 404 Not Found > > > > > > > > > > HTTP/1.1 404 Not Found > > > > > > > > > > 14:38:15.540631 < Content-Length: 50 > > > > > > > > > > Content-Length: 50 > > > > > > > > > > 14:38:15.540671 < Content-Type: text/html > > > > > > > > > > Content-Type: text/html > > > > > > > > > > > > > > > > > > > > 14:38:15.540706 < > > > > > > > > > > 14:38:15.540738 * Excess found: excess = 50 url = / (zero-length > > body) > > > > > > > > > > 14:38:15.540809 * Connection #0 to host console.r9host.com left > > intact > > > > > > > > > > > > > > > Regards, > > > > > Jayanth Reddy > > > > > > > > > > From: Fariborz Navidan <[email protected]> > > > > > Date: Saturday, 3 August 2024 at 3:06 PM > > > > > To: [email protected] <[email protected]> > > > > > Subject: Long time to load noVNC > > > > > Hello Everyone. > > > > > > > > > > I have a strange problem with console proxy after enabling SSL. I > > have > > > got > > > > > a valid certificate and uploaded into CS (v4.18.2.1). Afterward, > the > > > > > console proxy takes a long time to load. For example when I browse > to > > > > > https://console.mycompany.com, it take a few minutes to send > > response > > > and > > > > > when I click the "view console" button in a VM view page, it takes > a > > > few > > > > > minutes to load noVNC at > > > > > > > > > > > > > > > > https://console.r9host.com/resource/noVNC/vnc.html?autoconnect=true&port=8443&token= > > > > > . > > > > > .. > > > > > > > > > > Any idea why console provy VM is such slow? > > > > > > > > > > Thanks in advance. > > > > > Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL > > > > > INFORMATION intended solely for the use of the addressee(s). If you > > > are not > > > > > the intended recipient, please notify the sender by e-mail and > delete > > > the > > > > > original message. Further, you are not authorised to copy, > disclose, > > or > > > > > distribute this e-mail or its contents to any other person and any > > such > > > > > actions are unlawful and strictly prohibited. This e-mail may > contain > > > > > viruses. NxtGen Datacenter & Cloud Technologies Private Ltd > > (“NxtGen”) > > > has > > > > > taken every reasonable precaution to minimize this risk but is not > > > liable > > > > > for any damage you may sustain as a result of any virus in this > > > e-mail. You > > > > > should carry out your own virus checks before opening the e-mail or > > > > > attachment. NxtGen reserves the right to monitor and review the > > > content of > > > > > all messages sent to or from this e-mail address. Messages sent to > or > > > from > > > > > this e-mail address may be stored on the NxtGen e-mail system. *** > > End > > > of > > > > > Disclaimer ***NXTGEN*** > > > > > > > > > > Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL > > INFORMATION intended solely for the use of the addressee(s). If you are > not > > the intended recipient, please notify the sender by e-mail and delete the > > original message. Further, you are not authorised to copy, disclose, or > > distribute this e-mail or its contents to any other person and any such > > actions are unlawful and strictly prohibited. This e-mail may contain > > viruses. NxtGen Datacenter & Cloud Technologies Private Ltd (“NxtGen”) > has > > taken every reasonable precaution to minimize this risk but is not liable > > for any damage you may sustain as a result of any virus in this e-mail. > You > > should carry out your own virus checks before opening the e-mail or > > attachment. NxtGen reserves the right to monitor and review the content > of > > all messages sent to or from this e-mail address. Messages sent to or > from > > this e-mail address may be stored on the NxtGen e-mail system. *** End of > > Disclaimer ***NXTGEN*** > > > Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL > INFORMATION intended solely for the use of the addressee(s). If you are not > the intended recipient, please notify the sender by e-mail and delete the > original message. Further, you are not authorised to copy, disclose, or > distribute this e-mail or its contents to any other person and any such > actions are unlawful and strictly prohibited. This e-mail may contain > viruses. NxtGen Datacenter & Cloud Technologies Private Ltd (“NxtGen”) has > taken every reasonable precaution to minimize this risk but is not liable > for any damage you may sustain as a result of any virus in this e-mail. You > should carry out your own virus checks before opening the e-mail or > attachment. NxtGen reserves the right to monitor and review the content of > all messages sent to or from this e-mail address. Messages sent to or from > this e-mail address may be stored on the NxtGen e-mail system. *** End of > Disclaimer ***NXTGEN*** >
