Wednesday, June 24, 2009

Configuring VNC to auto-start

How to auto start VNC server in Red Hat Linux after system reboot?

My testing environment is a machine running on Red Hat Enterprise Linux 4 Update 4, with the bundled VNC Server (i.e. vnc-server-4.0-8.1). Also assume that a Linux user account called “walker” needs the VNC server to start up automatically when Linux boots up.

  1. The Linux user account that needs VNC server to automatically start up after system reboot, must have a VNC password. To create a new (or reset a forgotten) VNC password, just login or su (switch user) with that Linux user account and execute this simple command:

    Enter a password when prompted, which is used for VNC authentication.
  2. A hidden directory named .vnc is created in the user home directory by the vncpasswd command (if it’s not current exists). Execute ls -la $HOME/.vnc command to check if there is a file called xstartup. If this file is not exists, bring up VNC server with another simple command:
    vncserver :1

    If you get this similar message “A VNC server is already running as :1″, meaning that there is another instance of VNC server running with the same display number. To resolve this, just try to replace the :1 with :2, :3, etc. Alternatively, you may execute this netstat command with root user privilege:
    [root@walkernews ~]# netstat -tulpan | grep vnc
    tcp    0    0*   LISTEN   3402/Xvnc
    tcp    0    0*   LISTEN   8447/Xvnc
    tcp    0    0*   LISTEN   3402/Xvnc
    tcp    0    0*   LISTEN   8447/Xvnc
    tcp    0    0*   LISTEN   3402/Xvnc
    tcp    0    0*   LISTEN   8447/Xvnc

    The netstat output shows that there are two VNC servers running with display number 1 and 2. So, for the 3rd VNC server to start, the command should be vncserver :3.
  3. Edit $HOME/.vnc/xstartup file with your favourite editor, to un-comment these two lines in order to get the “normal” Linux Desktop view:
    exec /etc/X11/xinit/xinitrc
  4. Switch user to root account (i.e. su - root), edit /etc/sysconfig/vncservers with your favourite editor, append the display number and Linux user account information to the VNCSERVERS (an array variable). This configuration file defines who can start up VNC server with what display number via the VNCSERVERS array (that’s read by Linux start up scripts /etc/init.d/vncserver). For example,
    VNCSERVERS="1:root 2:tester 3:walker"

    That means there are three Linux user accounts (root, tester, and walker) will start up VNC server with display number 1, 2, and 3 respecitively, as Linux boots up.

    Note: Don’t simply add more than one VNCSERVERS array in /etc/sysconfig/vncserver configuration file. Otherwise, only the last VNCSERVERS array will be used.
  5. Make sure VNC server (the daemon or server process) is set to auto run upon system boots up to your runlevel. For example,
    [root@walkernews ~]# chkconfig ––list | grep vnc
    vncserver  0:off  1:off  2:off  3:off  4:off  5:on  6:off

    The ––list option of chkconfig shows VNC server is set to auto run in Linux runlevel 5 (the default multi-user runlevel with Linux Desktop console). To configure VNC server to auto run when Linux boots into runlevel 5, use the ––level with on option switch:
    chkconfig --level 5 vncserver on

Ok, that’s all you need. You should have the VNC server automatically running when Red Hat Linux boots up at runlevel 5. Although the guide might looks lengthy to you, but works involve shouldn’t take you more than 3 minutes after you get used with Linux!

Creating NFS datastores on a VMware cluster

The one issue I have seen so far with VMware storage is with regards to NFS datastores; they have to be configured onto each node in the cluster individually. Since this is done manually, it can be prone to error, so I started using the following powershell commands to perform it on all the hosts in a cluster.

foreach ($ESXhost in get-cluster clustername| get-vmhost)
New-datastore –nfs –vmhost $ESXhost –name datastorename –path /export/share –nfshost servername

Simply replace the clustername, datastorename, /export/share and servername with the appropriate values and run it in the VI Toolkit Powershell extension

Tuesday, June 16, 2009

VMware treadmill process

In my VMware environment I have several VMs that have very large VMDKs, but are only using a small portion of that space. These are referred to as "THICK" disks. I would like to reclaim that unused space and turn them into "THIN" disks, which means I need some kind of a treadmill process to thin them out.

Various googling shows some examples of using VMKFSTOOLS to clone the disk into a thin provisioned copy, delete the source, then rename the new disk to replace the original. But this misses 2 key requirements: 1) Ensuring the system is offline before starting, 2) Performing the task on all available systems at once. For this, we need a couple other steps.

Identifying offline systems and VMDKs
Using the VI Toolkit powershell extension, I can run the following command on a single line
get-vm | where {$_.PowerState -eq 'PoweredOff'} | get-harddisk | export-csv d:\temp\foo.csv
This exports all the systems and drives into a CSV file that can be opened in Excel and massaged as necessary. Change the path name from [Datastore] /path to /vmfs/volumes/datastore/path.

Creating a script to thin out the disks
Now we need a script that will put a specified disk on the treadmil.


if [ ! -n "$1" ]
echo "Usage: `basename $0` vmdkpath"

echo "Copying file $1"
vmkfstools -i $1 $1.thin -d thin
echo "Deleting file $1"
vmkfstools -U $1
echo "Renaming file $1"
vmkfstools -E $1.thin $1
exit 0

Using VI, save this file to the VMware host (i.e. putty into the host, create the file and save the contents). Use chmod +x treadmill to mark the file as an executable. Now all that remains is to queue up the disks to change.

Open notepad and paste in all the paths from the Excel spreadsheet. At the beginning of each line, add a call to the treadmill script so that it looks like the following
./treadmill /vmfs/volumes/datastore1/server1/server1.vmdk
Once all the lines look like this, simply copy and paste them into your existing putty session. This will go through each VMDK, create a thin copy, delete the original, and rename the new to the original. This could take a long time depending on the size and number of disks

Monday, June 15, 2009

VMware "unable to access a file since it is locked"

Ran into an unusual problem with my VMware farm, when trying to power on a system I get the error "Unable to access a file since it is locked".

A quick look on the web brings up
The first two options are somewhat expected (the file is locked by something else). In my case the third option resolved the issue for me, I recreated the VMX and everything is good.