Answers: <p>It looks like issue with ssh timeout is related to nested visualization restrictions. Thus, despite of enabling visualization in BIOS VM in container will still not be provisioned. I found similar answer <a href="https://superuser.com/questions/1121843/ssh-vagrant-not-working-inside-virtual-box-vm">here</a>.</p>
  
  <p>Once I started Docker container on host OS, issue has gone away and VM successfully provisioned. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-02T12:57:02.017Z
Answers: This answers boils down to "I've absolutely no idea why it doesn't work, but let's say its an obscure feature in the BIOS"...
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-02T14:33:29.103Z
Answers: It doesn't work because my case assumes nested virtualization usage. VBOX doesn't support nested virtualization, here is a ticket regarding it:  https://www.virtualbox.org/ticket/4032
Answers: user54
Answers: CC BY-SA 3.0
Answers: 2017-10-02T15:15:38.330Z
Answers: And in this very specific ticket there's [this comment](https://www.virtualbox.org/ticket/4032#comment:13): " Even with VirtualBox it is possible to execute VirtualBox without VT-x/AMD-V as a guest of VirtualBox with VT-x/AMD-V enabled."
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-02T17:41:43.850Z
Answers: Partly yes, it may be achieved by specifying 1 CPU only, but it doesn't guarantee that the rest of VM functional will be workable. In some cases depending on distro and architecture may be no issues but in others such restrictions like ssh access etc exist.
Answers: user54
Answers: CC BY-SA 3.0
Answers: 2017-10-02T18:22:22.667Z
Answers: This doesn't make sense for me, VTX instructions are specific interruptions at processor level, this has nothing to do with the number of core (hopefully or hyperv first revision   Wouldn't have existed, windows kernel at this time had no clue about those instructions but allowed 4vcpu vm) When playing Frankenstein nesting virtualization layers you have to learn deeply what it involves, there's no problem for me not understating it fully, it is a problem when you present it as a definitive answer on a question no one can reproduce because you eluded all versions of software and spec details
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-02T18:25:32.710Z
Answers: In brief: I wish answers here on deep technical problems like this one to be backed up by a clear analysis and not by a guess. Dig on how to run virtual box without VTx support within your container and you'll solve your problem.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-02T12:46:05.627Z
Answers: 2017-10-02T12:46:05.627Z
Answers: user54
Body: <p>I have a Docker image based on Ubuntu Xenial. Inside that container I try to start FreeBSD VM by using Vagrant and VirtualBox (Note: host OS for Docker is VM based on Vagrant and VirtualBox). VM is being provisioned fine, however, Vagrant can not ssh there. I also tried ssh with debug within container: </p>
  
  <pre><code># ssh -vvv -p 2222 vagrant@127.0.0.1
  OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug2: resolving "127.0.0.1" port 2222
  debug2: ssh_connect_direct: needpriv 0
  debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519 type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
  ssh_exchange_identification: read: Connection reset by peer
  </code></pre>
  
  <p>The same from host OS:</p>
  
  <pre><code># ssh -p 1111 vagrant@127.0.0.1
  ssh_exchange_identification: read: Connection reset by peer
  </code></pre>
  
  <p>I run container with the next parameters:</p>
  
  <pre><code>docker run --privileged -v /dev:/dev -p 1111:2222 vm:latest
  </code></pre>
  
  <p>I tried to run lightweight image like it was described <a href="https://github.com/zoobab/vagrant-inside-docker" rel="nofollow noreferrer">here</a> and everything started successfully. </p>
  
  <p>Any suggestions/ideas regarding it?</p>
  
  <p>Note: I start a VM in a docker container
  because I don't want to make garbage etc within my desktop OS and I don't have a hardware where I could test it. Therefore my approach is to use VM for this.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-10-02T13:54:21.657Z
