Haiku as ideal virtual machine guest. State of QEMU/KVM/VirGL support

As we all know Haiku (together with FreeBSD and OpenBSD) suffer from lack of drivers problem. It’s even worse than on Linux. It’s OK for FreeBSD as it now targets devices like routers and firewalls. But this problem renders desktop oriented Haiku useless or puts in a state for waiting a manufacturer that would use it like Apple uses macOS or Google uses Chrome OS: sells the OS together with limited hardware (but I find this second option unbelievable).

Looks like Haiku is a good OS for Google SoC projects so that junior programmers can learn. But that niche for Haiku looks rather disappointing…

So if we are to find the niche for Haiku we don’t have many options. Actually there is only one: ideal desktop virtual machine guest for Linux host.

The virtual machine that run on Linux host (there’s no need for Haiku if you have Windows or macOS host). We all know what a permanent disaster Linux desktops environments are :slight_smile:

In order to do so it needs decent support for virtual machines. Primarily QEMU (maybe VirtualBox and VMware, but the latter is not FOSS). This way it can use VM abstractions over Linux drivers instead of implementing all that drivers in Haiku. That’s much easier and is comparable to what Apple and Google do (as I notes above) so is (more?) possible than hoping that native Haiku drivers would be written some day.

What’s the state of QEMU/KVM/VirGL support in Haiku? Any plans to add VirGL support?

P.S. And don’t even mention old computers niche - it’s like commiting suicide really.

If taken together this and that posts mean that there are only two ways of solving driver problem in Haiku: putting Linux inside Haiku and Putting Haiku inside Linux.

I feel like the second way is better and it’s even better to utilize virtual machine for this. Virtual machine as a main work desktop is a very nice experience - it gives freedom and even security unavailable for normal installation. And we all know that Haiku is desktop only OS (no mobile support needed - Chromebook form-factor aside) so it’s going to run on systems that good enough to use virtual machine daily.

We write our own drivers. We also use FreeBSD ones in some places. And with this, Haiku runs natively and quite well on my machines. No need to involve any Linux code or virtualization (which always comes with an overhead), thanks.

5 Likes

So if we are to find the niche for Haiku we don’t have many options. Actually there is only one: ideal desktop virtual machine for Linux host.

Then why not running Linux:
a) directly
b) on an ARM SBC
c) remotely as VPS

EDIT: I misunderstood you, sorry.

That’s much easier and is comparable to what Apple and Google do (as I notes above) so is (more?) possible than hoping that native Haiku drivers would be written some day.

Providing a way so the developers don1t have to port/develop drivers seems contraproductive to me.

What’s the state of QEMU/KVM/VirGL support in Haiku?

There is literally articles about this on the Haiku main site. Or you can even test them in some minutes, so why asking questions like this?

Virtualbox/VmWare works ok, have seen some guys with QEMU and KVM sucess too. Your mileage may vary.

If taken together this and that posts mean that there are only two ways of solving driver problem in Haiku: putting Linux inside Haiku and Putting Haiku inside Linux.

Nope, it just means you see this options. Not less, not more.

But I see all options really. And there are only 3 of them: 1) Haiku in Linux, 2) Linux in Haiku, 3) Tailored hardware. If you do agree on that then you simply avoid reality.

Fix: If you don’t agree on that then you simply avoid reality.

I (personally) do avoid reality, if i have to use your words.
I -however- better like it with my words: I do try to alter reality so how i’d like to see it.
And that’s a big difference, but not the scope of the forum.

Maybe you should create a list about what so good is in Haiku what worth the deal integrating it into Linux, or integrating Linux into Haiku or running one on top of the another in VM.

You told yet only the Desktop environment. Anything else?
Because if it is the only one, then it would be much easier to create a desktop environment for Linux, it shouldn’t be too hard, and plenty pleople would use it, as “the Desktop environments are permanent disaster”.

Providing a way so the developers don1t have to port/develop drivers seems contraproductive to me

