VirtualBox

sossego said:
Like KVM, kqemu, and Xen, it is still a front end to qemu. I wish it did have full qemu functionality built in, that would be nice.
Click to expand...

They aren't "front-ends" to QEmu. Not even close. They use bits of QEmu to provide certain hardware bits (mainly related to network and block I/O), to simplify hardware-assisted virtualisation. But that's it, and only on x86/amd64.

KVM has been (or will be shortly) integrated into QEmu, though, as "a qemu accelerator" module similar to kqemu.

Front-ends to QEmu would be things like qemu-launcher, which just provide a nice GUI or management interface to the complete QEmu package, providing access to all the weird and wonderful things that QEmu can emulated.
 
Poor choice of words on my part but none of them work without qemu.
I believe the common phrase in all of them is somewhat of "a modified form of qemu." Each one also falls back on qemu if the system/cpu doesn't have the proper flags.
KVM has already been active in Linux.
 
phoenix said:
Front-ends to QEmu would be things like qemu-launcher, which just provide a nice GUI or management interface to the complete QEmu package, providing access to all the weird and wonderful things that QEmu can emulated.
Click to expand...

I personally use aqemu (emulators/aqemu). Except for e1000 missing in the UI due to how it detects whether qemu supports it or not, it works quite well.
 
x86 or amd64?

Which one?
And, since virtualbox is dependent upon ia32libs, has a pure 64bit solution been implemented yet?
 
OK -- first question -- which download? There is none labeled "FreeBSD" in any of the usual places (including SVN).
 
DrJ said:
OK -- first question -- which download? There is none labeled "FreeBSD" in any of the usual places (including SVN).
Click to expand...

There won't be anyone labeled FreeBSD, as it isn't supported officially(yet). Grab the source code from the OSE version from the bottom of the page, either by the nightly snapshot or directly from the SVN.
 
It doesn't compile for me on 7-STABLE (essentially 7.2-R) i386.

I installed the various required programs listed on the VBox site, changed a couple of the INC locations, and did the Bash symlink. ./configure works fine, but the compile fails for either no flags or the ones in the amd64 guide. The latter fails with the inability to create a bunch of directories.

I can give more information, but I'm done for the night.
 
It's compiling now. There is an ominous warning in the open tasks (since I'm on 7-STABLE):

Open tasks:

1. Fix kernel crashes on 7.2-RELEASE.
2. Code cleanup.
3. Fix errors on AMD64.
4. Fix user/permission problems.
 
Well, it compiled fine on i386 7-STABLE. I got partway through an installation of W2K server before the mouse capture override failed. Subsequently the loading vbox kernel module has locked the computer solid, even through it worked the first time. I've no idea why.

The screens did all come up, and I did get partway through the installation, so there definitely is hope, though things seem a bit raw right now.

The permissions are funky too. If you try it, it sets the VM up in /root (since you have to run it as su right now). I don't have much space allocated to /, so that filled up. There is an option to change the default location, which I did subsequently. Be aware of that.
 
DrJ said:
It's compiling now. There is an ominous warning in the open tasks (since I'm on 7-STABLE):

Open tasks:

1. Fix kernel crashes on 7.2-RELEASE.
2. Code cleanup.
3. Fix errors on AMD64.
4. Fix user/permission problems.
Click to expand...

I'd add :

  1. Fix kernel crashes on 8.0-CURRENT
  2. Vbox doesn't detect the module the second time
  3. it is launched in 8.0-CURRENT (the first time seems to detect it)
  4. No graphical display in 8.0-current. The screen remains grey.

I'm starting to see in the code why 2 is happening (didn't had much time). Don't know where to start for item number 3, any ideas ?
 
The Makefile also does not add the vboxusers group (or whatever it is called). The suggestion in the description to add regular users to the vbox group therefore fails, and vbox must be run as root.

This is a detail, but usually su commands are written with a "$" prompt to distinguish it from those that a regular user can issue (as "%"). So the -description file should be revised.

I should add that subsequent attempts to load the kernel module were after reboots, so the system should have been clean. Practically that was the only way after the hard lockup.
 
DrJ said:
This is a detail, but usually su commands are written with a "$" prompt to distinguish it from those that a regular user can issue (as "%").
Click to expand...

$ and % are both prompts of normal user, bash/sh and csh/zsh respectively, # is used for root prompt.
 
Hey folks, freebsd can run many linux software with the linux ABI. I mean if the problem is about a binary not available for FreeBSD you can give it a try. Trying to emulate a whole computer, then i guess we are in a problem for the moment. VB seems to me a good way. It is not very fast but will do the trick.
 
VirtualBox is dependent upon ia32 libs and vm86 functions.
AMD64 for FreeBSD would have to run both.
Be aware that any pure 64bit Linux system is unable to run VirtualBox. What does this tell you about it running on FreeBSD?

The VM is looking for Linux kernel hooks/mods/etc.

The linux binary does not work because you must be able to use the actual kernel and make the vm calls natively. Sorry, but only one kernel at a time.
 
The port status is non-existent. You are welcome to start it.
What Sun/VBox wants are FreeBSD hackers to write the program to access the kernel.
The build has not yet been optimized.
If you ask Sun for help with FreeBSD, you won't get it.
So, you're kind of on your own.

You can link a folder to root from the initial user account or you can build and run from within the folder itself.
 
You must log in or register to reply here.
Back
Top