Time loop in VMware guest

If the guest VM should always boot with the same date/time on the RTC, two actions must be done:

1. Edit the .vmx file of the guest VM, and add a line like this:

rtc.starttime = "1238765436"

where the number is a 1970-based epoch, in seconds.

2. Boot the guest VM, and run VMtools. Disable the host-to-guest time synchronization, and reboot the guest VM.

Then, the guest VM will always boot with the same date and time in the calendar.

Setup a Samba server

Edit /etc/samba/smb.conf and add set the basic settings in the 'global' section. The only important item is the "security=user" option.

The important thing is to enable the samba users with:

# smbpasswd -a

which adds (-a) a new user to the samba user database, and sets a new password to it.
Not doing this causes a 'permission denied' error in the client when attempting to mount it.

The syntax to mount a samba share is:

# mount -t cifs -o user=,pass= //server/resource

In the /etc/samba/smbusers file, it is possible to map sambe user names to UNIX user names, but it is not required to do so. By default, samba does a one-to-one mapping.

If we want to announce the samba shares on the network, it is necessary to start the 'nmb' service. Use the normal chkconfig interface to start smb and nmb on startup:

# chkconfig --add nmb
# chkconfig --level 3 nmb on
# chkconfig --level 4 nmb on
# chkconfig --level 5 nmb on

Set up VMware server on a x86_64 system

Setting up a 1.0.8 VMware server on a 64-bit PC creates some problems because VMware is distributed in binary form only (rpm packages) for 32-bit i386 architectures .

In my case, the target distribution is a Fedora 10 x86_64, so the first step was installing the 32-bit base libraries, that is, glibc, X11, etc. This can be easily done with the 'yum' installer:

# yum install glibc.i686 libgcc.i386 lidstdc++.i386 zlib.i386
# yum install libX11.i386 libXtst.i386 libXrender.i386 libXt.i386

Also, some Perl modules are required for the VMware installer to work properly:

# yum install perl-ExtUtils-Embed

which is not 32-bit specific, of course.

Now, we are in a position where the VMware-server package may be installed:

# rpm -ivh VMware-server-1.0.8.i386.rpm

If we hadn't installed the i386 libraries, the vmware-server rpm could be installed anyway but problems would appear when running the vmware-config.pl script, which runs the vmware-ping utility, which is a 32-bit one.

Now, some patches to the vmware distribution must be installed. In my case, the vmware-any-any-117d could not be installed, as it returned an error when compiling the kernel modules (something about an already defined symbol). The update that worked fine was 'vmware-update-2.6.27-5.5-2.tar.gz' but this depends on the particular kernel version that runs in my target system.

Installing this update is quite straightforward, however, this tarball contains a compiled 'update' executable which is intended for 32-bit installations. I decided to delete it and recompile manually before running the update:

# tar xfz vmware-update-2.6.27-5.5-2.tar gz
# cd vmware-update-2.6.27-5.5-2
# rm update
# gcc update.c -o update
# ./runme-pl

The 'runme.pl' script automatically launches the 'vmware-config.pl' script. I accepted all the proposed default answers, except for the NAT networking, which I answered 'no', the host-only networking -also 'no'- and the TCP port to listen to, which is by default 904, but I changed it to 902 to match the default port the clients connect to (why this discrepancy in the defaukt values?).

If I had accepted the 904 port in the server side, then the client wouldn't connect to the server and would return a 'connection refused' error. Fortunately, the client connectiomn dialog accepts an optional port number after the server IP, i.e. myserver:904.

After this, the client still returned an error when attempting to connect to the client: 'login incorrect (username/password)'. After some investigations, I found out that the problem was in the PAM libraries. Again, only the 64-bit pam libraries were installed, but vmware expects the 32-bit libraries, so the user authentication failed. Unfortunately, the pam i386 and x86_64 libraries cannot coexist simultaneously, because there are some common files provided by both packages (i.e. the man pages). So, the workaround is to download the pam package and its dependencies, and do a force install:

# yumdownloader --resolve pam.i386
# rpm -ivh --force *.rpm

Also, we must configure the proper path to the pam libraries.
Edit /etc/pam.d/vmware-authd :

#%PAM-1.0
auth sufficient /lib/security/pam_unix2.so shadow nullok
auth required /lib/security/pam_unix_auth.so shadow nullok
account sufficient /lib/security/pam_unix2.so
account required /lib/security/pam_unix_acct.so

After all this, vmware server runs correctly and clients may connect.

To install the vmware client (a.ka. vmware-server-console), all I had to do is install the client rpm:

# rpm -ivh VMware-server-console-1.0.8-126538.i386.rpm
# vmware-config-server-console.pl

and that's all.