Installation of latest vs explicit virtualbox version

[joeltimothyoh]

Presently virtualbox packages installed implicitly meaning latest versions are installed in built images. Just wondering this is intentionally designed to be so.

For explicit versions the individual .deb packages can be installed for instance like so:

echo "Installing virtualbox" \
    && wget https://download.virtualbox.org/virtualbox/6.1.26/virtualbox-6.1_6.1.26-145957~Ubuntu~eoan_amd64.deb -O /tmp/virtualbox-6.1_6.1.26-145957~Ubuntu~eoan_amd64.deb \
    && apt-get install -y /tmp/virtualbox-6.1_6.1.26-145957~Ubuntu~eoan_amd64.deb \
    && rm -f /tmp/virtualbox-6.1_6.1.26-145957~Ubuntu~eoan_amd64.deb

[leojonathanoh]

@joeltimothyoh it's intentional to use the latest version of virtualbox. In general, each distro version has it's "coupled" packages, so ubuntu 18.04 will never go beyond virtualbox 5.x, and ubuntu 20.04 should never go beyond virtualbox 6.x.

To install explicity virtualbox version can break builds whenever any virtualbox release, because the apt packages will remove the older virtualbox packages. So unless there's a bot to check for releases, and to bump the virtualbox version to the specific package (imo a bit complex, and not very necessary), the latest version might suffice. Also, packer generally uses virtualbox in a rather generic way, so most packer versions generally work with most virtualbox versions.

[joeltimothyoh]

@joeltimothyoh it's intentional to use the latest version of virtualbox. In general, each distro version has it's "coupled" packages, so ubuntu 18.04 will never go beyond virtualbox 5.x, and ubuntu 20.04 should never go beyond virtualbox 6.x.

Well true though we're dealing with containers here rather than host OSes. It doesn't matter so much what the container OS version or even OS is than the stability of the application running within the container on the host.

To install explicity virtualbox version can break builds whenever any virtualbox release, because the apt packages will remove the older virtualbox packages.

I'm not sure I understand. Packages are installed and so frozen within a docker image.

Also, packer generally uses virtualbox in a rather generic way, so most packer versions generally work with most virtualbox versions.

That's an assumption I'm not saying is incorrect but that's rather faith based.

[leojonathanoh]

Well true though we're dealing with containers here rather than host OSes. It doesn't matter so much what the container OS version or even OS is than the stability of the application running within the container on the host.

The container OS determines the package version that will be installed and be running inside the container.

I'm not sure I understand. Packages are installed and so frozen within a docker image.

Whenever a distro bumps a package like e.g. virtualbox=6.1.16-dfsg-6~ubuntu1.20.04.2 to 6.1.20-dfsg-6~ubuntu1.20.04.2 for instance, the Dockerfile that specifies a stale version virtualbox=6.1.16-dfsg-6~ubuntu1.20.04.2 will now fail . Notice the apt-cache by default only shows packages from focal-updates/multiverse source, basically the "latest" and "stablest" build only.

root@b82d1b49475c:/# apt-cache madison virtualbox
virtualbox | 6.1.26-dfsg-3~ubuntu1.20.04.2 | http://archive.ubuntu.com/ubuntu focal-updates/multiverse amd64 Packages
virtualbox | 6.1.16-dfsg-6~ubuntu1.20.04.2 | http://security.ubuntu.com/ubuntu focal-security/multiverse amd64 Packages
virtualbox | 6.1.6-dfsg-1 | http://archive.ubuntu.com/ubuntu focal/multiverse amd64 Packages

That's an assumption I'm not saying is incorrect but that's rather faith based.

If you look at packer docs on virtualbox* builders, they do not mention much about virtualbox versions, its because the virtualbox packer builder generally is not breaking, and virtualbox major versions generally don't break behavior that the virtualbox* packer builders use.

[joeltimothyoh]

The container OS determines the package version that will be installed and be running inside the container.

