Monday, June 29, 2009

SQL script to get VMware tools versions

Brief Description:
SQL Script to get Virtual Machine tools versions and the version of the corresponding parent Host.

We needed to check/verify that all Virtual Machines on our clusters had the correct version of the VMware tools relative to the corresponding Hosts in their parent cluster. Due to the clunkiness of getting across the board information out of virtual center, we looked at pulling the information from the Virtual Center Database and with PowerShell.

The information we needed to get was:
  • Virtual Machine Name
  • Virtual Machine Operating System
  • The Virtual Machine's tools version
  • Virtual Machine Tools Status
  • Parent Host Name
  • Parent Host Build

VMWare sees the tools version of the VM as OK if it meets or exceeds the Host product build version.

SQL Script is below, Benj is going to follow up with a PowerShell script to do the same because he thinks it's cooler.

    Use [YourVMwareDBName]
      select as VMName,
        vm.tools_version, vm.Guest_OS,
          case vm.tools_status
            when 0 then 'Not Installed' when 1 then 'Not Running' when 2 then 'Out of Date' when 3 then 'OK' when NULL then 'Indeterminate'
          end as Tools_Status, as Host_Name, ho.Product_Build as Host_Build
      from vpx_vm vm join vpx_entity ev on =
      join vpx_entity eh on = vm.host_id
      join vpx_host ho on = vm.host_id
      where is_template = 0 order by

Monday, June 22, 2009

How to set the default runlevel using yast2

You want to set the default runlevel for Novell SUSE SLES 10 from a script. You don’t want to edit files using text editors. The man page for yast2 is not clear.
Example of the problem:
server:~ # yast2 runlevel set runlevel 3
Unknown option for command 'set': 3
Use 'yast2 runlevel set help' for a complete list of available options.
server:~ # yast2 runlevel set help
YaST Configuration Module runlevel
Command 'set'
Set default runlevel after boot
runlevel [ 2 3 5 ] Specify default runlevel
help Print the help for this command
verbose Show progress information
server:~ # yast2 runlevel set runlevel=3

Friday, June 12, 2009

Debugging Windows 7

The correct way to debug a crash is to send it to the vendor, but sometimes that isn’t an option. In this case on my Windows 7 RC laptop which had been very stable. Support isn’t really an option on this pre-release software, so in an effort to determine why it had suddenly become unstable I broke down and did some investigation.

Windows 7 by default is configured to capture a kernel memory dump. I resisted the instinct to hard power off the laptop when it blue screened and waited for the memory.dmp file to finish writing. After that the laptop restarted itself, reported the error to Microsoft and offered me no advice.

To examine the dump file I downloaded the Windows Debugging Tools. They did not explicitly state they would work for Windows 7, but I had no problems. I did have to install them from an elevated command prompt to get the install to succeed. After that I started WinDbg from the start menu:


I then configured the debugger to use the Microsoft web symbols by choosing Symbol File Path in the File Menu (it’s that or download the actual symbols which takes too long):




After that I chose File – Open Crash Dump and navigated to c:\windows\memory.dmp. And received an error: “You don’t have permission to open this file”.


I then exited out from the debugger and restarted it by right clicking on the shortcut and choosing Run as administrator. Choose to save the workspace when prompted or you will have to reconfigure the symbol path. Then reopen the memory.dmp file. It opens the debugger and looks like this:


Type: !analyze -v

I got results like this:

0: kd> !analyze -v
* *
* Bugcheck Analysis *
* *

A driver is causing an inconsistent power state.
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 84d07c78, Physical Device Object of the stack
Arg3: 82b41ae0, Functional Device Object of the stack
Arg4: 85153f00, The blocked IRP

Debugging Details:


IRP_ADDRESS: 85153f00



IMAGE_NAME: disk.sys

Clicking on the hyperlinked device object in the above output gave me the following information (after a brief wait while the debugger chatted with the symbol server):

0: kd> !devobj ffffffff8511a7e0 f
Device object (8511a7e0) is for:
DR2 \Driver\Disk DriverObject 85633d00
Current Irp 00000000 RefCount 0 Type 00000007 Flags 01002050
Vpb 84cbe3f8 Dacl 8a848b84 DevExt 8511a898 DevObjExt 8511acd8 Dope 84c0a410
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) 85144020 \Driver\partmgr
AttachedTo (Lower) 84d07c78 \Driver\iScsiPrt

A-ha! The iScsiPrt driver. I had recently attached an iSCSI disk and was amazed at how well it worked despite the fact that my laptop was constantly docked, undocked and moved to disconnected networks. Apparently it wasn’t quite as stable as I suspected. I removed the favorite target and volume in the iSCSI control panel applet. Hopefully, that will allow a return to stability.

Despite this small amount of instability, I still adore Windows 7. I never took to Vista despite many attempts on home and work machines, and stayed on Windows XP. Now I cannot imagine going back.

Thursday, June 11, 2009

Access Denied when Administering NetApp root volume with Microsoft Client for NFS

Symptom Brief Description:
You receive an access denied message when attempting to use the Microsoft Client for NFS to modify files on a NetApp root volume.
Administering a NetApp filer requires the ability to modify certain files contained in the /etc directory of the root volume. The files are modifiable from a linux computer connected to the export, but not from a Windows computer.
  • Cannot create a new file in the /etc directory
  • Cannot modify a file in the /etc directory
The NetApp filer will only allow modification from a client with a UID of zero. Make the following registry changes to force the Microsoft Client for NFS to use the correct UID. This may cause problems accessing other resources if you use a UID mapping service within your organization.
Set or create the following DWORD (32-bit) values:
Name: AnonymousGid
Data: 0
Name: AnonymousUid
Data: 0
You may also need to set the following value depending on the configuration of your NetApp OnTap operating system.
Name: UseReservedPorts
Data: 0
Restart the Client for NFS service (or your machine). Reconnect the mount using syntax similar to:
mount toaster:/vol/root r:
Type ‘mount’ and ensure the properties show UID=0, GID=0.

You may need to use the "-o nolock" option in the mount command to get writes to succeed.

Friday, June 5, 2009

Cannot install VM additions for Windows 2000 on Microsoft Virtual PC 7

Symptom Brief Description:
You cannot install the VM additions, which provide mouse and video drivers, on a Windows 2000 guest on Microsoft Virtual PC 7 running on the Windows 7 RC.
Installation of the integration features or components, which were previously known as virtual machine additions fails on a Windows 2000 guest. Microsoft has dropped support for these older operating systems within Microsoft Virtual PC 7.
  • Installation of the integration features fails.
  • Video resolution is incorrect
  • Mouse does not release from screen
Copy the VMadditions.iso file from an installation of Microsoft Virtual PC 2007 SP1 running on a Windows XP computer. The default file location is C:\Program Files\Microsoft Virtual PC\Virtual Machine Additions\VMadditions.iso. Place the file on your Windows 7 machine with the newer additions at C:\Program Files\Windows Virtual PC\Integration Components (by default). You can than manually attach the ISO image to a virtual machine running Windows 2000 and install the additions.
This solution supplies video and mouse drivers within the guest, but sound does not function.