Haiku works very poorly as a guest under the Linux Kernel Virtual Machine QEMU KVM
|Reported by:||Don Quixote||Owned by:||axeld|
|Keywords:||kvm, kernel virtual machine, qemu, linux, ubuntu, virtualization, subversion, signal, SIGKILL, bfs, filesystem, r42888||Cc:|
Description (last modified by )
This is most likely several different bugs in the Linux kernel, KVM or QEMU, but there is some possibility that the problems I am experiencing are in Haiku. In any case, it would be helpful for someone who knows more about Haiku's internals than I do to work with the KVM developers to make this work better.
I was planning to submit each of the following problems as a separate Trac ticket, and will do so upon request. But I figured it would be best to bring this to your attention now rather than wait until I had the gumption to type up so many bug reports.
I've spent five or six days trying to get to the point where I can build Haiku when booted off a Micro Center store brand 16 GB USB Flash drive on my Early 2006 MacBook Pro, model identifier MacBookPro1,1.
Haiku mostly works on my unit, but there are some problems that I hoped to fix and submit patches for, but because of all the problems with virtualization I have experienced, I have yet to get as far as booting my laptop with the latest Subversion.
If I do "svn co" for either the buildtools or the haiku source, the checkout will go extremely slowly. If it were to succeed at all, I expect either codebase would take more than a day to completely check out.
However in several days of trying, I was never able to complete the checkout. Always it would fail in some really bad way that required me to reboot Haiku.
To start with, the files are retrieved very slowly at best. Every few dozen files the checkout pauses for a time ranging from a few seconds to a few minutes. Eventually it halts completely.
At that point the svn process cannot be killed by sending it signals, not even signal 9 (SIGKILL) which cannot be caught or ignored.
I had the same thing happen with rm -rf. The rm process got stuck and could not be killed with signals.
More often, svn complains that it could not read the host's response header, then the svn process terminates. I've restarted it a whole bunch of times but have yet to get the whole buildtools tree to check out while running Haiku under KVM. I never had this kind of problem under VirtualBox or Ubuntu. Most exasperating is that after one of my reboots, a whole bunch of the buildtools' .svn directories contained corrupt data. The BFS filesystem itself was not corrupt, but "svn cleanup haiku/buildtools" complained that many of the sources were not under version control. Rather than try to fix this I would "rm -rf" the entire directory where that source file resided. It was while doing that that I found I could not kill rm with SIGKILL.
I was previously using VirtualBox, which worked far better. However full builds of both the buildtools and Haiku took 4 1/2 hours. While VirtualBox guests can be configured to have more than one CPU, only one host CPU is used. The multicore guest CPU is only emulated; I expect it would actually run slower than configuring the guest with just one core.
I hoped to speed up builds under virtualization by using the Linux Kernel Virtual Machine on Ubuntu 11.04. KVM *can* use more than one host core. I have two cores in my Intel Core Duo (32-bit - NOT Core 2 Duo). I have always allocated two cores to the Haiku guest, then avoided using my laptop when Haiku was doing anything CPU-intensive.
Maybe KVM would work better with just one core allocated to the guest. I will try that later and will report my results.
I had the hope that KVM would work better in Ubuntu 11.10 but it does not.
The video and mouse movement are painfully slow. While virt-manager presents the options of using VNC, Spice and SDL for graphics, only VNC actually works. I don't think it is yet possible to use SDL at all. Spice can be gotten to work in Ubuntu 11.10, but Ubuntu 11.10 is only distributing 64-bit packages. I'd be happy to build Spice from source if someone could tell me whether I can expect it to work in 32-bit, but I've asked around and no one has responded yet.
My current /etc/libvirt/qemu guest configuration file is attached. I've tried a whole bunch of different configurations though.
Mapping my USB key to an IDE drive seems to be the most reliable and have the best throughput. Mapping it to SCSI does not work at all as Haiku does not support the emulated SCSI Host Bus Adapter. I would have expected that SCSI Pass-Through to allow Haiku to directly control the USB key would work best, but it works very poorly. Mapping it as a USB drive causes a 100% repeatible crash during boot.
I have a whole bunch of serial logs if you want them, but these problems have been so reproducible for me I don't expect that you'll need them.
There are several problems that are frequently reported in the serial log:
check sense: Hardware error
/dev/net/rtl81xx/0: media change, media 0x800020 quality 1000 speed 1000000000 /dev/net/rtl81xx/0: media change, media 0x900026 quality 1000 speed 10000000
ps2: strange mouse data, x-delta 127, trying resync ps2: strange mouse data, x/y overflow, trying resync ps2: bad mouse data, trying resync
virt-manager does not pass SysRq through to the guest, so I have never been able to use the keyboard to enter KDL. virt-manager does have a menu that sends various key combinations to the guest, but Alt-SysRq-D is not one of the listed key combos, and I cannot find a way to customize the menu options.
I'm planning to try Xen next. I've installed the Ubuntu packages but have not yet figured out how to configure it.
Haiku would work best under both KVM or Xen if it had paravirtualized drivers. This would include Virtio for block storage, QXL video for Spice or Xen video, as well as memory ballooning. I'm interested in virtualization, and would love to implement all these myself, but I am a long way from knowing enough about Haiku's internals to write any real code yet.