Fixing VMware clock synchronization problems

On a VMWare environment sometimes guest operating systems may experience synchronization problems resulting into wrong dates and/or times. This could be more than annoying.

From Timekeeping in VMware Virtual Machines, page 14:

VMware Tools includes a time synchronization feature that periodically checks the guest operating system clock against the host operating system clock and corrects the guest clock. Unlike non-VMware synchronization software, VMware Tools time synchronization works in concert with the built-in catchup feature in VMware virtual machines and avoids turning the clock ahead too far. To enable VMware Tools time synchronization in a guest, first install VMware Tools in the guest operating system. Next, check that time synchronization is turned on. You can enable synchronization from the graphical VMware Toolbox application within the guest. Alternatively, you can set the .vmx configuration file option tools.syncTime = true to enable time synchronization. Note that time synchronization in a Linux guest works even if you are not running the VMware Toolbox application. All that is necessary is that the VMware guestd process is running in the guest and tools.syncTime is set to true.

VMware Tools time synchronization is designed to be a second line of defense to deal with special cases where a guest operating system’s clock falls behind real time despite the built-in catchup mechanism provided in the virtual machine. It is normal for a guest’s clock to be behind real time whenever the virtual machine is stopped for a while and then continues running; in particular, after a suspend/resume, snapshot, disk shrink, or VMotion operation. These are the main cases that VMware Tools time synchronization is meant to handle. The guest’s clock may also fall behind in less common circumstances, such as under heavy load when the guest has not been able to get enough CPU time to handle all its timer interrupts. The VMware Tools time synchronization daemon is quite simple and has a few limitations. The daemon checks the guest clock only once per minute. If the guest clock is much farther behind the host time than the virtual machine’s built-in catchup mechanism expects it to be, the daemon resets the guest clock to host time and cancels any pending catchup. For most guest types, the daemon never turns the guest clock backward, even if the guest’s clock time is running ahead of real time. Turning the clock backward is seldom needed and can cause some guest software to become confused. If your guest’s clock is running ahead of real time, see Known Issues and Troubleshooting on page 18 for troubleshooting tips and potential solutions and workarounds.

Install VMware Tools and have the Virtual Machine synchronize its clock with the Host Machine’s (keep in mind that this might bring issues if the host and the guest are in different timezones because the guest will get the exact host’s time).

You may proceed by stopping the Virtual Machine and then editing the configuration file (xxxxxx.vmx) on the host machine, setting:

tools.syncTime = "true"

After that, you may start the Virtual Machine. The clock should now keep synchronized.


VMware Virtual Disk Manager usage

VMware Virtual Disk Manager - build 39867.
Usage: vmware-vdiskmanager.exe OPTIONS diskName | drive-letter:
Offline disk manipulation utility
     -c                   : create disk; need to specify other create options
     -d                   : defragment the specified virtual disk
     -k                   : shrink the specified virtual disk
     -n      : rename the specified virtual disk; need to
                            specify destination disk-name
     -p                   : prepare the mounted virtual disk specified by
                            the drive-letter for shrinking
     -q                   : do not log messages
     -r      : convert the specified disk; need to specify
                            destination disk-type
     -x     : expand the disk to the specified capacity

     Additional options for create and convert:
        -a       : (for use with -c only) adapter type (ide, buslogic or lsilogic)
        -s          : capacity of the virtual disk
        -t     : disk type id

     Disk types:
        0                 : single growable virtual disk
        1                 : growable virtual disk split in 2Gb files
        2                 : preallocated virtual disk
        3                 : preallocated virtual disk split in 2Gb files

     The capacity can be specified in sectors, Kb, Mb or Gb.
     The acceptable ranges:
                           ide adapter : [100.0Mb, 950.0Gb]
                           scsi adapter: [100.0Mb, 950.0Gb]
        ex 1: vmware-vdiskmanager.exe -c -s 850Mb -a ide -t 0 myIdeDisk.vmdk
        ex 2: vmware-vdiskmanager.exe -d myDisk.vmdk
        ex 3: vmware-vdiskmanager.exe -r sourceDisk.vmdk -t 0 destinationDisk.vmdk
        ex 4: vmware-vdiskmanager.exe -x 36Gb myDisk.vmdk
        ex 5: vmware-vdiskmanager.exe -n sourceName.vmdk destinationName.vmdk
        ex 6: vmware-vdiskmanager.exe -k myDisk.vmdk
        ex 7: vmware-vdiskmanager.exe -p m:
              (A virtual disk first needs to be mounted at m:
               using the VMware Diskmount Utility.)

