Automatic fallback to serial console when SSH doesn't work (because of VPN, etc)

[volkertb]

There are currently several issues (including #3236 and boot2docker/boot2docker#628) pertaining to the pesky VPN problem when running Docker on a hypervisor such as VirtualBox. In short: VPN clients hijack all routes on the underlying host machine, making it impossible for the host machine to access the virtual (host-only) network interfaces through which virtualized Docker machines usually make themselves available to the physical host machine.

A possible workaround that I described at boot2docker/boot2docker#628 (comment) entails the use of a serial console (which boot2docker supports out of the box, even though this feature is apparently not well documented). However, this requires a user to manually set up an emulated serial connection between the host computer and the VM.

It would be much more practical if the docker-machine tool (and also any other tools in de Docker toolbox that remotely access Docker machines over SSH) gained the possibility to set up emulated serial interfaces in Docker machines (at least on VirtualBox, which supports those) and use such interfaces to automatically fall back to a connection over a serial console whenever SSH connections would fail. It would be great if this could be done transparently, other than displaying a warning to the user that the SSH connection was lost and the fallback to a serial connection was necessary.

I don't immediately see any security issues regarding such a feature, since an emulated serial connection would not travel over a network. Any exchange of sensitive data over such virtual connections would only take place within the same physical machine. Of course I understand that a fallback over an automatically emulated serial connection would not always be available, for instance when the docker-machine client tool and the machine VM were not running on the same physical computer. But then again, the VPN issue usually does not occur in such more complicated setups. In most cases, the VPN problem rears its ugly head on laptops running the VMs locally.

Please consider this enhancement. It would make things a lot more convenient to a lot of people, as well as make for a more robust Docker environment on laptops and desktop machines. Thank you.

[nathanleclaire]

It's an interesting idea... The network certainly causes nothing but problems in these highly restrictive environments (and that's assuming vbox networking doesn't have its own bugs at play!!)

[volkertb]

Of course, one might want to limit certain functionality in such a hypothetical fallback mode. For instance, we probably don't want the Docker client to send hundreds of megabytes of build context to the Docker daemon over a serial link. ;-) Right now, I'm thinking about an emergency fallback mode for the docker-machine tool only, perhaps with reduced functionality.

[caleyg]

Just chiming in here, I think this would be a great value add. As I would like to leverage docker-compose from the host to build containers in the default vm docker-machine created for me in VirtualBox.
I'm currently on a highly restrictive VPN enterprise connection (Cisco AnyConnect) and currently I can only interact with the containers on this vm from a serial port via PuTTy.

[baybal]

don't want the Docker client to send hundreds of megabytes of build context to the Docker daemon over a serial link. ;-) Right now, I'm thinking about an emergency fallback mode for the docker-machine tool only, perhaps with reduced functionality.

Why so @volkertb ? You don't have to emulate 80386 interrupt driven serial. There are Linux VM drivers that handle serial on a higher level, with orders of magnitude higher throughput. Virtio serial and hyper-v hypercalls ARE faster than emulated network by huge margin.

[volkertb]

I hadn't considered that, @baybal. I agree, that would be even better. 🙂

[volkertb]

So would any developers be willing to take a shot at this?