Hi, I suspect some problems with names resolving. Can You check if You have also such delay when doing e.g. “sudo” commands after You ssh to the instance?
On 12 Jul 2019, at 16:23, Brian Haley <haleyb.dev@gmail.com> wrote:
On 7/12/19 9:57 AM, Giuseppe Sannino wrote:
Hi community, I need your help ,tips, advices. *> Environment <* I have deployed Openstack "Stein" using the latest kolla-ansible on the following deployment topology: 1) OS Controller running as VM on a "cloud" location 2) OS Compute running on a baremetal server remotely (wrt OS Controller) location 3) Network node running on the Compute host As per the above info, Controller and compute run on two different networks. Kolla-Ansible is not really designed for such scenario but after manipulating the globals.yml and the inventory files (basically I had to move node specific network settings from the globals to the inventory file), eventually the deployment works fine. *> Problem <* I have no specific issue working with this deployment except the following: "SSH connection to the VM is quite slow". It takes around 20 seconds for me to log into the VM (Ubuntu, CentOS, whatever).
But once logged-in things are OK? For example, an scp stalls the same way, but the transfer is fast?
*> Observations <* * Except for the slowness during the SSH login, I don't have any further specific issue working with this envirorment * With the Network on the Compute I can turn the OS controller off with no impact on the VM. Still the connection is slow * I tried different type of images (Ubuntu, CentOS, Windows) always with the same result. * SSH connection is slow even if I try to login into the VM within the IP Namespace From the ssh -vvv, I can see that the authentication gets stuck here: debug1: Authentication succeeded (publickey). Authenticated to ***** debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions@openssh.com <mailto:no-more-sessions@openssh.com> debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network
> 10 to 15 seconds later
What is sshd doing at this time? Have you tried enabling debug or running tcpdump when a new connection is attempted? At first glance I'd say it's a DNS issue since it eventually succeeds, the logs would help to point in a direction.
-Brian
debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00@openssh.com <mailto:hostkeys-00@openssh.com> want_reply 0 debug3: receive packet: type 91 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 Have you ever experienced such issue ? Any suggestion? Many thanks /Giuseppe
— Slawek Kaplonski Senior software engineer Red Hat