ok, there are (maybe) Haiku on Virtualbox or VMWare or Qemu or…
BUT
I think that should be very interesting run Virtual Machines ON Haiku…
VirtualBox is open source, it is possible port on Haiku?
I like run Windows, GNU\Linux, xBSD, xSolaris in VMs with their applications… think LAMP stack on Haiku!
what do you think?
There is already a qemu port for haiku: http://haikuware.com/directory/view-details/emulators/computer-systems/qemu
Yes but qemu is a command line only application, so not right for Haiku; it’s a lot complex to use!
It will be better to have VirtualBox on Haiku… I think there was a GSOC to port VB but it seems i=m mistaken…
There is a GUI component but it might need some updates:
I used Qemu sometime ago trying to get it to work, it is very slow and is very resource heavy, its not a virtualization it is true emulation. This means it comes with a very significant overhead. Its runs like crap and the GUI doesn;t work right, it is also very difficult to configure properly.
Best thing to do is hope virtualbox port happens.
Qemu offers virtualisation when run in conjunction with Xen (a standalone hypervisor) or with KVM (OS based virtual machine) both of which are most commonly used with Linux of course.
Haiku doesn’t provide KVM and doesn’t support being used as the domain 0 operating system of Xen. In fact we can go further: Haiku’s kernel doesn’t provide any virtualisation services at all.
Haiku doesn’t run in Long Mode on modern CPUs, and most virtualisation software does not support running a Long Mode guest on a i386 mode host, so this would be very limiting anyway (no 64-bit guests)
The GSOC project is to improve usability aspects of Haiku running as a VirtualBox guest. This is a more practical scenario than running Haiku as a host OS.
Yet VirtualBox supports 64-bit guest on 32-bit host OS but only with hardware virtualization. The poster asked about VirtualBox so I point this out.
http://www.virtualbox.org/manual/ch03.html#intro-64bitguests
Qemu is slow to use and not worth using.
VMWare is closed source so you will not see that on Haiku.
Haiku could get VirtualBox (Open Source edition) but only with software virtualization for now. VirtualBox (soft mode) should still be faster than Qemu but slower than running VB with hardware virtualization.
Some quick testing of software vs hardware virtualization I did in VB with 7zip showed:
a) 7zip benchmark (7za b): encoding speed is 2X faster with hardware mode
b) creating 7zip archive of system/lib & sub-folders gave similar result to a) above:
VB in software mode
total time: 2m9s
VB in hardware mode
total time: 1m11s
*VB running on Windows 7 64-bit host
Hardware virtualization makes a big difference by giving 2X the CPU power to the guest OS!!! You can also notice this difference in booting which is much faster too.
QEMU is FAST… boot up any Linux distro install QEMU and make sure it has KVM support and watch your virtualized OSes run at near native speed. For instance on my laptop without KVM haiku does a mere 20 or so FPS on GLTeapot… with KVM enabled it shoots up to around 270-300 FPS which is only slightly below native speed. And as far as desktop applications I can’t tell the difference between QEMU with KVM and native.
VirtualBox’s main advantage is in the GUI and convenience of use not speed QEMU is even gaining USB2 support so it is still a highly valid target.
@cb88
Ok, KVM is for hardware virtualization on Linux and maybe on BSD too with their port. So, when using KVM with Qemu then it should run fast like VirtualBox but currently Haiku does not support KVM and likely will not for R1.
Qemu on Windows 7 also does not support KVM and stuck with 0.11.1. Windows 7 is the OS I mostly run now.
Also, Qemu emulates the CPU type. That slows things down. Not sure if this happens with newer versions since I have not tried Qemu past 0.11.1. That is why Qemu is called an emulator. VirtualBox passes my actual CPU type to the guest OS - no CPU emulation.
Qemu is only fast on Linux using KVM otherwise it is slow for the rest of us because we are stuck with 0.11.1 version that uses kqemu acceleration!
KVM seems to be only on Linux (and maybe BSD). So, that is the only OS that can run Qemu fast.
http://www.linux-kvm.org/page/Main_Page
VirtualBox is available on Windows, OS X, Linux and Solaris and should support hardware V on all of these OSes. Since I will run Windows 7, Haiku and maybe Linux, then it makes sense to stick with VB.
Also, when doing the 7zip test Qemu+kqemu took over 13 minutes. I stopped it because I could not take waiting for it to finish. Ran really, really slow!
Consider that any hardware virtualization on Haiku (like KVM) would not appear until R2. Since Qemu+kqemu is super slow and Virtualbox with software virtualization runs much faster than Qemu with software V then which is better for Haiku? =)
With hardware accel they maybe equal but only if Qemu stopped emulating the CPU. I cannot say without testing it out myself. But with software accel, VB beats Qemu hands down!!! No contest!!! Haiku would get software V for R1 & hardware V for R2 with any virtual machine software.
PS Michael Lotz, Haiku dev, worked on Qemu port and was able to get it to 0.11.1 but nothing newer than that because of KVM. With VirtualBox, should be able to port the latest version and just use software V mode until Haiku supports hardware V.
On Windows 7 you can run Microsoft’s Windows Virtual PC.
[quote]
Also, Qemu emulates the CPU type. That slows things down. Not sure if this happens with newer versions since I have not tried Qemu past 0.11.1. That is why Qemu is called an emulator. VirtualBox passes my actual CPU type to the guest OS - no CPU emulation.[/quote]
Even hardware virtualisers emulate a different CPU from the host CPU. For example they remove the hardware virtualisation feature from the CPU flags on the emulated CPU to avoid a Russian Doll scenario. Also emulating a specific CPU is important for live migration (or even offline migration if you don’t like nasty surprises) because the software inside the guest isn’t expecting the CPU to change. On its own this makes no performance difference, programs don’t spend a significant portion of their time executing instructions like CPUID.
Actually the kqemu acceleration would give you somewhat similar performance to the VirtualBox software virtualisation mode. kqemu and VirtualBox work roughly the same way - a kernel driver hijacks the host system, enabling ring 3 software on the guest to run in ring 3 on the host.
It’s possible you haven’t actually installed kqemu, that you’ve installed it but it doesn’t work (or no longer works on newer Haiku builds), or that you simply didn’t enable kqemu in your qemu session.
You mention version QEMU 0.11.1 several times, but I don’t see much sign that it’s actually available for Haiku. The Bebits link, for example, is to a BeOS version which claims to be 0.9.1 from years previous.
I use VirtualBox on Windows 7. I also once in awhile run Qemu port on Windows 7 for testing.
It could be that kqemu driver is not working properly on Windows even though Qemu Manager says installed and enabled. Since Qemu is really for Linux (not Windows) then testing it on Linux is best. At least then I would not be using a Qemu port and could tell if kqemu was really on or off. May hook up my Linux box to check this out better and get accurate results.
Correct, the binary version of Qemu for Haiku is currently 0.9 but up to version 0.11.1 can be ported to Haiku.
0.12.0 removed kqemu going for KVM instead. So the last version of Qemu ports other OSes will use is 0.11.1 to benefit from kqemu until they get KVM support.
[quote=NoHaikuForMe]Qemu offers virtualisation when run in conjunction with Xen (a standalone hypervisor) or with KVM (OS based virtual machine) both of which are most commonly used with Linux of course.
Haiku doesn’t run in Long Mode on modern CPUs, and most virtualisation software does not support running a Long Mode guest on a i386 mode host, so this would be very limiting anyway (no 64-bit guests)
The GSOC project is to improve usability aspects of Haiku running as a VirtualBox guest. This is a more practical scenario than running Haiku as a host OS.[/quote]
I really wish I cared, but I don’t. to me its just not a big deal. Screw emulating, that for servers and linux users who can’t run windows apps.
Yes, you might not but others may. They will want to run another OS in a virtual machine. I only do this myself for testing out OSes and believe it much better to install the OS to the drive and dual, triple or quad boot the computer.
Haiku cannot run Windows (or X based Linux) applications either last time I checked. =)
Which some people may find important using and may prefer running them through a virutal machine instead of rebooting their computer. ie, to some maybe very important and to others not so much. For me, it is of little importance. Better to get the right apps onto Haiku instead to avoid using VMs.
Ok I did some testing on a Linux system and below are the results.
Qemu without kqemu
bench: 7za b
Compress Decompress
Speed (KB/s) 33 623
MIPS 33 56
Qemu+kqemu (user mode accel)
7zip /boot/system/lib + subfolders
real 10m38s
user 4m55s
sys 4m50s
bench: 7za b
Compress Decompress
Speed (KB/s) 218 7138
MIPS 217 649
VirtualBox
7zip /boot/system/lib + subfolders
real 5m49s
user 0m29s
sys 3m31s
bench: 7za b
Compress Decompress
Speed (KB/s) 250 6477
MIPS 249 588
The interesting part is the 7zip bench shows Qemu w/kqemu difference of 10-20% compared to VB but when 7zipping (compressing) system/lib folder VB does it in half the time. User CPU time really killed Qemu!!!
Without kqemu, Qemu is 6.5X slower compressing and 11.5X slower decompressing 7zips. Runs real terrible and should never use this mode.
Extra info:
Atom330 system w/2GB RAM, Debian Lenny OS, Alpha2 ISO, 0.9.1 Qemu, 3.2.12 VB, 500MB given to VM
*Issue with A3 RC which I have to report.
*Could not find 0.11.1 Qemu deb binary so stuck with 0.9.1 - default one in Lenny.
*Qemu defaults to kqemu user mode accel. I tried enabling full kqemu virtualization but crashes. Full kqemu V is anyways only meant to work with couple of OSes from their docs.
Yes, you might not but others may. They will want to run another OS in a virtual machine. I only do this myself for testing out OSes and believe it much better to install the OS to the drive and dual, triple or quad boot the computer.
Haiku cannot run Windows (or X based Linux) applications either last time I checked. =)
Which some people may find important using and may prefer running them through a virutal machine instead of rebooting their computer. ie, to some maybe very important and to others not so much. For me, it is of little importance. Better to get the right apps onto Haiku instead to avoid using VMs.[/quote]
better to just put it on a 8-10gb thumb drive, they are cheap these days and the performance benefits of running on real hardware exceed the benefits of virtualization. Now obviously for dynamic enviroments like large data centers and the need to virtualize OS’s to handle the various demands they have, sure it makes sense for them to be heavy into virtualization, even for OS development is makes sense. In fact any scenario where regular reboots are need virtualization makes alot of sense to development purposes.
But for the average PC, user ?? Its a edge case useage, I would welcome virtualbox with openarms, but its not a nessecity right now in anyway I cn see.
Well, not exactly. The difference between the benchmark and compressing real files is that the benchmark doesn’t require any system calls or I/O, almost every cycle is spent in userspace. But when 7zip needs to read a file, it makes system calls to the OS, going into ring 0 on the guest and running filesystem code, disk I/O etc.
VirtualBox is able to handle some of this by running the code directly on your CPU. The bulk of the guest OS filesystem code (which thinks it is running in ring 0) can be faked out in ring 1 of the host OS. The system call itself, which is a trap into ring 0, and the I/O code, have to be painstakingly emulated.
Qemu’s kqemu in “user mode” doesn’t do the ring 1 trick, from the moment the system call happens until control is returned to the 7zip userspace code, it’s emulating everything which is noticeably slower for programs which do a lot of system calls. But this strategy is much less prone to subtle mistakes.
You should also beware that the guest OS clocks are virtual too. So “wallclock” or “real” time inside the VM is not necessarily real to you. Obviously if something feels very slow, it probably is, but you may not want to entirely trust benchmark results inside a VM.
Tones,
Any chance you could put together a simple guide - A Beginners guide to using Qemu on Haiku? It is some thing that keeps coming up. I haven’t had the patience to learn what to install from were, which switches are relevant, etc. Could be very useful documentation.
I talk about run other OSs on Haiku: it’s very rare hardwares that run 4 or 5 different kernels without problems… Haiku is fast than light and could be the kickass VMs dispatcher… 
So hardware compatible with Haiku and also can play other OSs!
I like win-win situations!
Is it possible? wich software? how install it?
thx
[quote=andrea.paiola]I talk about run other OSs on Haiku: it’s very rare hardwares that run 4 or 5 different kernels without problems… Haiku is fast than light and could be the kickass VMs dispatcher…
So hardware compatible with Haiku and also can play other OSs!
I like win-win situations!
Is it possible? wich software? how install it?
thx[/quote]
WTF is the point of running 4-5 other Operating systems in VM’s ? Unless your a data center server and you have some need to do so, and they often do, How in the world could you ever need to do this on a desktop OS ? You do realize the overhead your talking about here. Just becuase haiku is light and fast doesn’t mean it would make a good vm host.