It looks like ssh on the management node is using a ConnectTimeout value of 2 seconds: debug3: timeout: 1999 ms remain after connect
Does specifying a longer time make a difference? ssh -o ConnectTimeout=10 -vvvv vm79 On Wed, Apr 2, 2014 at 11:19 AM, Curtis <[email protected]> wrote: > Hi Andy, > > Thanks, inline... > > On Wed, Apr 2, 2014 at 8:22 AM, Andy Kurth <[email protected]> wrote: > > I can't tell from just the commands. They look normal. Were there any > > WARNING messages during the image process prior to the reboot? > > > > What error message is reported when you try to ssh from the management > > node? (Connection timed out, etc) It may be helpful if you send the > output > > from running "ssh -v <win_computer>". > > > > This is what that output looks like: > > [root@VCL-PROD:~] $ ssh -vvvv vm79 > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /root/.ssh/config > debug1: Applying options for vm* > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to vm79 [10.1.0.195] port 22. > debug2: fd 3 setting O_NONBLOCK > debug1: fd 3 clearing O_NONBLOCK > debug1: Connection established. > debug3: timeout: 1999 ms remain after connect > debug1: permanently_set_uid: 0/0 > debug3: Not a RSA1 key file /etc/vcl/vcl.key. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /etc/vcl/vcl.key type 1 > debug1: identity file /etc/vcl/vcl.key-cert type -1 > Connection timed out during banner exchange > > > To troubleshoot, you'll need to login as root using the password which > was > > redacted from the vcld.log output. Check the following: > > > > Is the Cygwin SSHD service running? If not, try to start it. If you get > > an error related to incorrect credentials then something went wrong when > > root's password was set early on in the image capture process. > > It's usually hung up, ie. won't respond to commands. > > If I login to the vm on its console (with virt-manager) then sshd > can't be restarted from the windows service console, or cygrunsrv, but > if I kill it with taskill and then start it, it starts up fine. > > Something to do with long logon times maybe? > > > > > If SSHD is running, it could be a firewall problem. Try simply turning > off > > the firewall temporarily on the Windows computer and try to ssh from the > > management node. > > The windows fw is not on, or at least it says it's not on. It's turned > off in the image. > > > > > If the firewall isn't the problem, something isn't configured correctly > > with the sshd service. While logged in as root, you can try running > > C:\cygwin\root\VCL\Scripts\update_cygwin.cmd. This gets run > automatically > > when an image is loaded and configures sshd correctly and starts the > > service. If running this solves the problem, then you'll have to figure > > out which commands or changes made by this script fixed it. If possibly, > > it will be easier to troubleshoot if you take a snapshot of the computer > > before running this script so that you can revert to the broken state in > > order to narrow down the problem. > > > > Ok will give the update_cygwin.cmd a shot. > > Thanks, > Curtis. > > > -Andy > > > > > > > > > > On Tue, Apr 1, 2014 at 6:28 PM, Curtis <[email protected]> wrote: > > > >> On Tue, Apr 1, 2014 at 4:16 PM, Curtis <[email protected]> wrote: > >> > Hi All, > >> > > >> > We are having an issue with some of our images where when we try to > >> > create a new image from an existing image, everything goes ok until > >> > the part where the virtual machine is rebooted, and after it's > >> > rebooted sshd does not start up and the imaging process fails. > >> > > >> > Anyone have any thoughts? I'm fairly sure it has something to do with > >> > the various commands that are run on the image once an image creation > >> > process starts. > >> > >> Also, this gist has all the commands that are being run: > >> > >> https://gist.github.com/curtisgithub/6117a73b47e994d9be03 > >> > >> But I'm not much of a windows administrator -- does anyone see > >> anything unusual in that gist that might be causing issues? Perhaps > >> something with the root logon or password? > >> > >> > > >> > Thanks, > >> > Curtis. > >> > > >> > -- > >> > Twitter: @serverascode > >> > Blog: serverascode.com > >> > >> > >> > >> -- > >> Twitter: @serverascode > >> Blog: serverascode.com > >> > > > > -- > Twitter: @serverascode > Blog: serverascode.com >
