<div dir="ltr">Hi Sean,<div>the ssh to localhost is slow as well.</div><div>"telnet localhost" is also slow.</div><div><br></div><div>/Giuseppe</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 Jul 2019 at 18:18, Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2019-07-15 at 16:29 +0200, Giuseppe Sannino wrote:<br>
> Hi!<br>
> first of all, thanks for the fast replies. I do appreciate that.<br>
> <br>
> I did some more test trying to figure out the issue.<br>
> - Set UseDNS to "no" in sshd_config  => Issue persists<br>
> - Installed and configured Telnet => Telnet login is slow as well<br>
> <br>
> From the "top" or "auth.log"nothing specific popped up. I can sshd taking<br>
> some cpu for a short while but nothing more than that.<br>
> <br>
> Once logged in the VM is not too slow. CLI doesn't get stuck or similar.<br>
> One thing worthwhile to mention, it seems like the writing throughput on<br>
> the disk is a bit slow: 67MB/s  wrt around 318MB/s of another VM running on<br>
> a "datacenter" Openstack installation.<br>
unless you see iowait in the guest its likely not related to the disk speed.<br>
you might be able to improve the disk performace by changeing the chache mode<br>
but unless you are seeing io wait that is just an optimisation to try later.<br>
<br>
when you are logged into the vm have you tried ssh again via localhost to<br>
determin if the long login time is related to the network or the vm.<br>
<br>
if its related to the network it will be fast over localhost<br>
if its related to the vm, e.g. because of disk, cpu load, memory load or ssh server configuration<br>
then the local ssh will be slow.<br>
<br>
> <br>
> The Cinder Volume docker is running on the Compute Host and Cinder is using<br>
> the filesystem as backend.<br>
> <br>
> BR<br>
> /Giuseppe<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Fri, 12 Jul 2019 at 17:41, Slawek Kaplonski <<a href="mailto:skaplons@redhat.com" target="_blank">skaplons@redhat.com</a>> wrote:<br>
> <br>
> > Hi,<br>
> > <br>
> > I suspect some problems with names resolving. Can You check if You have<br>
> > also such delay when doing e.g. “sudo” commands after You ssh to the<br>
> > instance?<br>
> > <br>
> > > On 12 Jul 2019, at 16:23, Brian Haley <<a href="mailto:haleyb.dev@gmail.com" target="_blank">haleyb.dev@gmail.com</a>> wrote:<br>
> > > <br>
> > > <br>
> > > <br>
> > > On 7/12/19 9:57 AM, Giuseppe Sannino wrote:<br>
> > > > Hi community,<br>
> > > > I need your help ,tips, advices.<br>
> > > > *> Environment <*<br>
> > > > I have deployed Openstack "Stein" using the latest kolla-ansible on the<br>
> > <br>
> > following deployment topology:<br>
> > > > 1) OS Controller running as VM on a "cloud" location<br>
> > > > 2) OS Compute running on a baremetal server remotely (wrt OS<br>
> > <br>
> > Controller) location<br>
> > > > 3) Network node running on the Compute host<br>
> > > > As per the above info, Controller and compute run on two different<br>
> > <br>
> > networks.<br>
> > > > Kolla-Ansible is not really designed for such scenario but after<br>
> > <br>
> > manipulating the globals.yml and the inventory files (basically I had to<br>
> > move node specific network settings from the globals to the inventory<br>
> > file), eventually the deployment works fine.<br>
> > > > *> Problem <*<br>
> > > > I have no specific issue working with this deployment except the<br>
> > <br>
> > following:<br>
> > > > "SSH connection to the VM is quite slow".<br>
> > > > It takes around 20 seconds for me to log into the VM (Ubuntu, CentOS,<br>
> > <br>
> > whatever).<br>
> > > <br>
> > > But once logged-in things are OK?  For example, an scp stalls the same<br>
> > <br>
> > way, but the transfer is fast?<br>
> > > <br>
> > > > *> Observations <*<br>
> > > >  * Except for the slowness during the SSH login, I don't have any<br>
> > > >    further specific issue working with this envirorment<br>
> > > >  * With the Network on the Compute I can turn the OS controller off<br>
> > > >    with no impact on the VM. Still the connection is slow<br>
> > > >  * I tried different type of images (Ubuntu, CentOS, Windows) always<br>
> > > >    with the same result.<br>
> > > >  * SSH connection is slow even if I try to login into the VM within the<br>
> > > >    IP Namespace<br>
> > > > From the ssh -vvv, I can see that the authentication gets stuck here:<br>
> > > > debug1: Authentication succeeded (publickey).<br>
> > > > Authenticated to *****<br>
> > > > debug1: channel 0: new [client-session]<br>
> > > > debug3: ssh_session2_open: channel_new: 0<br>
> > > > debug2: channel 0: send open<br>
> > > > debug3: send packet: type 90<br>
> > > > debug1: Requesting <a href="mailto:no-more-sessions@openssh.com" target="_blank">no-more-sessions@openssh.com</a> <mailto:<br>
> > <br>
> > <a href="mailto:no-more-sessions@openssh.com" target="_blank">no-more-sessions@openssh.com</a>><br>
> > > > debug3: send packet: type 80<br>
> > > > debug1: Entering interactive session.<br>
> > > > debug1: pledge: network<br>
> > > > > > > > > 10 to 15 seconds later<br>
> > > <br>
> > > What is sshd doing at this time?  Have you tried enabling debug or<br>
> > <br>
> > running tcpdump when a new connection is attempted?  At first glance I'd<br>
> > say it's a DNS issue since it eventually succeeds, the logs would help to<br>
> > point in a direction.<br>
> > > <br>
> > > -Brian<br>
> > > <br>
> > > <br>
> > > > debug3: receive packet: type 80<br>
> > > > debug1: client_input_global_request: rtype <a href="mailto:hostkeys-00@openssh.com" target="_blank">hostkeys-00@openssh.com</a><br>
> > <br>
> > <mailto:<a href="mailto:hostkeys-00@openssh.com" target="_blank">hostkeys-00@openssh.com</a>> want_reply 0<br>
> > > > debug3: receive packet: type 91<br>
> > > > debug2: callback start<br>
> > > > debug2: fd 3 setting TCP_NODELAY<br>
> > > > debug3: ssh_packet_set_tos: set IP_TOS 0x10<br>
> > > > debug2: client_session2_setup: id 0<br>
> > > > debug2: channel 0: request pty-req confirm 1<br>
> > > > Have you ever experienced such issue ?<br>
> > > > Any suggestion?<br>
> > > > Many thanks<br>
> > > > /Giuseppe<br>
> > <br>
> > —<br>
> > Slawek Kaplonski<br>
> > Senior software engineer<br>
> > Red Hat<br>
> > <br>
> > <br>
<br>
</blockquote></div>