Skip to content

VMware Workstation Unrecoverable Error: (vmx) NOT_IMPLEMENTED

I RDP’d to my workstation and attempted to start a virtual machine in VMware Workstation 6.5.2. However, part of the way through the boot process VMware would pop up the following error:

VMware Workstation Unrecoverable Error

VMware Workstation Unrecoverable Error

Looking at the log file I would see

NOT_IMPLEMENTED d:/build/ob/bora-156735/bora/vmx/main/pollVMX.c:3651

It didn’t matter whether I was trying to start a Windows or a Linux virtual machine, I still got the error.

The cause appears to have been my display settings. I changed my RDP client settings to “High Color (16 bit)” and everything started working.

Moving MS SQL Server 2000 to new hardware

We had the fibre channel cards on our SQL Server fail on us. We had been planning to replace this server, and the storage array it was attached to, so we decided to bring that forward rather than repairing the server. Note we also had a copy of the server running in an isolated virtual machine for testing. All of our databases, including master.mdf were on a LUN on the storage array (previously mounted as D:).

Here are the steps we took in migrating our server:

  1. Installed Windows and drivers on the new server.
  2. Modified the zones and mounted the LUN containing the SQL databases on the existing storage array to the new server (E:).
  3. Created the required LUN on the new storage array and mounted on the new server (D:).
  4. Used robocopy E:\ D:\ /MIR /R:0 /W:1 to copy the databases from the old LUN to the new LUN.
  5. Unmounted the old LUN and undid the zone changes.
  6. Moved everything on D: to a temporary directory on D: (so they wouldn’t get overwritten during the install of SQL Server 2000). Note, move the files to the same filesystem so everything happens instantly (i.e. not a copy).
  7. On the old server, exported HKLM\Software\Microsoft\MSSQL from the registry.
  8. Copied the SID from the old server to the new server using newsid.exe (I had a friend run into a problem when restoring databases to a new server during a DR test. Because the SID of the new server was different to the old server security in the database didn’t work correctly. I assume this was because they were using local Windows accounts. ) I don’t know if we needed to do this step, but we did it just in case.
  9. Removed the old server from the domain and renamed it. Changed its IP address.
  10. Renamed the new server to the original name of the old server and added it to the domain. Set its IP address to the one previously used on the old server.
  11. Installed SQL Server 2000. During the installation we specified the same paths as had been used on the old server (D:\Databases).
  12. Installed SQL Server 2000 service packs.
  13. Shut down the SQL services.
  14. On the new server, exported HKLM\Software\Microsoft\MSSQL from the registry (just in case things went wrong).
  15. On the new server, imported HKLM\Software\Microsoft\MSSQL that had been exported from the old server.
  16. Renamed the directory containing the new master.mdf (D:\Databases to D:\Databases.freshinstall).
  17. Moved the directories in the temporary directory back to their original location in D:.
  18. Restarted the SQL services.

Everything still seems to be working so I guess it worked. Luckily we weren’t using local accounts (only domain accounts) so we didn’t have to try to recreate the original accounts (which might have caused an issue with different account SIDs).

Windows Server 2003 W32Time Errors

The time on my PC at work has been gradually getting out of wack. So I took a look at the PDC Emulator (PDCe)in the root of our Active Directory forest and found lots of W32Time errors like:

The time provider NtpClient cannot reach or is currently receiving invalid time data from 192.168.1.1 (ntp.m|0x8|172.16.1.1:123->192.168.1.1:123).

192.168.1.1 is a Windows Server 2003 machine in our DMZ. The DMZ server synchs the time with time.windows.com and the PDCe synchs the time with the DMZ server. This used to work fine (well after many teething problems) when the server in the DMZ ran Linux. However, since moving the function to a Windows server it seems to have failed.

Looking at the debug logs (see the entries for the various filelog registry keys for information on enabling logging) I found the following errors:

149095 16:21:16.1250000s - ListeningThread -- response heard from 192.168.1.1:123 149095 16:21:16.1250000s - /-- NTP Packet:
149095 16:21:16.1250000s - | LeapIndicator: 3 - not synchronized;  VersionNumber: 3;  Mode: 4 - Server;  LiVnMode: 0xDC
149095 16:21:16.1250000s - | Stratum: 0 - unspecified or unavailable
149095 16:21:16.1250000s - | Poll Interval: 15 - out of valid range;  Precision: -6 - 15.625ms per tick
149095 16:21:16.1250000s - | RootDelay: 0x0000.0000s - unspecified;  RootDispersion: 0x0001.0400s - 1.01563s
149095 16:21:16.1250000s - | ReferenceClockIdentifier: 0x00000000 - unspecified
49095 16:21:16.1250000s - | ReferenceTimestamp:   0xCD676E70C58C64FD149095 16:21:16.1250000s -  - 12881592560771673500ns - 149092 12:09:20.7716735s
149095 16:21:16.1250000s - | OriginateTimestamp:   0xCD6B9DFC20000000149095 16:21:16.1250000s -  - 12881866876125000000ns - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | ReceiveTimestamp:     0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - | TransmitTimestamp:    0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - >-- Non-packet info:
149095 16:21:16.1250000s - | DestinationTimestamp: 149095 16:21:16.1250000s - 0xCD6B9DFC20000000149095 16:21:16.1250000s -  - 12881866876125000000ns149095 16:21:16.1250000s -  - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | RoundtripDelay: 000ns (0s)
149095 16:21:16.1250000s - | LocalClockOffset: -142822326500ns - 2:22.822326500
149095 16:21:16.1250000s - --
149095 16:21:16.1250000s - Peer 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123) is not Win2K. Setting compat flags.
149095 16:21:16.1250000s - Packet test 6 failed (not syncd or bad interval since last sync).
149095 16:21:16.1250000s - Packet test 7 failed (bad stratum).
149095 16:21:16.1250000s - Ignoring packet that failed tests from 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123).

