[kolla][nova][neutron] Access to VMs is slow when running on a remote compute host

Giuseppe Sannino km.giuseppesannino at gmail.com
Fri Jul 12 13:57:48 UTC 2019

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)
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,

*> 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
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network

>>>>> 10 to 15 seconds later

debug3: receive packet: type 80
debug1: client_input_global_request: rtype 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190712/bd984f1d/attachment.html>

More information about the openstack-discuss mailing list