So we need a watchdog to let docker know when the container should be destroyed. Without taking this into account, as soon as that command returns the container will be destroyed. We’ll be using the VBoxManage command to spawn the VM, and that command starts the VM and returns shortly thereafter.
Another detail to add has to do with the container lifecycle. To implement this we’ll need to install the VirtualBox Extension Pack for the specific version of VirtualBox that gets installed, and I’ve incorporated that into the Dockerfile. VRDP does not include the normal VirtualBox interface, but rather just an RDP view of the virtual machine that doesn’t rely on services inside the guest VM. The VirtualBox Extension Pack includes VirtualBox Remote Display Protocol (VRDP), which is an implementation of RDP at the VirtualBox level. It is possible to install the normal VirtualBox GUI into the container and use remote X Windows (typically ssh -X) to access it. To have access to the VMs from the VirtualBox level (so we could, potentially, do OS installs and such) we should have access to some form of remote GUI. This gave me a great point to start from.
There are plenty of Internet resources for that.įor this task I, once again, plagiarized Jess Frazelle’s application container expertise and took a look at her VirtualBox Dockerfile. Note: This blog does not go into installing Docker. Turns out that VirtualBox can accommodate quite nicely! So let’s set it up…
In this case, we’re talking about running a VM in a container on Linux in a headless mode - could be considered a service. The twist is that the context of those blogs have to do with GUI apps that are in your face. If you’ve read my other blogs on containerizing desktop applications (links at the bottom of this page) it should be no surprise that running VirtualBox in Docker would be one of my thoughts. Because the machine’s main job is not virtualization I didn’t want to install a native virtualization stack (Xen, KVM) and wondered how I could continue to use VirtualBox (zero VM conversions!). So I put some thought into running these VM workloads in that context. I have a different machine that I run as a headless storage node, and much of the time it’s rather idle. Just wanted to avoid the CPU/memory contention and such. I recently made some changes with respect to my personal computing environment such that I really didn’t want to use my desktop’s resources to run VMs in the background while I did work in the foreground. For simple virtual machines that I only need occasionally, or for short duration, I’ve found VirtualBox to be an easy solution. I’ve been a virtualization guy since VMware was at beta 1 of ESX. Headless VirtualBox in a Docker Container:
0 kommentar(er)
