Bounty and timeline on vmware 5.x on FreeBSD 6.x

[Eric Anderson]

On 04/05/07 02:12, Per Hedeland wrote:
> Eric Anderson <anderson at freebsd.org> wrote:
>> On 04/04/07 17:17, Per Hedeland wrote:
>>> Christian Laursen <xi at borderworlds.dk> wrote:
>>>> "Rick C. Petty" <rick-freebsd at kiwi-computer.com> writes:
>>>>
>>>>> On Wed, Apr 04, 2007 at 01:44:01PM -0500, Eric Anderson wrote:
>>>>>>         libglibmm-2.4.so.1 => not found
>>>>>>         libglibmm_generate_extra_defs-2.4.so.1 => not found
>>>>>>         libatkmm-1.6.so.1 => not found
>>>>>>         libpangomm-1.4.so.1 => not found
>>>>>>         libgdkmm-2.4.so.1 => not found
>>>>>>         libgtkmm-2.4.so.1 => not found
>>>>>>         libgnomecanvasmm-2.6.so.1 => not found
>>>>>>         libsexymm.so.1 => not found
>>>>> I suspect most of these come from their GNOME C++ counterparts, such as
>>>>> glibmm, gtkmm, gnomemm, libgnomecanvasmm, libsexymm, et al.  Not sure if
>>>>> this would work but you could try installing the freebsd ports for these
>>>>> and adding some /etc/libmap.conf entries??
>>>> That will not work. Linux binaries need linux libraries, so the right thing
>>>> to do would be to make linux-* ports of the neccesary linux libraries.
>>> I don't want to dissuade anyone from trying, but unless things have
>>> changed drastically from vmware 3/4, the hard part of getting it to work
>>> on FreeBSD isn't finding Linux libraries for the binary, nor even
>>> fiddling with the Linuxolator to provide additional support for it (if
>>> that is even needed), but to port the Linux versions of the vmmon and
>>> (assuming you want networking) vmnet kernel modules.
>>>
>>> Source for these used to be, and probably still is, available in the
>>> vmware distribution, but it's a significant amount of work for someone
>>> with good kernel knowledge, and the requirements seem to be more or less
>>> different for each combination of vmware version and FreeBSD version
>>> (i.e. you need to produce vmware-version-specific ports with lots of
>>> FreeBSD #ifdefs). The diffs for vmware-3-vmmon are over 7000 lines.
>>>
>>> Orlando had "almost finished" the vmmon port for vmware 4, but there
>>> were still some problems left (e.g. it couldn't run on SMP FreeBSD
>>> IIRC), and he hadn't even started on vmnet (I believe that's the simpler
>>> of the two though, you basically replace it completely with an interface
>>> to if_tap which has/had most of the functionality needed). I had vmware
>>> 4 running briefly with his preliminary vmmon port, but without
>>> networking it was useless to me.
>>>
>>> Note that this isn't optional optimization stuff like kqemu, vmware will
>>> not run without vmmon, and will not have networking without vmnet.
>>> Again, this is the case with vmware 3/4, I haven't even looked at
>>> current versions.
>> Thanks for the info - all good points.  We'll never know unless someone 
>> at least *tries* to make it work, which is all I'm doing.  I just want 
>> to know what the barriers are, so someone who just wants to code can 
>> jump right in and start hacking away without all this other stuff in the 
>> way.
> 
> That's great of course, I just wanted to spare some/anyone the
> disappointment of thinking the lib dependencies were the major obstacle,
> only to find out that this isn't the case after a lot of boring work.:-)


Yes, understood.  I'm not particularly enjoying this part, but nobody 
else seems to be jumping up to the task, so I figured I could at least 
start on it.  I'm not a library guru, so I'm spinning a lot, but 
eventually I'll have those ironed out at least.


>> Maybe the real question is, what is QEMU missing, that VMWare has?  I 
>> can think of three things right off:
>>
>> - Good video card support
>> - Real PXE enabled network card
>> - VM extension use (huge in my opinion)
> 
> Personally (a relatively happy qemu user since a year or so) I don't
> care at all about the first two - and don't know if I care about the
> last one - what is it?:-)

The first one is essential for running any graphical OS at full screen 
on a halfway decent system (my laptop has 1920x1200 resolution!).  Sure 
I can run in a smaller window, but my point is that it isn't synchronous 
to vmware in that case.

PXE boot support is essential for a lot of people doing lots of kernel 
development, either in FreeBSD or Linux.  Of course you don't have to 
have that, but I've found it to be incredibly helpful.  QEMU actually 
has etherboot support, which supports pxe booting, but the FreeBSD BTX 
goo is slightly unhappy with that, and causes it not to work.  I don't 
know anything about BTX or assembly, so I can't help there.

The last one is relating to newer processors' feature of virtual machine 
extensions, both Intel ('Core' and 'Core 2') and latest AMD processors 
have that.  What that allows, is basically the virtual machine to run 
it's own virtual processor, using the real processor to do most of the 
CPU virtualization - which means the system runs native speed.  I can 
tell you from using VMWare workstation 5.5 with that extension, that it 
is *FAST*.  I think only work on kqemu kernel module would be needed 
there, but I don't know really.

Eric