<div dir="ltr">Hi Radoslaw, all,<div>I applied the GSSAPIAuthentication setting along with the UseDNS one. No luck.</div><div><br></div><div>One thing I want to share and that maybe goes in a "no network" direction.</div><div>I disabled the execution of the motd script during the login phase via "chmod -x /etc/update-motd.d/*".</div><div>I'm able to reduce the login time from ~12secs down to ~3sec.</div><div><br></div><div>To me, it looks like the issue is with the access in RW to the Guest VM filesystem which takes quite a while.</div><div><br></div><div>One more thing, in the tcpdump trace, during the SSH login, I can see that when the procedure gets stuck (that pledge network... log in ssh) is the Server (so the Guest OS) that takes time to reply with a "Server packet.</div><div>But, I can see a TCP ACK sent back from the server. This makes me quite sure that from a networking point of view the things are handled with no delay.</div><div><br></div><div>/G</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 Jul 2019 at 19:27, Radosław Piliszek <<a href="mailto:radoslaw.piliszek@gmail.com">radoslaw.piliszek@gmail.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"><div dir="ltr">For completeness - always also ensure that 'GSSAPIAuthentication' is set to 'no' because in default config it might require DNS lookups too.<div>(Obviously you can run GSSAPIAuthentication and avoid DNS lookups by configuring GSSAPI appropriately ;-) ).<br><div><div><div><br></div><div>Kind regards,</div><div>Radek</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pon., 15 lip 2019 o 19:14 Giuseppe Sannino <<a href="mailto:km.giuseppesannino@gmail.com" target="_blank">km.giuseppesannino@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Alex,<div>yeah, it was the first suspect also based on the various research on internet.</div><div>I currently have the "useDNS" set to no but still the issue persists.</div><div><br></div><div>/G</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 Jul 2019 at 18:46, Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@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"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2019 at 10:40 AM Giuseppe Sannino <<a href="mailto:km.giuseppesannino@gmail.com" target="_blank">km.giuseppesannino@gmail.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"><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></blockquote><div><br></div><div>Are you having dns issues? Historically if you have UseDNS set to true and your dns servers are bad it can just be slow to connect as it tries to do the reverse lookup.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></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" target="_blank">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>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>