Whenever a distro bumps a package like e.g. virtualbox=6.1.16-dfsg-6~ubuntu1.20.04.2 to 6.1.20-dfsg-6~ubuntu1.20.04.2 for instance, the Dockerfile that specifies a stale version virtualbox=6.1.16-dfsg-6~ubuntu1.20.04.2 will now fail . Notice the apt-cache by default only shows packages from focal-updates/multiverse source, basically the "latest" and "stablest" build only.

See OP again for installing specific virtualbox versions via .deb packages without apt-get.

If you look at packer docs on virtualbox builders, they do not mention much about virtualbox versions, its because the virtualbox packer builder generally is not breaking, and virtualbox major versions generally don't break behavior that the virtualbox packer builders use.

Sure thing, though it isn't so much packer that would break things than virtualbox which might happen to release breaking updates.

Know that I'm not suggesting having to specify specific versions of packages. It might suffice to install latest versions via apt-get and building only later container OS images.

[leojonathanoh]

ok. what do you suggest, should we be using apt or .deb packages for virtualbox ?

[joeltimothyoh]

ok. what do you suggest, should we be using apt or .deb packages for virtualbox ?

With .deb packages virtualbox versions can be consistent across images. Though it's rather pointless actually building so many variant OS images.

[leojonathanoh]

im split on this one. also, using .deb doesn't mean we have to build so many variants for virtualbox versions, perhaps we can just stick to virtualbox 6.1

[joeltimothyoh]

After extensive use of docker the container OS really doesn't really matter or get in the way of compatibility more than updates to applications themselves which breaks things. With 6.1 I suppose ubuntu-20.04 images are required if installed via apt. Then again, virtualbox 6.1 is still a little generic - the further question would be which 6.1.* version to use.

With apt, the latest version would be installed. Convenient, though potentially breaking and virtualbox versions will hop without notice.

With .deb, specific versions can be installed. Adds administrative overhead as virtualbox versions would have to be bumped. Specific (usually non-latest) versions of virtualbox can be specified and used for extended periods of time. Minimizes possible incompatibilities between installed packer and latest virtualbox versions.

[leojonathanoh]

The important thing to note is to use virtualbox docker image, one needs to mount /dev/vboxdrv from the docker host into the container, meaning the docker host must run the same virtualbox major version as the docker image.

I did try to use virtualbox 5 on the host and virtualbox 6 docker image, but it failed. So i believe the important thing here is to match virtualbox major versions on the host and the docker image.

Alternatively, one may also match OS versions on the host and the docker. Assuming both the host and the docker image use apt, matching on OS version e.g. ubuntu 20.04 will generally be fine, because OS versions generally do not bump the major version of a binary like virtualbox, unless the binary is very very outdated. Meaning ubuntu 20.04 will stick to virtualbox 6 for its lifetime or for a long time.

With apt, the latest version would be installed. Convenient, though potentially breaking and virtualbox versions will hop without notice.

With .deb, specific versions can be installed. Adds administrative overhead as virtualbox versions would have to be bumped. Specific (usually non-latest) versions of virtualbox can be specified and used for extended periods of time. Minimizes possible incompatibilities between installed packer and latest virtualbox versions.

i'd think with apt, one gets the latest stablest versions (i.e. they push bugfix versions pretty quickly). While using .deb is good for sticking with one very stable version.

[joeltimothyoh]

Remind again why virtualbox has to be installed on the host at all since having so defeats the purpose of building a container with it installed. @leojonathanoh

[leojonathanoh]

@joeltimothyoh virtualization is a feature of a cpu. in order to run VMs, the container itself must have access to the virtualization device.

[joeltimothyoh]

I would think some of such devices would exist independently of virtualization software like virtualbox and that they need to simply be exposed to the container. @leojonathanoh

[leojonathanoh]

not aware of any so far for containers. nested virtualization for VMs is the easiest way.

[joeltimothyoh]

I don’t think nested virtualization has so much to do with containers and the host requiring matching versions of virtualization software. But we’ll have to find out else building images within VMs could suffice.

[leojonathanoh]

It should be the other way around: we already know nested virtualization works in a VM. So if there's a way to do the same in containers, then we can eliminate the need for VM hypervisors. Sure, there might need a "matching" version on the host for container builds, but one could also say there needs to be the overhead of running a hypervisor for VM builds.