But in reality not providing this way is contraproductive. This way almost nobody ports drivers (simply not enough man even though there are some) and almost nobody uses Haiku. This circle can be broken via somebody payed and hired driver developers (not gonna happen) or via gradually icreasing user base so that more and more more developers wanna write/port drivers.

Flawless support for Haiku in virtual machine will increase the userbase. By flawless I mean with minimal loss in CPU and GPU, no VM related bugs, support for other VM drivers, convenient out of the box experience with Haiku in VM, easy files and clipboard exchange with the host.

You told yet only the Desktop environment. Anything else?

That’s a pretty big deal actually. If we look at it from developer point of view - uniform desktop environment like in Windows/Android without Linux fragmentation.

If we add stable ABI/API - even better!

There are virtio drivers in Haiku, and there are virtualbox/vmware guest addons in depot. More integration is possible, but needs programming.

Thanks for providing details about VM support!

No need to involve virtualization (which always comes with an overhead), thanks.

But it’s a great way to run your main desktop if you if have good enough hardware. At the moment it only loose too much on GPU. Tools like GPU pass through or VirGL emerge to solve this issue.

I have a feeling that virtal machine sandboxing is the near future of the desktop. So I suggest Haiki to be prepared.

I’ve just remembered that the main favorite on the niche of the best main desktop in virtual machine on Linux host is Android x86. It gradually adds virtual machines support, has uniform GUI, there have been even attempts to add separate windows to it, it supports lots of Android apps.

So I hardly can imagine how Haiku can beat Android x86. Is there any features that superior on Haiku than on Android x86? And how can they help to gain user base?

(1) Correct me if I’m wrong, but it seems you are proposing some sort of desktop (Linux) or subsystem that runs a virtualized Haiku on top of QEMU/KVM to interface with Linux drivers through some virtio interface? We already have support for some virtio devices and disk drivers in Haiku to make this possible, but you are still required to write some other virtio Haiku drivers anyway to interface with the VM host, even to support several hardware accelerated features missing in Haiku. Without this, your VM experience in some features will be either limited or just slower than on bare metal.

By even doing this, users will still complain about missing apps like Chromium, Firefox and other games etc, which isn’t enough to justify the overhead of running it in a VM. I just don’t see how this will ‘increase the userbase’ towards general users, when they can simply already run or try Haiku in a VM on any OS that supports hardware virtualization.

(2) This option has already been attempted and it is possible but only as a separate project and it is called Cosmoe. But since we have been purging allot of GPL based code (with the exception of the glibc library), I’m pretty sure that, you have to convince the other developers in using code from Linux which won’t be allowed, due to licensing issues anyway.

(3) This depends on which sort of tailored hardware. The x86 route looks too expensive for the Haiku Project IMHO and would even be a dead end for Haiku Inc’s finances. Targeting cheaper ARM boxes, such as the Raspberry Pi sounds much more feasible to do.

For the driver problem, I’d rather use drivers from Fuchsia or FreeBSD or if possible, switch to Zircon than go through the QEMU/KVM route. Also you have to convince the other developers on this idea for any sort of change to happen; if not your option is the Cosmoe route. But after considering the options you proposed as they stand, I’m not convinced.

1 Like

(1)

Something like this but not exactly. I’m not aware of the details yet. I guess CPU loss may be acceptable now. Some drivers may be already written. What probably missing on Haiku (in order to be an ideal VM guest OS) is GPU accelation with minimum loss. The idea is to focus on this direction - flawless work in a Virtual Machine on Linux host (why use Haiku when you have macOS or Windows?) but on Windows too - for promotional reasons mostly. And try to occupy this niche faster than Android x86 does it. This would require checking all VM user experience. “Is there any VM functions that may be implemented in order to make it better?” and so on.

(2)

This option doesn’t look beautiful…

(3)

Here Haiku is to compete with Android, AOSP and Lineage OS.