Comments: @030 It's actually a VM in a docker container in a VM. Just so you understand all of the gore.
Comments: Briansbum
Comments: CC BY-SA 3.0
Comments: 2017-10-02T14:03:41.380Z
Comments: @030 Yes, but why not run just a docker container?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2020-01-22T10:50:13.193Z
Comments: I dont get it, this makes no sense at all?
Comments: chris polzer
Tags: <docker><vagrant>
Title: SSH to VM inside Docker container
UserDisplayName: user54
ThreadText: # SSH to VM inside Docker container
  
  (Asked by: username_0 on 2017-10-02)
  
  I have a Docker image based on Ubuntu Xenial. Inside that container I try to start FreeBSD VM by using Vagrant and VirtualBox (Note: host OS for Docker is VM based on Vagrant and VirtualBox). VM is being provisioned fine, however, Vagrant can not ssh there. I also tried ssh with debug within container:
  
  ```
  # ssh -vvv -p 2222 vagrant@127.0.0.1
  OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug2: resolving "127.0.0.1" port 2222
  debug2: ssh_connect_direct: needpriv 0
  debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_rsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_dsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ecdsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519 type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /root/.ssh/id_ed25519-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
  ssh_exchange_identification: read: Connection reset by peer
  
  ```
  
  The same from host OS:
  
  ```
  # ssh -p 1111 vagrant@127.0.0.1
  ssh_exchange_identification: read: Connection reset by peer
  
  ```
  
  I run container with the next parameters:
  
  ```
  docker run --privileged -v /dev:/dev -p 1111:2222 vm:latest
  
  ```
  
  I tried to run lightweight image like it was described [here](https://github.com/zoobab/vagrant-inside-docker) and everything started successfully.
  
  Any suggestions/ideas regarding it?
  
  Note: I start a VM in a docker container
  because I don't want to make garbage etc within my desktop OS and I don't have a hardware where I could test it. Therefore my approach is to use VM for this.
  
  **Tags:** docker, vagrant
  
  > **Comments:**
  > **username_1**: @username_2 It's actually a VM in a docker container in a VM. Just so you understand all of the gore.  
  > **username_2**: @username_2 Yes, but why not run just a docker container?  
  > **username_3**: I dont get it, this makes no sense at all?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-10-02. Score: 0 | Accepted answer
  
  It looks like issue with ssh timeout is related to nested visualization restrictions. Thus, despite of enabling visualization in BIOS VM in container will still not be provisioned. I found similar answer [here](https://superuser.com/questions/1121843/ssh-vagrant-not-working-inside-virtual-box-vm).
  
  Once I started Docker container on host OS, issue has gone away and VM successfully provisioned.
  
  > **Comments:**
  > **username_4**: This answers boils down to "I've absolutely no idea why it doesn't work, but let's say its an obscure feature in the BIOS"...  
  > **username_0**: It doesn't work because my case assumes nested virtualization usage. VBOX doesn't support nested virtualization, here is a ticket regarding it:  https://www.virtualbox.org/ticket/4032  
  > **username_4**: And in this very specific ticket there's [this comment](https://www.virtualbox.org/ticket/4032#comment:13): " Even with VirtualBox it is possible to execute VirtualBox without VT-x/AMD-V as a guest of VirtualBox with VT-x/AMD-V enabled."  
  > **username_0**: Partly yes, it may be achieved by specifying 1 CPU only, but it doesn't guarantee that the rest of VM functional will be workable. In some cases depending on distro and architecture may be no issues but in others such restrictions like ssh access etc exist.  
  > **username_4**: This doesn't make sense for me, VTX instructions are specific interruptions at processor level, this has nothing to do with the number of core (hopefully or hyperv first revision   Wouldn't have existed, windows kernel at this time had no clue about those instructions but allowed 4vcpu vm) When playing Frankenstein nesting virtualization layers you have to learn deeply what it involves, there's no problem for me not understating it fully, it is a problem when you present it as a definitive answer on a question no one can reproduce because you eluded all versions of software and spec details  
  > **username_4**: In brief: I wish answers here on deep technical problems like this one to be backed up by a clear analysis and not by a guess. Dig on how to run virtual box without VTx support within your container and you'll solve your problem.  
  
  ---
  
  