VMware Virtual Disk Manager examples

Converting growable into preallocated disk
This line will convert the growable virtual disk ‘WebFileServer.vmdk’ to type 3 (aka ‘preallocated virtual disk split in 2Gb files’). The resulting virtual disk will be created as ‘WebFileServer_pre-alloc.vmdk’.

vmware-vdiskmanager -r "WebFileServer.vmdk" -t 3 "WebFileServer_pre-alloc.vmdk"

See Also

Using ejabberd with MySQL native driver

Get mysql driver (if ejabberd < 2.0.0)

If you are using an ejabberd version previous to 2.0.0 (about end of 2007) then you need to put the MySQL .beam files somewhere in your Erlang path (possibly with your ejabberd .beam files):

cd /opt/
tar xvfz mysql_beam.tar.gz
cp -v *.beam /var/lib/ejabberd/ebin/

Mysql initialization

mysql> GRANT ALL ON ejabberd.* TO 'ejabberd'@'' IDENTIFIED BY '';
Query OK, 0 rows affected (0.06 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

Empty database creation:

mysql> CREATE DATABASE ejabberd;
Query OK, 1 row affected (0.00 sec)

Schema creation:

cd /tmp
mysql ejabberd &lt; mysql.sql -p
Enter password:

Check that the database structure has been correctly created:

echo "show tables;" | mysql -D ejabberd -uroot -p
Enter password:

Ejabberd configuration

If you installed ejabberd from sources, you would probably need to proceed compiling again but using:

./configure --enable-odbc

Comment out the following line in ejabberd.cfg:

{auth_method, internal}.

Add the following lines in ejabberd.cfg:

{auth_method, odbc}.
{odbc_server, {mysql, "localhost", "ejabberd", "ejabberd", "password"}}.

Note: The MySQL configuration description is of the following form:

{mysql, Server, DB, Username, Password}

When you have done that user accounts are stored in MySQL. You can define extra information that you might want to store in MySQL. Change the module used in ejabberd.cfg to change the persistence from the Mnesia database to MySQL:

* Change mod_last to mod_last_odbc to store the last seen date in MySQL.
* Change mod_offline to mod_offline_odbc to store offline messages in MySQL.
* Change mod_roster to mod_roster_odbc to store contact lists in MySQL.
* Change mod_vcard to mod_vcard_odbc to store user description in MySQL.


Sticky sessions (aka persistence)

While working with load balancers it is sometimes required that the client connects to the same backend server all the time. This concept has several names (e.g.: sticky sessions, session stickiness, persistent sessions, persistence, etc…).

Wikipedia explains this concept clearly:

One dilemma when operating a load-balanced service, is what to do if the backend servers require some information (“state”) to be stored “persistently” (across multiple requests) on a per-user basis. This can be a problem if a backend server needs access to information generated by a different backend server during a previous request. Performance may suffer if cached information from previous requests is unavailable for re-use.

One solution is to consistently send clients to the same backend server. This is known as “persistence” or “stickiness”. One downside to this technique is lack of automatic failover, in case one or more backend servers should fail or be taken offline for maintenance. Persistent information is lost if it cannot be transmitted to the remaining backend servers. Citation.

See Also

Opening Large Capture Files with WireShark (aka Ethereal)

Sometimes it might be needed to open ”’big”’ network traffic capture files (a.k.a. .cap) . This challenge is commonly encountered since this sort of logging it is usually very verbose. Leaving a packet sniffer (such as tcpdump) overnight logging all the packets that go through a network interface card might generate several gigs of data.

WireShark (formerly known as Ethereal) is an excellent open source packet sniffer with a nice user interface (GUI) and available for many different platforms.

According to WireShark’s documentation:

Wireshark uses memory to store packet meta data (e.g. conversation and fragmentation related data) and to display this info on the screen.

How much memory actually used is depending on:

  • the number of packets captured (well, depending on the capture duration and the network load on the line)
  • the kind of packets captured (small/large packets, some packet types will lead to much more memory usage than others)
  • the preference settings, e.g. the “TCP desegmentation” setting

In my experience (and with the capture files and Preference settings I’m usually working with), I need about ten times of memory than the actual capture file size. But again, this will largely depend on the things noted above.

Fortunately, WireShark includes a easy-to-use tool to manipulate capture files: editcap.

Editcap is able to do things like processing a huge capture file and extract the packet information that correspond to a certain period of time. This functionality is perfect if, let’s say, you have a 24 hours capture file and you know that problems were reported at a certain time. You could then extract a bunch of packets around that time, export this into a new file and open it using WireShark.

Editcap Usage

Usage: editcap [options] ...   [ [-] ... ]

A single packet or a range of packets can be selected.

Packet selection:
  -r                     keep the selected packets, default is to delete them
  -A         don't output packets whose timestamp is before the
                         given time (format as YYYY-MM-DD hh:mm:ss)
  -B          don't output packets whose timestamp is after the
                         given time (format as YYYY-MM-DD hh:mm:ss)
  -d                     remove duplicate packets

Packet manipulation:
  -s            truncate each packet to max.  bytes of data
  -C            chop each packet at the end by  bytes
  -t    adjust the timestamp of each packet,
                          is in relative seconds (e.g. -0.5)
  -E  set the probability (between 0.0 and 1.0 incl.)
                         that a particular packet byte will be randomly changed

Output File(s):
  -c   split the packet output to different files,
                         with a maximum of  each
  -F       set the output file type, default is libpcap
                         an empty "-F" option will list the file types
  -T         set the output file encapsulation type,
                         default is the same as the input file
                         an empty "-T" option will list the encapsulation types

  -h                     display this help and exit
  -v                     verbose output

Editcap Example
This example extracts all the packet information corresponding to 4th July 2008, 6am to 7am and writes it into a new file, i.e.:

  • Source file: 2008-07-04_capture.cap (813 MB)
  • Destination file: 6to7.cap (48.5 MB)
editcap -A "2008-07-04 06:00:00" -B "2008-07-04 07:00:00" 2008-07-03_capture.cap 6to7.cap

Showing MySQL Permissions


mysql> show grants for 'USERNAME'@'SERVER';


mysql> show grants for 'root'@'localhost';

| Grants for root@localhost                                                                                     |
1 row in set (0.00 sec)

See Also

Manipulating VMWare Virtual Disks with Virtual Disk Manager

From Using VMware Virtual Disk Manager:

VMware Virtual Disk Manager is a utility in VMware Server that lets you create, manage, and modify virtual disk files from the command line or within scripts.

One key feature is the ability to enlarge a virtual disk so its maximum capacity is larger than it was when you created it. This way, if you find you need more disk space on a given virtual disk, but do not want to add another virtual disk or use ghosting software to transfer the data on a virtual disk to a larger virtual disk, you can simply change the maximum size of the disk. This is something you cannot do with physical hard drives.

Another feature allows you to change whether or not all virtual disk space is preallocated or growable, and whether or not the virtual disk is stored in a single file or split into 2GB files. For example, you might find that you preallocated all the disk space for a virtual disk, but need to reclaim some hard disk space on the host. You can convert the preallocated virtual disk into a growable disk and remove the original virtual disk file. The new virtual disk is large enough to contain all the data on the original virtual disk. The virtual disk grows in size as you add data to it, as if you never preallocated the disk space when you created the virtual disk.
You can use the virtual disk manager to:

  • Automate the management of virtual disks with scripts.
  • Create virtual disks that are not associated with a particular virtual machine, to be used for templates, for example.
  • Switch the virtual disk type from preallocated to growable, or vice versa. When changing the disk type to growable, some space on the virtual disk is reclaimed. You can shrink the virtual disk to reclaim even more disk space.
  • Expand the size of a virtual disk so it is larger than the size specified when you created it.
  • Defragment virtual disks.
  • Prepare and shrink virtual disks without powering on the virtual machine (Windows hosts only).
  • Rename and move virtual disks.

You cannot use the virtual disk manager to create physical (raw) disks. You cannot shrink physical disks at all.

See Also


HAProxy hot-reconfiguration

As of version 1.2.8, a new soft-reconfiguration mechanism has been introduced.
It is now possible to “pause” all the proxies by sending a SIGTTOU signal to
the processes. This will disable the listening socket without breaking existing
connections. After that, sending a SIGTTIN signal to those processes enables
the listening sockets again. This is very useful to try to load a new
configuration or even a new version of haproxy without breaking existing
connections. If the load succeeds, then simply send a SIGUSR1 which will make
the previous proxies exit immediately once their sessions are closed ; and if
the load fails, then simply send a SIGTTIN to restore the service immediately.
Please note that the ‘grace’ parameter is ignored for SIGTTOU, as well as for
SIGUSR1 when the process was in the pause mode. Please also note that it would
be useful to save the pidfile before starting a new instance.

The ‘-st’ and ‘-sf’ command line options are used to inform previously running
processes that a configuration is being reloaded. They will receive the SIGTTOU
signal to ask them to temporarily stop listening to the ports so that the new
process can grab them. If anything wrong happens, the new process will send
them a SIGTTIN to tell them to re-listen to the ports and continue their normal
work. Otherwise, it will either ask them to finish (-sf) their work then softly
exit, or immediately terminate (-st), breaking existing sessions. Citation.


The command to be issued to restart HAProxy gracefully would be:

haproxy -f configfile -sf

Example (added the PID location):

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/ -sf $(cat /var/run/


Fixing VMWare vmxnet driver networking issues under Debian Linux

It seems that using particular combinations of VMWare Server and Linux Kernel version(s) while installing VMWare Tools under Linux guest machines, may render the virtual machine’s networking down.

This page provides a “hacky” workaround to solve this situation. There might be other deeper and more proper solutions out there but I came up with this one because it is very simple to put in place and not harmful at all.

So, let’s imagine this scenario:

  • VMWare Server 1.0.2 (other versions might apply as well, not tested thought)
  • Debian Linux 4.0 Etch guest, running 2.6.18-6-686 kernel (other versions might apply as well, not tested thought)
  • VMWare Tools 1.0.2-39867 (other versions might apply as well, not tested thought)

Then, after the VMWare Tools get installed, the screen shows something like this:

The configuration of VMware Tools 1.0.2 build-39867 for Linux for this running
kernel completed successfully.

You must restart your X session before any mouse or graphics changes take

You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X session.

To use the vmxnet driver, restart networking using the following commands:
/etc/init.d/networking stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/init.d/networking start


--the VMware team

Right now the networking does not work. If you try to see what is going on, you should see something like this:


lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1556 (1.5 KiB)  TX bytes:1556 (1.5 KiB)

That’s it. No network interfaces. If you go for VMWare Tools’ installer suggested steps, the networking should work again:

/etc/init.d/networking stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/init.d/networking start



eth0      Link encap:Ethernet  HWaddr 00:0C:29:23:95:ED
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::20c:29ff:fe23:95ed/64 Scope:Link
          RX packets:4425 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7426 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:316655 (309.2 KiB)  TX bytes:494628 (483.0 KiB)
          Interrupt:169 Base address:0x1424

lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1556 (1.5 KiB)  TX bytes:1556 (1.5 KiB)

The issue here is that this settings will be lost upon restart. I guess it is a matter of having the proper modules loaded properly but I have not been able to find the proper configuration files combination to get this reliably enough.

Proposed solution/workaround

Basically, create a simple script that does what VMWare Tools’ intaller suggests and have it invoked upon system restart.

The script should contain the following:

#! /bin/bash
# vmxnet driver loader - loads the vmware network driver.


/etc/init.d/networking stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/init.d/networking start

This file should be created under /etc/init.d folder, with 755 permissions (i.e. chmod 755 filename). The, to have it invoken upon restart you could do this:

update-rc.d vmxnet-loader defaults 10
 Adding system startup for /etc/init.d/vmxnet-loader ...
   /etc/rc0.d/K10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc1.d/K10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc6.d/K10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc2.d/S10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc3.d/S10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc4.d/S10vmxnet-loader -> ../init.d/vmxnet-loader
   /etc/rc5.d/S10vmxnet-loader -> ../init.d/vmxnet-loader

I suggest having the initscript invoked with a lower sequence code (i.e. 10) so the networking gets activated before other services which may use and/or need it.

That’s it. Now your virtual machine’s networking should be fine upon restarts.

See Also