Category Archives: vmware

Quick and dirty fix for VMware Linux guests loosing clock accuracy

Posted on by

I covered on a previous post how to keep the clock synchronized for VMware Linux guest(s). Well this seems to not work at least for recent versions VMware Server 2 (i.e. the one with web based management console). For now the quick& dirty solution I am using is putting a cron job that executes ntpdate pretty often…

My cron job looks like this:

#
# Temporary fix for the time getting lost
#
0-59/10 * * * * /usr/sbin/ntpdate north-america.pool.ntp.org > /dev/null 2>1

Yes, this fix requires to have NTPDATE installed (apt-get install ntpdate under Debian).

Fixing VMware clock synchronization problems

Posted on by

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.

Solution
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.

References

VMware Virtual Disk Manager usage

Posted on by 
VMware Virtual Disk Manager - build 39867.
Usage: vmware-vdiskmanager.exe OPTIONS diskName | drive-letter:
Offline disk manipulation utility
  Options:
     -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

Posted on by

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

Manipulating VMWare Virtual Disks with Virtual Disk Manager

Posted on by

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

References

Fixing VMWare vmxnet driver networking issues under Debian Linux

Posted on by

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
effect.

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

Enjoy,

--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:

ifconfig

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          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

E.g.:

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0C:29:23:95:ED
          inet addr:10.123.16.83  Bcast:10.123.16.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe23:95ed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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:127.0.0.1  Mask:255.0.0.0
          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.
#
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin

/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