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

Mark Goddard mark at stackhpc.com
Fri Jul 12 15:35:50 UTC 2019


On Fri, 12 Jul 2019 at 15:24, 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.
>

+1 - ~30s timeout on SSH login is normally a DNS issue.


> -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
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190712/c9932c3d/attachment.html>


More information about the openstack-discuss mailing list