<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>

CC BY-SA 3.0
2017-10-02T12:57:02.017Z
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"...
Tensibai
CC BY-SA 3.0
2017-10-02T14:33:29.103Z
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
user54
CC BY-SA 3.0
2017-10-02T15:15:38.330Z
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."
Tensibai
CC BY-SA 3.0
2017-10-02T17:41:43.850Z
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.
user54
CC BY-SA 3.0
2017-10-02T18:22:22.667Z
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
Tensibai
CC BY-SA 3.0
2017-10-02T18:25:32.710Z
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.
Tensibai
CC BY-SA 3.0
2017-10-02T12:46:05.627Z
2017-10-02T12:46:05.627Z
user54
<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>

CC BY-SA 3.0
2017-10-02T13:54:21.657Z
@030 It's actually a VM in a docker container in a VM. Just so you understand all of the gore.
Briansbum
CC BY-SA 3.0
2017-10-02T14:03:41.380Z
@030 Yes, but why not run just a docker container?
030
CC BY-SA 4.0
2020-01-22T10:50:13.193Z
I dont get it, this makes no sense at all?
chris polzer
<docker><vagrant>
SSH to VM inside Docker container
user54
# 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 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.  

---

