Building and running virtualbox with KVM instead of Oracle's kernel module
- Inicie sesión ou rexístrese para enviar comentarios
virtualbox uses a kernel module from Oracle as its hypervisor, which, to my understanding, is a proprietary module. However, you can now build the GPL'd licensed base package of virtualbox with kvm as the hypervisor. I've written down the steps I used to do this.
Links:
Github page with most of these instructions for building virtualbox with KVM: https://github.com/cyberus-technology/virtualbox-kvm
Page to download the virtualbox 7.0.20 source code to follow these instructions: https://www.virtualbox.org/wiki/Download_Old_Builds_7_0
Pre-requisite steps:
I'm not writing about how to set up kvm on your system. I setup kvm on Trisquel 11 by installing qemu - here are my installed qemu packages:
ipxe-qemu-256k-compat-efi-roms
ipxe-qemu
qemu-block-extra
qemu-system-common
qemu-system-data
qemu-system-gui
qemu-system-x86
qemu-utils
Also, I'm running an Intel CPU that is later than 11th generation, and so I had to add a grub command line parameter to disable split-lock detection in order to build this version of virtualbox: split_lock_detect=off
I added that line to the GRUB_CMDLINE_LINUX_DEFAULT parameters in /etc/default/grub, and then ran 'sudo update-grub' and restarted the computer.
====================================================
Main building instructions:
I mainly followed the instructions from https://github.com/cyberus-technology/virtualbox-kvm which are for Ubuntu 22.02, which is the version of Ubuntu that Trisquel 11 is based on. Following these instructions worked great. I normally have been using linux-libre kernel 6.11 recently, but for these build instructions I had to use the default Trisquel 5.15 kernel version.
1. Install the build dependencies (I ran this command with 'sudo apt-get install --dry-run' the first time to test and make sure all these build dependencies would install without a problem) -
sudo apt-get install acpica-tools chrpath doxygen g++-multilib libasound2-dev libcap-dev libcurl4-openssl-dev libdevmapper-dev libidl-dev libopus-dev libpam0g-dev libpulse-dev libqt5opengl5-dev libqt5x11extras5-dev qttools5-dev libsdl1.2-dev libsdl-ttf2.0-dev libssl-dev libvpx-dev libxcursor-dev libxinerama-dev libxml2-dev libxml2-utils libxmu-dev libxrandr-dev make nasm python3-dev python2-dev qttools5-dev-tools texlive texlive-fonts-extra texlive-latex-extra unzip xsltproc default-jdk libstdc++5 libxslt1-dev linux-headers-5.15.0-124 makeself mesa-common-dev subversion yasm zlib1g-dev glslang-tools libc6-dev-i386 lib32stdc++6 libtpms-dev
2. Download the GPL'd virtualbox 7.0.20 source package from Oracle - I got it from here: https://www.virtualbox.org/wiki/Download_Old_Builds_7_0
3. Extract the source code:
tar xf VirtualBox-7.0.20.tar.bz2
4. Clone the git repo for virtualbox-kvm:
git clone https://github.com/cyberus-technology/virtualbox-kvm vbox-kvm
5. Change director into the virtualbox source directory:
cd VirtualBox-7.0.20
6. Run some additional git commands:
git init
git add *
git commit -m "VirtualBox vanilla code"
git am ../vbox-kvm/patches/*.patch
7. Configure the build environment:
./configure --with-kvm --disable-kmods --disable-docs --disable-hardening --disable-java
source ./env.sh
8. Build it:
kmk
9. Post-build - the virtualbox binary that was built will have been placed in out/linux.amd64/release/bin/. Run it from the same build directory with:
./out/linux.amd64/release/bin/VirtualBox
If you have kvm running, it should just work, no need to install any kernel modules or anything. I downloaded and ran Trisquel Mini with it.
===========================================================
Notes:
Don't use the Oracle virtualbox extension pack, as that is proprietary code.
Note: VirtualBox is a trademark owned by Oracle. This how-to has no affiliation with Oracle.
Please let me know any steps I got wrong here.
| Anexo | Tamaño |
|---|---|
| trisquel-mini-on-vboxkvm-on-trisquel.jpg | 114.76 KB |
| trisquel-mini-on-vboxkvm-on-trisquel2.jpg | 113.65 KB |
| trisquel-mini-on-vboxkvm-on-trisquel3.jpg | 86.87 KB |
Update - I had to use the default Trisquel linux-image 5.15 kernel to build vbox, but now I can run it using the linux-libre 6.11 kernel that I had been used to running. I assumed that would be the case, but it is worth noting.
You know what is wrong: those great instructions should be on https://trisquel.info/en/wiki/installing-virtualbox ! Would you edit that page? Thank you!
That wiki says that Virtualbox versions after 4.2 "depend on the non-free open watcom compiler". It was for compiling the VBox BIOS. I wonder if that's still the case. I did a bit of online research to try to find an answer, but I did not find any answer.
The "configure" file at the root of https://download.virtualbox.org/virtualbox/7.1.4/VirtualBox-7.1.4.tar.bz2 includes that comment:
# Check for the OpenWatcom compiler, needed for compiling the BIOS
#
# If the system has Open Watcom installed, WATCOM will be set in the
# environment. If the user has her/his own Open Watcom install it will be
# pointed to by on the command line, which will set the WATCOM variable.
# The only exception is detecting OpenWatcom in tools/common/openwatcom.
In the first line, the word "needed" suggests that Open Watcom is required. It is non-free: https://www.gnu.org/licenses/license-list.html#Watcom
Despite what is written in the last line, there is no tools/common directory in that source code. As a consequence, it does not look like Open Watcom is bundled with VirtualBox.
Little after, a shell function named check_open_watcom includes those lines:
WATCOM=`/bin/ls -rd1 $DEVDIR/common/openwatcom/* 2> /dev/null | head -1`
if [ -z "$WATCOM" ]; then
if [ $OSE -eq 0 -a $OS = "linux" ]; then
log_failure "Open Watcom was not found"
exit 1
fi
log_failure "Open Watcom was not found, using alternative BIOS sources"
cnf_append "VBOX_WITH_OPEN_WATCOM" ""
return 0;
fi
Line 74 of the same file defined OSE as 1, not 0. So, apparently, in absence of Open Watcom, "alternative BIOS sources" would be used. I let you further investigate.
That's interesting. I built it on Trisquel and I obviously don't have open watcom installed. You said,
>"Despite what is written in the last line, there is no tools/common directory in that source code. As a consequence, it does not look like Open Watcom is bundled with VirtualBox"
... so I guess I built it with an alternative BIOS?
Apparently, VirtualBox developers "provide alternative sources (assembly) of the components that normally get built with OpenWatcom, so VirtualBox can be built without it": https://forum.virtualbox.org/ticket/12011#comment:3
I guess those are the "alternative BIOS sources" in the message I quoted in my previous post. The question is: is that assembly really source code or some kind of blob (output by Open Watcom)?
In the 'src' directory there is a Devices/BiosCommonCode folder with some files that seem relevant. There are some .asm files which I assume are assembly, but which are human readable, so don't look like the kinds of binary blobs I'm familiar with.
Also there's a c++ file called MakeAlternativeSource.cpp, which is also human readable, but I can't make much sense of c++, so not sure exactly what is happening with it. I see that there is a section that says it "Parses the linker map file for the BIOS" and that "This is generated by the watcom linker", but it's also human readable.
In the src/VBox/Devices/PC/BIOS directory there's files called
VBoxBiosAlternative8086.asm
and
VBoxBiosAlternative386.asm
and
VBoxBiosAlternative286.asm
... which are also human readable. Not sure what the significance of them is. None of them mention the word 'watcom'.
If you feel that assembly is readable, then it looks like VirtualBox can be re-included in distributions satisfying the GNU FSDG: it is good news! To spread it or maybe have people check it, you could take part in the Free Software Directory weekly meeting (on Friday) or at least explain your findings on its mailing list? The relevant information is directly on https://directory.fsf.org
There's really no substitute for needing the non-free compiler in order to build from source. Their solution to avoid people "needing" that non-free compiler is pre-compiling the source code and then disassembling the BIOS image with that program. But we know that those came from a higher level source code. The compiler's output should not be considered the source code.
Given "We do not know yet if this page exclusively refers to free software" on https://directory.fsf.org/wiki/VirtualBox I was under the impression that the freedom status of VirtualBox was still discussed. Isn't it?
I wish I could understand the reasoning from our FSF/GNU side of things:
>"The Free Software Foundation (FSF) has stated that the license is not "free" as it requires the source to be published when you "deploy" the software for private use only.[1] In contrast, FSF's General Public License (GPL) does not require that a modified source code has to be made public when the software modification was only used privately without a public release of the software. This makes the Watcom license also GPL incompatible and a stronger copyleft license than the GPL and even the AGPL."
https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License
The Open Watcom license says that source code must be released, even when the software is for private use only, and we on the FSF/GNU side say, "No, demanding even MORE source code availability is non-free"?
How is it that a more stringent demand for releasing more source code is non-free? I can see where it could possibly be considered incompatible with the GPL or another copyleft license due to placing too high a burden on GPL'd projects, but non-free? It literally is MORE free in terms of more code availability.
The short answer: Because it doesn't allow private internal use that you share with no one else.
Well, that's not completely true; it does allow for some private internal use, but what private internal use it does allow for isn't broad enough to cover all cases that should be considered private internal use.
So here's the long answer: Let's start with the Free Software Definition: "You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way." The idea being able to use your own copies on your own computers privately without ever telling anyone anything about it.
I believe that Debian calls this the "Desert Island Test".
The problematic section is 1.4:
1.4 "Deploy" means to use, sublicense or distribute Covered Code other than for Your internal research and development (R&D) and/or Personal
Use, and includes without limitation, any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use, as well as direct or indirect sublicensing or distribution of Covered Code by You to any third party in any form or manner.
To shrink it down: To "deploy" means any and all internal use that's not R&D use and/or Personal Use.
Maybe it's in production use in a company for example, used to compile software releases. But it's only run on their computers and never shared with anyone outside the org. This should be private use. Anyway, that is considered "Deploying" the software because it's neither R&D nor "Personal Use." As a result 2.2 applies:
2.2 You may use, reproduce, display, perform, modify and Deploy Covered Code, provided that in each instance:
(c) You must make Source Code of all Your Deployed Modifications publicly available...
And, since the source code must be made public simply from that usage that should be considered strictly internal, there ends the "you should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist." And thus, the license is non-free.
I believe it would also fail Debian's "Desert Island Test" in that scenario because one could not use it disconnected on an island without needing to reconnect to society to offer the source code back to the public.
>"except for R&D use and/or Personal Use"
But any modification of the code that a person or company would want to "use ... privately in [their] own work or play, without even mentioning that they exist" would easily fall under the R&D and/or Personal Use exceptions in the license. Any use that does not fall under those exceptions is clearly going to be commercial distribution, where the source code should be made available. I'm not seeing the problem.
A free software license must allow all private, internal uses unconditionally, without restricting them to specific categories like "R&D" or "Personal Use." After all, it is supposed to be "for any purpose".
Who decides what the definition of free software licence is?
The Free Software Foundation maintains https://www.gnu.org/philosophy/free-sw.html
It is very stable: the last clarification is more than three years old, according to the changelog at the end, where it is also apparent that rms (who defined "free software" in the first place) has made all the significant changes for the past 15+ years.
Actually, if you allow unconditional internal use without sharing source, then you will create horrendous situations where entities like the US Federal Government (~18 million employees and contractors among thousands of departments, agencies, offices, and bureaus) or Walmart (~2.3 million employees and millions of contractors among thousands of stores and geographic locations) could create and distribute hundreds of variations of GPL'd software internally and not share one iota of source modification, even though the entire world is suffering under the weight of their "internal" software's bugs.
In fact, we already have the situation where the entire nation of North Korea is constantly modifying thousands of pieces of GPL'd software for "internal use only" without sharing sources.
It would seem that the "Unconditional internal use" exception, when scaled up large enough, simply becomes "widespread commercial distribution without licensing responsibility".
@MB - >"https://trisquel.info/en/wiki/installing-virtualbox ! Would you edit that page?"
If there's lingering problems as to Virtualbox's free software status, even when self-compiled, then I don't see a reason for Trisquel to have a Virtualbox wiki page. And it sounds unnecessary, as apparently everyone is already using Virt-Manager or using CLI commands for qemu or kvm. So, in response to your question, I guess I won't be editing that page.
I am a translator!
What are the advantages of virtualbox over virt-manager?
I don't know, I'm still learning about virtualbox. virt-manager seems pretty good to me though. And also using qemu from the command line is pretty good too.
Other than ease of use, I recall none. This being said, virtualbox is also such a security nightmare debian canned it for a while there.
And upon looking further, I see it still isn't there:
https://packages.debian.org/search?keywords=virtualbox&searchon=names&suite=stable§ion=all
virt-manager is definitely a better choice out of the two.
Better idea:
qemu-img create -f qcow2 your.img 20G (you can use as much as you want)
qemu-system-x86_64 -m 3072 -cdrom your.iso -boot d your.img --enable-kvm (for booting iso to install on your .img)
qemu-system-x86_64 --enable-kvm your.img cpu kvm64,+nx -m 4096 -device (for loading your new installation whenever)
Are you still able to use qemu on the latest Hyperbola version?