Open Stack

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 at 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 at openssh.com <mailto:no-more-sessions at 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 at openssh.com <mailto:hostkeys-00 at 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