Wednesday, 30 June 2010

Create a NFS share for VM ISO files with Windows 2003 Server R2

If your ESX servers are not connected to network storage or if you do not have enough available space on your SAN to dedicate a sub folder of a VMFS volume for ISO files, then you can use a NFS network share to centrally store these images. Creating the NFS share can be done with many server operating systems, but did you know that Windows Server 2003 R2 has native NFS? has many "how to" VMware Tips for ESX, and the following is the instructions found there for creating a Windows 2003 R2 NFS share:

  1. On the Windows 2003 Server make sure "Microsoft Services for NFS" in installed. If not you need to add it under Add/Remove Programs, Windows
    Components, Other Network File and Print Services
  2. Next go to folder you want to share and right-click on it and select Properties
  3. Click on the NFS Sharing tab and select "Share this Folder"
  4. Enter a Share Name, check "Anonymous Access" and make sure the UID and GID are both -2
  5. In VirtualCenter, select your ESX server and click the "Configuration" tab and then select "Storage"
  6. Click on "Add Storage" and select "Network File System" as the storage type
  7. Enter the Windows Server name, the folder (share) name and a descriptive Datastore Name
  8. Once it finishes the configuration you can now map your VM's CD-ROM devices to this new VMFS volume

Repeat steps 5 through 8 for each of your ESX servers to make the same ISO files available to all ESX hosts.

These instructions assume that you have already configured the VMkernel port group on a vSwitch for each ESX host. For instructions and information about configuring the VMKernel for NAS/NFS storage check the Storage Chapter of the ESX Server 3 Configuration Guide.

Of course, you can use the NFS share for more than just ISO file storage too. This is a good repository for patches and scripts that need to be used on all hosts. NFS also makes a good target for VM image backups too. Use some imagination and install the free VMware server on your 2003 R2 box and you have a low budget DR platform. Oh yeah, I shouldn't forget to mention you can even run ESX VMs from NFS!

Important Notes:

  • ESX version 3.x only supports NFS version 3 over TCP/IP.
  • Best practice for TCP/IP storage is to use a dedicated subnet. This will usually require creating separate Service Console and VMKernel port groups on a dedicated vSwitch.
  • On the Windows 2003 R2 server be sure to configure the shared folder so that the file permissions allow anonymous full control. You can make the share read only when adding the storage in ESX.
  • Be sure to remember to punch a hole in the ESX firewall for NFS. On the Configuration tab, go to the Security Profile settings and add the NFS Client so it appears in the allowed outbound connections.


You can also create a NFS share from the Windows command line with the following command

C:\>nfsshare [SHARENAME]=[path to folder, e:\foldername] -o rw -o root anon=yes anonuid=-2 anonguid=-2

You then need to manually add the Anonymous Access user account on the Security tab and set to "full control". (I bet you can do this from the cmd line too, but I do not have that command right now)


Thursday, 17 June 2010

How to Modify the All Users Startup Menu in Windows 2008, Vista and Windows 7

How to Modify the All Users Startup Menu

As you no doubt know, Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 have modified the locations for user profiles. They are no longer in %SystemDrive%\Documents and Settings and exist in the %ProgramData%\Users folder.

However, to modify the All Users profile to add a shortcut to the Startup menu you actually need to access the %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup folder.

Tuesday, 1 June 2010

Cannot open Virtual Machine Console

Original document located at vmware KB:


  • When you try to connect to a virtual machine console from VirtualCenter, you see one or more of these errors:
    • Error connecting: Login (username/password) incorrect
    • Error connecting: Host address lookup for server <SERVER> failed: The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for Do you want to try again?
    • Error connecting: cannot connect to host <host>: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Do you want to try again?
    • Error connecting: You need execute access in order to connect with the VMware console. Access denied for config file.
    • Unable to connect to MKS: failed to connect to server IP:903. For more information, see
      Troubleshooting the firewall policy on an ESX Server (1003634).
      ESX 4.0 hosts lose network connectivity when multiple service console interfaces are configured on subnets that use DHCP IP addresses (1010828).
  • You cannot open a remote console to a virtual machine.
  • Virtual machine console is black (blank).
  • The VMware Infrastructure (VI) Client console tab session may time out or disconnect while in use.
  • Migration of virtual machines using vMotion fails.
  • This issue may affect a single ESX  host. If the virtual machines are moved to another ESX host, you may be able to connect to the console without error.
  • This issue may occur if you try to connect to the console using VMware Infrastructure (VI) Client connected directly to the ESX host or to vCenter Server.


If your network is configured such that a firewall exists between the ESX host and the client running the workstation running VI Client, you might not be able to open a virtual machine console. To connect to a virtual machine console from VI Client, port 903 needs to be open in any firewall between the the workstation running VI Client and the ESX host. This
applies even if VI Client is connected to VirtualCenter and not directly to ESX host.

Note: Before performing the steps in this article:
  • For more information on restarting the Management agents, see Restarting the Management agents on an ESX Server (1003490).
  • For more information on editing configuration files, see Editing configuration files in VMware ESX (1017022).

To troubleshoot this issue:
(Just issuing step 1 worked for me !)

  1. Log in to the VirtualCenter Server directly through Terminal Services or a Remote KVM and attempt a connection from VI Client from this system. If this method works, the firewall is likely preventing the console from working. Configure your firewall to allow communications on port 903 between the ESX host and the workstation running VI Client.

    If port 903 is not open or cannot be opened in your environment, enable the vmauthd proxy. This forces remote console communication to be sent on port 902 on the Service Console, instead of 903.

    Note: By enabling this setting there may be degradation in performance communicating to the ESX host service console, if remote consoles are heavily utilized.

    To enable the proxy:
    1. Log in to the ESX host's service console as root.
    2. Open /etc/vmware/config with a text editor. 
    3. Add the following line:
      vmauthd.server.alwaysProxy = "TRUE"
    4. Issue the following command to restart xinetd:
      service xinetd restart
  2. Verify the ESX firewall policy.  For more information, see
  3. Verify that the ESX host and the workstation running VI Client are correctly synced to an NTP service. This is required to satisfy SSL handshaking between VI Client and ESX. For more information, see Verifying time synchronization across environment (1003736).

  4. DNS problems are a common cause of virtual machine console problems. Verify name resolution in your environment. For more information, see:

  • After verifying DNS, open a command prompt on the VI Client machine and perform the following:
    ipconfig /flushdns
    ipconfig /registerdns
  • Verify /var partition is not full.
  • Verify that the permissions for the virtual machine's .vmx file are set correctly. To set the permissions, run the command:
    chmod 755 </full/path/to/virtual machine.vmx>
  • If your ESX host has more than one service console configured, verify that they are not on the same network.
  • Check if the Service Console IP is routing traffic to the workstation running the vCenter. For more information on configuring the Service Console Gateway, see Changing the IP address, default gateway, and hostname of the Service Console in ESX (4309499).