Actually after re-thinking this I still think that only VM host and tailored hardware are possible niches for Haiku. The problem is that both these niches are already occupied or will be occupied by Android/Android x86.

So in order to compete it should do something better than Android… What could it be? Easier centralized patches and vulnerabilities fixes because of the hybrid kernel (just a guess - I’m not really familiar)? Support for desktop Qt? Real desktop experience (instead of mobile experience on desktop)?

  1. Could you explain closer what for benefits this should bring to me?.. i use haiku because it’easier to manage, easier to set up and has a more consitance way for doing things (drag’n drop, storing data in fileattributes and so on) if i would have to use a Haiku in linux you lose the consistency (linux doing things different from haiku). Its a mix and its not easy to set it up, also it is much slower than on real bare metal … so i can only way more disadvantages than winning some drivers.

  2. Intresting Point because you can get the whole ecosystem of linux on haiku. But for me this would mean that you first need to have all drivers ready… since linux cant use hardware directly since it’s virtual… the other solution would be your promotet linux sub system wich is more work then just implement all drivers for haiku nativly (wich gives you more speed and better system integration). So again way more work than the price you gain and again you are losing consistency.

  3. Tailored Hardware… could be a solution… but ask yourself or other people if you or they would buy a special computer only for and only with haiku… if they could have for the sam price a computer preinstalled with windows or linux… If you answer this honsetly you have to say no

… so from my point of view the main problem its not the missing hardware support… i guess :smiley:

Points 2 and 3 are very unlikely to happen so I suggest not bother discussing them.

As about point 1: the Linux host ideally should be a lightweight easy to use GUI virtual machine manager (setting up, any device passthrough, some interface for live switching between OSes, disk shared among OSes, etc.). It is used only for managing VMs and nothing more. All the work is done inside Haiku guest (or other guest OSes). So there is no consistency problems if you use Haiku only.

As about VM being slower - that’s fine if your computer is fast enough. At the same time you get a safer from security points of view experience than bare metal and easier system maintenance.

Actually if to have user-friendly GUI VMs hypervisor + few guest OSes that can utilize GPU acceleration and CPU with minimal possible losses (there still should be some perfomance loss if we are to have isolation for security reasons) - that would be a really great user experience!

And if we are to imagine what OS should be ideal canditate for such a guest OS: it’s definitely Android x86, and… Haiku. For some reason I feel like it fits… Gnome 3 Linux (and Windows?) should be in the list too but should be used for some rare stuff only.

The main thing that should be checked is GPU accelearion with minimal losses. For example Android x86 now has QEMU/VirGL support and continues to make it better.

This VMs with superviser Linux host desktop use-case scenario is specualtive and might not actually happen but I feel like it’s the future of non-Windows and non-macOS desktop (actually it’s a norm on servers now). And if it’s actually to happen it’s not too late for Haiku to try to fight for it’s place in such future.

Not gonna happen? Who knows?

1 Like

Sigh. Haiku is better now than it ever was, and I think has more hope now than ever before. But on the Raspberry Pi and certain machines I have, it still can’t start.

So something I’ve been exploring for the time being for a while I realized is kvm. And so, after Poem failed, I broke off a subproject called Couplet which is its own project in progress. My goal is to have a front end which I’ve named “Vintage” with a pre-supplied VM image inside the OS, which will allow one to start a Haiku session fullscreen on top of Linux. The problem is having time to sit and work on it, and unless I can get a working, bootable demo of it out by the end of this year, I’m about ready to declare it vaporware and a lost cause.

So, because Couplet isn’t anywhere near done yet, it’s true that the best thing for now is just to play with Cosmoe. And when I finally get everything with Couplet finished, including Vintage, I’ll be sure to let people know. But that’s kind of an answer to Haiku on Linux for you from me.

3 Likes

apgreimann, sounds great!

And I isist that using an OS inside VM is not a crappy workaround but another and better way of using an OS (better than bare bone). Certainly it’s only in case of solving GPU accelation problem (and not forgetting about CPU loss minimizing).