Note the bad stratum message. I don’t know why these servers didn’t want to work together. The commands
w32tm /stripchart /computer:192.168.1.1

and
w32tm /monitor /computers:192.168.1.1

showed that they communicate using NTP. The way I got around it was to simply configure the PDCe to synch with the time server of a local ISP:
rem Stop the Windows Time service
net stop w32time

rem Set everything back to defaults
w32tm /unregister
w32tm /register

rem Start the Windows Time service
net start w32time

rem Specify the NTP server
w32tm /config /manualpeerlist:100.20.3.4 /syncfromflags:manual /reliable:yes /update

Note I thought about synching the PDCe with time.windows.com, but that address resolves to time.microsoft.akadns.net – so I imagine that the IP address will change fairly often which would cause a problem on the firewall access-list.
For troubleshooting information on Windows and NTP I recommend Windows Time and the W32TM service.

Where are VMware Infrastructure 3.5 snapshots stored?

When you create a snapshot in VMware Instrastructure (formerly ESX), the server stops updating the .vmdk files. Instead it creates a delta file for each .vmdk file. Any writes are written to the delta file rather than the .vmdk file.

This has a few implications:

  • The amount of disk space used will increase (a delta can theoretically grow as large as the original .vmdk).
  • Read performance can suffer (both the .vmdk and the delta file will now need to be read).

The delta file is stored with the virtual machine’s configuration file, not with the .vmdk file. So, if you have multiple .vmdk files on different volumes you might be in for a surprise.

In the example below I have a virtual machine called VM-Test. It has two .vmdk files, one in /vmfs/volumes/storage1/VM-Test and one in /vmfs/volumes/storage2/VM-Test. I have shown the directory listings before and after taking a snapshot. As you can see the delta for both .vmdk files is stored in the same directory as the configuration file.

Before the snapshot:

[root@vmsvr /]# cd /vmfs/volumes/storage1/VM-Test
[root@vmsvr VM-Test]# ls -l
total 8651072
-rw-------    1 root     root     268435456 Dec 14 22:08 VM-Test-38405ab5.vswp
-rw-------    1 root     root     8589934592 Dec 14 22:16 VM-Test-flat.vmdk
-rw-------    1 root     root         8664 Dec 14 22:08 VM-Test.nvram
-rw-------    1 root     root          314 Dec 14 22:11 VM-Test.vmdk
-rw-------    1 root     root            0 Dec 14 21:53 VM-Test.vmsd
-rwxr-xr-x    1 root     root         1572 Dec 14 22:08 VM-Test.vmx
-rw-------    1 root     root          252 Dec 14 22:08 VM-Test.vmxf
-rw-r--r--    1 root     root        19089 Dec 14 22:11 vmware.log
[root@vmsvr VM-Test]# ls -l ../../storage2/VM-Test/
total 4194368
-rw-------    1 root     root     4294967296 Dec 14 22:16 VM-Test_1-flat.vmdk
-rw-------    1 root     root          314 Dec 14 22:11 VM-Test_1.vmdk

After creating a snapshot:

[root@vmsvr VM-Test]# ls -l ../../storage2/BC-Test1/
total 4194368
-rw-------    1 root     root     4294967296 Dec 14 22:16 VM-Test_1-flat.vmdk
-rw-------    1 root     root          314 Dec 14 22:11 VM-Test_1.vmdk
[root@vmsvr VM-Test]# ls -l
total 9591296
-rw-------    1 root     root     671088640 Dec 14 22:26 VM-Test-000001-delta.vmdk
-rw-------    1 root     root          248 Dec 14 22:18 VM-Test-000001.vmdk
-rw-------    1 root     root     16777216 Dec 14 22:26 VM-Test_1-000001-delta.vmdk
-rw-------    1 root     root          310 Dec 14 22:18 VM-Test_1-000001.vmdk
-rw-------    1 root     root     268435456 Dec 14 22:08 VM-Test-38405ab5.vswp
-rw-------    1 root     root     8589934592 Dec 14 22:17 VM-Test-flat.vmdk
-rw-------    1 root     root         8664 Dec 14 22:08 VM-Test.nvram
-rw-------    1 root     root     273866015 Dec 14 22:18 VM-Test-Snapshot1.vmsn
-rw-------    1 root     root          314 Dec 14 22:11 VM-Test.vmdk
-rw-------    1 root     root          542 Dec 14 22:18 VM-Test.vmsd
-rwxr-xr-x    1 root     root         1510 Dec 14 22:25 VM-Test.vmx
-rw-------    1 root     root          252 Dec 14 22:25 VM-Test.vmxf
-rw-r--r--    1 root     root        30121 Dec 14 22:25 vmware.log

