Hi,  From your description I am not sure of your configuration?  Please refrain from using the term "VMware" so much, please specify more clearly, like VMware Server 2.0.2, or the VMware Virtual Machine, or VMware Tools, as I am not always sure what you are referring to.

I am guessing that have upgraded your base Operating System from Fedora 12 to Fedora 14 64bit, would this be correct?  And that you are running VMware Server 2.0.2 in this environment.

Have you completely uninstalled the old installation of VMware Server from your upgraded Fedora 12, base Operating System?  And then recompiled/installed VMware Server 2.0.2 into your 64 bit Fedora 14 computer ?  If you have not, I would recommend doing so, if this is possible. I have had issues when having compilied a kernel for Nvidia drivers and then upgraded the version of linux, of course the previously compiled drivers/modules are unlikely to work in the later linux version and need to be recompilied.

Personally I have only used Debian 64 bit once, and that was a while ago now, and while VMware Server ran perfectly, I had issues with other applications so I moved back to using the 32 bit PAE kernels.  I believe that VMware Server was still able to create 64 bit virtual machines when running on a 32 bit PAE kernel.

I hope some of what I have written may help you.  If you supply more information about your environment, and the steps that you have done, other may be able give further assistance.

Hmmm, do I have this correct?;

1) You had VMware Server 2.0.2 working well installed in 64 Bit Fedora 12 64 Bit on a Intel Core2Duo PC

2) You then performed a clean install 64 bit Fedora 14 on the Intel Core2Duo PC

3) You then attemtped to install VMware Server 2.0.2, however the installation fails

I built a 64 bit Fedora 14 image and attempted to install VMware Server 2.0.2 (VMware-server-2.0.2-203138.x86_64.tar.gz) and this was certainly not successful, neither was the rpm.

I have not attempted to apply any specific fixes as you have.  Lets hope some one in the wider community can work out how to modify the installation scripts to work with Fedora 14.

I have almost exactly the same problem.

New install of Fedora 14, with yum update, taking me to

  kernel 2.6.35.10-74.fc14.x86_64

  glibc at glibc-2.12.90-21.x86_64

VMWare server 2.0.2.

Had to use magic script from http://www.howtoforge.com/how-to-install-vmware-server-2-on-a-fedora-14-desktop-kernel-2.6.35.

(This is exactly the kind of thing that VMware should continously be fixing for us, IMHO, regardless of stated platform support).

I observe I can log into the webAccess using localhost:8222, but when I click on the Virtual Machines tab it takes a long time before it returns an empty list.

If I then try to use Virtual Machine, Add virtual machine to inventory, vmware-hostd catches signal 11, and then terminates.

I tried using various versions of glibc, from the Fedora archives, from 2.5 to 2.10, using LD_LIBRARY_PATH to get them loaded, and when I do so, I can't get vmware-hostd to stay running. This is because the alternative libc.so.6 has dependencies on various things in /lib64/ld-linux-x86-64.so.2 such as get_rlimit, and I can't make it use an older copy of ld-linux-x86-64.so.2. I am certainly not going to change the copy in /lib64.

By amending /etc/abrt/abrt.conf so that ProcessUnpackaged = yes, and restarting abrtd, and amending /usr/sbin/vmware-hostd so that it does ulimit -c unlimited I can get a core dumped, to see what went wrong.

[root@nyangau /var/spool/abrt/ccpp-1293553486-26532]# gdb /usr/lib/vmware/bin/vmware-hostd coredump

... snip

(gdb) where
#0  0x0000003ee327a694 in _int_malloc () from /lib64/libc.so.6
#1  0x0000003ee327aea8 in malloc_check () from /lib64/libc.so.6
#2  0x00007f046b18c4fd in operator new(unsigned long) () from /usr/lib/vmware/lib/libstdc++.so.6/libstdc++.so.6
#3  0x00007f046b8ffa35 in Vmacore::System::SystemFactoryImpl::CreateBacktrace(Vmacore::Ref<Vmacore::System::Backtrace>&) ()
   from /usr/lib/vmware/vmacore/libvmacore.so.1.0
#4  0x00007f046ba06599 in Vmacore::System::GenerateCoreDump() () from /usr/lib/vmware/vmacore/libvmacore.so.1.0
#5  0x0000000000ab368e in DumpTraceCoreAndExit(int) ()
#6  <signal handler called>
#7  0x0000003ee3332ad0 in __strncmp_ssse3 () from /lib64/libc.so.6
#8  0x00007f046b426622 in __xmlParserInputBufferCreateFilename (URI=0x6973810 "/work/vm/Kudu/Kudu.vmxf", enc=XML_CHAR_ENCODING_NONE)
    at xmlIO.c:2305