[joeltimothyoh]

I'm thinking with containers runtimes supporting virtualization there should be no need for virtualization software on the host

[leojonathanoh]

https://stackoverflow.com/questions/25741904/is-it-possible-to-run-virtualbox-inside-a-docker-container

[leojonathanoh]

https://stackoverflow.com/questions/48422001/how-to-launch-qemu-kvm-from-inside-a-docker-container

[leojonathanoh]

there's always a need for the container to access the virtualization capability on the host using --device.

[joeltimothyoh]

Ok. Though I thought with something like sysbox that such wouldn't be necessary.

[leojonathanoh]

Ok. Though I thought with something like sysbox that such wouldn't be necessary.

i dont think sysbox has the capability of mapping host virtualization capability into the container yet.

Let's track this in https://github.com/nestybox/sysbox/issues/427

[joeltimothyoh]

Just checking if apt is still going for be used for installing virtualbox, and if so, how the workflow would be to get a matching host version or vice-versa.

I personally feel specific versions in .deb packages should be installed instead. @leojonathanoh

[leojonathanoh]

@joeltimothyoh yes we could install .deb instead. in general, using virtualbox builder is not as very good because it needs a matching host version (major version at least), and it cannot run alongside kvm which is used by guestmount etc. As i said, to ensure virtualbox major versions match on host and VM, one just needs to ensure that the host distro is the same as the the VM's, and run apt install virtualbox on both of them. https://github.com/theohbrothers/docker-packer/issues/10#issuecomment-955805484

kvm would be better, and we should move builds over to that.

[joeltimothyoh]

I’m not comprehending. Why the need for VMs now when docker alone could work with matching versions. Unless there’s a real need for guestmount @leojonathanoh

[leojonathanoh]

Why the need for VMs now

packer creates VM images by running VMs, which when dockerized means VMs now run in a container.

when docker alone could work with matching versions.

The issue is not about docker. It applies to any container runtime.

In order to run VMs in a container, the container must have matching binaries to the binaries of host's active hypervisor e.g. for virtualbox, to be able to run a VM in a container, the virtualbox driver must be running among lsmod of the host, and the host's /dev/vboxdrv device be mounted in the container.

Unless there’s a real need for guestmount @leojonathanoh

What i mean in https://github.com/theohbrothers/docker-packer/issues/10#issuecomment-968289857, is that if one wants to create an .iso from a virtual hard disk, guestmount is needed to mount a virtual hard disk in order to extract its contents. Since guestmount works by running a kvm (type 1 hypervisor) underneath, the kvm hypervisor cannot run alongside another hypervisor, e.g. virtualbox (type 2 hypervisor), and this is regardless of whether the VMs are created on the host itself or in separate containers of the same host. For example, suppose two packer instance running on the physical machine, the first packer using a shell-local builder is building an .iso from .vmdk, so a guestmount is mounting a .vmdk on a mountpoint /mnt/vmdk (which actually runs a kvm VM behind the scenes to mount the .vmdk). In such a case, if a second packer spins up a virtualbox VM using the virtualbox-ovf builder , the virtualbox VM startup will fail with error because two hypervisors cannot run on the same physical host:

==> virtualbox-iso: Error starting VM: VBoxManage error: VBoxManage: error: VirtualBox can't enable the AMD-V extension. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_SVM_IN_USE)
==> virtualbox-iso: VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
==> virtualbox-iso: Cleaning up floppy disk...
==> virtualbox-iso: Deregistering and deleting VM...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored after 6 seconds 435 milliseconds: Error starting VM: VBoxManage error: VBoxManage: error: VirtualBox can't enable the AMD-V extension. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_SVM_IN_USE)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

That's why i said to only strictly use kvm, and do away with type 2 hypervisors like virtualbox.

[joeltimothyoh]

I'm thinking in the meantime we could use fixed versions of virtualbox. @leojonathanoh

[leojonathanoh]

@joeltimothyoh ok we can implement that. Just not that that important, the virtualbox versions just have to match on major versions. So ensure match the distro of the host and the docker image and use apt install virtualbox on the host and you will be fine.