GNS3 and Vista 64bit

GNS3 installs on the 64 bit version of Windows Vista without any errors. However, when you try to test Dynamips you may get the error “Failed to start”. If you try to create a router you may get the error “Can’t start dynamips on port 7200″.

There are two things you may have to do:

  • By default, GNS installs in the directory C:\Program Files(x86)\GNS3 directory. GNS3 installs Dynamips below that in C:\Program Files(x86)\GNS3\Dynamips. However, GNS3 is configured by default to look for Dynamips under C:\Program Files\GNS3\Dynamips. You will need to update the path to the correct location (Under Edit, Preferences, Dynamips).
  • Check that you have the correct file system permissions to the above directories.

How to tell if another instance of a VBS script is running

The following VBS function will allow you to check if another instance of your script is running. Note, I have only tested this for one user.

Function OtherInstances()
  ' This function determines if there are other instances of this script running. If other instances are running it returns TRUE, otherwise it returnes FALSE
 
  Dim strComputer, objWMIService, colItems, objItem, Count
 
  strComputer = "."
  Count = 0
  Set objWMIService = GetObject("winmgmts:" _
      & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
  Set colItems = objWMIService.ExecQuery _
      ("Select * from Win32_Process Where Name = 'cscript.exe'" & _
          " OR Name = 'wscript.exe'")
  For Each objItem in colItems
      If InStr(1, LCase(objItem.CommandLine), LCase(Wscript.ScriptName)) > 0 Then
        Count = Count + 1	
	  End If
  Next
 
  If Count > 1 Then
    OtherInstances = TRUE
  Else
    OtherInstances = FALSE 
  End If
End Function

Copy CUPS configuration from one server to another

Many versions of Linux use the Common UNIX Printing System (CUPS). Need to copy the configuration from one server to another? Here’s how.

Stop CUPS on the target system

Rename or backup the exiting CUPS configuration

mv /etc/cups /etc/cups.orig

Copy the /etc/cups directory from the source system to the destination system

Copy any modified model files from the source system to the destination system. These files should be in /usr/share/cups/model

On the destination server edit the file /etc/cups/cupsd.conf and check if the hostname or IP address of your source server is present. If so, change it to the destination server.

If any custom groups or accounts are used on the old system to manage CUPS recreate them on the new system.

Restart cups.

Test

Script to document a Red Hat Enterprise Linux 3 system

This script should output html documenting the important parts of a system:

sysinfo

If anyone sees something I’ve left out, and I’m sure there’s a lot, please leave a comment.

Firefox locks up for a minute or two when downloading – fix

I have been having an issue with Firefox locking up when I download something. It seems to consume 100% of the CPU for a minute or two before starting the download.

Thanks to a posting by “Bountyhunter” at http://forums.macosxhints.com/archive/index.php/t-63868.html it’s now fixed. To quote the post:

I came across this post while I was trying to fix the same problem, and I found the solution is that the download history is extremely full, and takes a long time to load, thereby hanging up Firefox for a while. Click the “Clean Up” button at the bottom of the “Downloads” window, and it’ll be fixed. You can also set it to do that automatically for you under Tools->Options->Privacy->Download History

http://billstclair.com/blog/slow_firefox_downloads_fixed.html
and
http://kb.mozillazine.org/Firefox_hangs#Hang_downloading_files

Backing Up a Linux server in the DMZ to a Windows Share

This script connects to a remote Linux server and backs it up to a file share on a Windows server. Note, that because the version of smbfs used does not support files larger than 2GB the backup is split into multiple files. Later versions of smbfs don’t have this limitation.

 #!/bin/sh
 RemHost=lnx-server
 TarFile="/windows-server/lnx-server-backup/lnx-server.tar.gz."
 # Mount the drive to backup to
 mount -t smbfs -o username="domain\\account" \
   -o password="'password'" \
   '//windows-server/lnx-server-backup$' /mnt/lnx-server-backup
 
ssh $RemHost "cd / ; tar --gzip -cf - . ; /root/logs/backup.log" \
 | split -b 2000000000 - $TarFile
 sleep 10
 
umount /mnt/lnx-server-backup