#9  0x00007f046b40057b in xmlNewInputFromFile__internal_alias (ctxt=0x698ddd0, filename=0x6973810 "/work/vm/Kudu/Kudu.vmxf")
    at parserInternals.c:1450
#10 0x00007f046b42705d in xmlDefaultExternalEntityLoader (URL=0x6973810 "/work/vm/Kudu/Kudu.vmxf", ID=0x0, ctxt=0x698ddd0)
    at xmlIO.c:3631
#11 0x00007f046b4031a4 in xmlCreateURLParserCtxt__internal_alias (filename=0x6973810 "/work/vm/Kudu/Kudu.vmxf", options=0)
    at parser.c:12125
#12 0x00007f046b417f4a in xmlReadFile__internal_alias (filename=0x7f04644e7b90 "<?xm\004\177", encoding=0x0, options=4)
    at parser.c:13197
#13 0x0000000001e864f6 in ?? ()
#14 0x0000000001edac98 in ?? ()
#15 0x0000000001e9326d in ?? ()
#16 0x0000000001ea1341 in ?? ()
#17 0x0000000001cce5d9 in ?? ()
#18 0x0000000001ccec21 in ?? ()
#19 0x0000000001e9f1b8 in ?? ()
#20 0x0000000001c6836f in ?? ()
#21 0x0000003ee3606d5b in start_thread () from /lib64/libpthread.so.0
#22 0x0000003ee32e4a7d in clone () from /lib64/libc.so.6

(gdb) frame 7
#7  0x0000003ee3332ad0 in __strncmp_ssse3 () from /lib64/libc.so.6
(gdb) disassemble
Dump of assembler code for function __strncmp_ssse3:
   0x0000003ee3332aa0 <+0>:    test   %rdx,%rdx
   0x0000003ee3332aa3 <+3>:    je     0x3ee33341e4 <__strncmp_ssse3+5956>
   0x0000003ee3332aa9 <+9>:    cmp    $0x1,%rdx
   0x0000003ee3332aad <+13>:    je     0x3ee33341f0 <__strncmp_ssse3+5968>
   0x0000003ee3332ab3 <+19>:    mov    %rdx,%r11
   0x0000003ee3332ab6 <+22>:    mov    %esi,%ecx
   0x0000003ee3332ab8 <+24>:    mov    %edi,%eax
   0x0000003ee3332aba <+26>:    and    $0x3f,%rcx
   0x0000003ee3332abe <+30>:    and    $0x3f,%rax
   0x0000003ee3332ac2 <+34>:    cmp    $0x30,%ecx
   0x0000003ee3332ac5 <+37>:    ja     0x3ee3332b10 <__strncmp_ssse3+112>
   0x0000003ee3332ac7 <+39>:    cmp    $0x30,%eax
   0x0000003ee3332aca <+42>:    ja     0x3ee3332b10 <__strncmp_ssse3+112>
   0x0000003ee3332acc <+44>:    movlpd (%rdi),%xmm1
=> 0x0000003ee3332ad0 <+48>:    movlpd (%rsi),%xmm2
   0x0000003ee3332ad4 <+52>:    movhpd 0x8(%rdi),%xmm1
   0x0000003ee3332ad9 <+57>:    movhpd 0x8(%rsi),%xmm2

My Fedora 14 has zlib-1.2.5-2.fc14.x86_64, and that is whats being used as /lib64/libz.so.1.

My Fedora 14 has libxml2-2.7.7-2.fc14.x86_64, but of course, vmware-hostd, isn't using that, its using /usr/lib/vmware/lib/libxml2.so.2/libxml2.so.2, and I haven't found an easy way to find out what version that is yet.

http://us.generation-nt.com/answer/bug-565683-peers-inside-zlib-internal-code-help-168989591.html

talks about libxml2 violating zlibs interface, and shows a sample of offending code.

When I use GDB to disassemble where we are in xmlParserInputBufferCreateFilename, it looks strikingly similar.

Maybe VMwares libxml2 is compiled against an older zlib, and violates its interface.

Maybe I need to try getting vmware-hostd to use zlib prior to 1.2.3.5...

{{{ Andy

Thank you!

I did the "libxml" trick and now it works. Btw, i'm using a 32 bits system.

It was driving me crazy because it only failed when i opened a machine or restarted vmware after creating one.

You should consider using ESXi which is free, but usually requires "better" hardware (eg: requires 2 or 3 GB of ram, won't recognize most 100mb ethernet cards, etc).

You will also need a windows box to configure it, or try the cli.

Afaik this is the support status:

raid: only hardware raid controllers are supported (no software raids nor fakeraids)

bzip some vm: tar/gzip is available from console

scripts/maintenances: you could add a small linux VM if the console is not enough.

firewall: You may use a linux VM to perform NAT and other firewall tasks.