Posts Tagged ‘Linux’

Service Console Directory Listing Text Color in PuTTY

January 25th, 2010

Curious about the default colors you see in a remote PuTTY session connected to the ESX Service Console?  Some are obvious such as the directory listings which show up as blue text on a black background.  Another obvious one is the compressed .tar.gz file which will show up in a nicely contrasting red text on black background.  Or how about this one which I’m sure you’ve seen, executable scripts are shown as green text on a black background.  You might be asking yourself “What about the oddball ones I see from time to time which don’t have an explanation?”  I’ve provided an example in the screenshot – a folder named isos shows up with a green background and blue text.  What does that mean? 

There’s a way to find out.  While in the remote PuTTY session connected to the ESX Service Console, run the command dircolors -p from any directory.  Here’s the default legend:

# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
NORMAL 00 # global default, although everything should be something.
FILE 00 # normal file
DIR 01;34 # directory
LINK 01;36 # symbolic link. (If you set this to ‘target’ instead of a
 # numerical value, the color is as for the file pointed to.)
FIFO 40;33 # pipe
SOCK 01;35 # socket
DOOR 01;35 # door
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 40;31;01 # symlink to nonexistent file
SETUID 37;41 # file that is setuid (u+s)
SETGID 30;43 # file that is setgid (g+s)
STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 01;32
# List any file extensions like ‘.gz’ or ‘.tar’ that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a ‘#’)
# If you use DOS-style suffixes, you may want to uncomment the following:
#.cmd 01;32 # executables (bright green)
#.exe 01;32
#.com 01;32
#.btm 01;32
#.bat 01;32
.tar 01;31 # archives or compressed (bright red)
.tgz 01;31
.arj 01;31
.taz 01;31
.lzh 01;31
.zip 01;31
.z 01;31
.Z 01;31
.gz 01;31
.bz2 01;31
.deb 01;31
.rpm 01;31
.jar 01;31
# image formats
.jpg 01;35
.jpeg 01;35
.gif 01;35
.bmp 01;35
.pbm 01;35
.pgm 01;35
.ppm 01;35
.tga 01;35
.xbm 01;35
.xpm 01;35
.tif 01;35
.tiff 01;35
.png 01;35
.mov 01;35
.mpg 01;35
.mpeg 01;35
.avi 01;35
.fli 01;35
.gl 01;35
.dl 01;35
.xcf 01;35
.xwd 01;35
# audio formats
.flac 01;35
.mp3 01;35
.mpc 01;35
.ogg 01;35
.wav 01;35

 

Applied to the screenshot example above, the legend tells us that the isos directory is: OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky.

Another color you may commonly see which I haven’t yet mentioned is cyan which identifies symbolic links.  These can be found in several directories.  Most often you will see symbolic links in /vmfs/volumes/ connecting a friendly datastore name with it’s not so friendly volume name which is better known by the VMkernel.

That’s it. Not what I would considering Earth shattering material here, but maybe you’ve seen these colors before and haven’t connected the dots on their meaning.  For people with Linux background, this is probably old hat.

VMware ESX Guest OS I/O Timeout Settings (for NetApp Storage Systems)

October 29th, 2009

You may already be aware that installing VMware Tools in a Windows VM configures a registry value which controls the I/O timeout for all Windows disk in the event of a short storage outage. This is to help the guest operating system survive high latency or temporary outage conditions such as SAN path failover or maybe a network failure in Ethernet based storage.  VMware Tools changes the Windows default value of 10 seconds for non-cluster nodes, 20 seconds for cluster nodes, to 60 seconds (or x03c hex).

Did you know that disk I/O timeout is a configurable parameter in other guest operating systems as well? And why not, it makes sense that we would want every guest OS to be able to outlast a storage deficiency.

NetApp offers a document titled VMware ESX Guest OS I/O Timeout Settings for NetApp Storage Systems. It’s published as kb41511 and you’ll need a free NetApp NOW account to access the document. This white paper serves a few useful purposes:

  • Defines recommended disk I/O timeout settings for various guest operating systems on NetApp storage systems
  • Defines benchmark disk I/O timeout settings for various guest operating systems which could be used on any storage system, including local SCSI
  • In some cases provides scripts to make the necessary changes
  • Explains the methods to make the disk I/O timeout changes on the following guest operating systems:
    • RHEL4
    • RHEL5
    • SLES9
    • SLES10
    • Solaris 10
    • Windows

Now on the subject disk I/O timeouts, understand the above is to be used as chance for extending the uptime of a VM during adverse storage conditions. As in life, there are no guarantees. A guest OS with high disk I/O activity may not be able to tolerate sustained read and/or write requests for the duration of the timeout value. Windows guests may freeze or BSOD. Linux guests may go read-only on their root volumes which requires a reboot. Which brings me to the next point…

A larger timeout value isn’t necessarily better. In extending disk I/O timeout values, we’re applying virtual duct tape to an underlying storage issue which needs further looking into. Given the complex and wide variety of shared storage systems available to the datacenter today, storage issues can be caused by many variables including but not limited to disks (spindles), target controllers, fabric components such as fibre cables, SFP/GBICs, HBAs, fabric switches, zoning, network components such as copper cabling, NICs, network switches, routers, and firewalls. Also keep in mind that while the OS may survive the disk I/O interruption, application(s) running on the OS platform may not.  Applications themselves implement response timeout values which are likely going to be hard coded and non-configurable by a platform or virtualization administrator in the application itself.

Lastly, try to remember that if you go through the effort of increasing your disk I/O timeout values on Windows guests beyond 60 seconds, future installation of VMware Tools or other applications/updates may reset the disk I/O timeout back to 60 seconds.  What this means is that in medium to large environments, you’re going to need an automated method to deploy custom disk I/O timeout values at least for Windows guests.  For those with NetApp storage, NetApp pushes these standards firmly, along with other VMware best practices which I’ll save for a future blog article.

Update 4/28/10:  VMware Tools for vSphere installation doesn’t change the disk timeout setting if a custom value was previously set (ie. 190 seconds)

Update 9/12/11:  See also VMware KB article 1009465 Increasing the disk timeout values for a Linux 2.6 virtual machine

Access a CD/DVD from the ESX console

December 17th, 2008

If by chance you need to access the CD/DVD ROM tray on your ESX host from the service console (COS), it is not as straight forward as clicking on the cup holder icon under “My Computer”.  The media needs to be mounted in the RHEL based service console operating system first.  This blog entry explains how.

1.  Determine which device represents the tray holding the media you want to mount using the command ll /dev |grep cdrom. In this case on a Dell PER900, I see two CD/DVD ROM instances.  /dev/hda represents the physical tray on the ESX host.  /dev/scd0 represents the virtual .iso media connected via the DRAC:

12-17-2008 11-04-37 AM

2.  I want to mount the virtual .iso media represented by /dev/scd0.  The command is mount /dev/scd0 /mnt/cdrom.  As seen in the following example, once I have mounted the device, the CD/DVD media is now accessible at the /mnt/cdrom location.  In this case, it’s a Windows Server 2003 CD.  Why would I want to stick a Windows CD in an ESX host?  Perhaps I’d like to create an .iso image to be stored on a VMFS volume using the dd if=/mnt/cdrom of=/vmfs/volumes/vmfs_storage1/win2k3.iso command:

12-17-2008 11-03-39 AM

3.  When finished, don’t forget to unmount the media.  The command for this is umount /mnt/cdrom.  Notice the media cannot be unmounted when someone or something is presently accessing the media directory structure (as indicated by the “device is busy” error message on the first unmount attempt):

12-17-2008 11-07-50 AM

He sed / she sed

November 14th, 2008

Sed (Stream EDitor) is a powerful Unix and Linux utility which has the ability to parse text files and make changes.  It’s practically a gold mine for scripting.  Fortunately, this utility has been part of the modified Red Hat Enterprise Linux service console (COS) in VMware ESX current and previous versions.  Used in my deployment scripts, it serves me well for the purposes of rapidly standing up new or rebuilding existing ESX hosts.

Admittedly, I don’t have a real strong Linux background.  My foundation has been primarily Microsoft Windows, and before Windows, Microsoft DOS and Commodore 64/VIC-20 BASIC programming which actually did provide me a nice basis for command line going forward.  When I began building ESX hosts, I soon discovered scripting was where it’s at for efficiency and more imporantly consistency.  I learned the use of sed by borrowing snippets of example code available on the internet and VMware Community forums.  By the way, the sed rabbit hole goes very deep.  I’ve only learned the find/replace function of it to get me by for ESX scripting which is just the tip of the iceberg.

I learned something about sed recently that probably would have helped me during my learning process of sed a while back.  The majority of sed examples found on the internet (and probably in the man pages) use a forward slash / as the delimiter.  This is because the / is natively used in ed, more, and vi.  What I discovered is that any character can actually be used as a delimiter.  This would have been helpful for me to know earlier because some of the scripting I do involves Linux paths which of course make use of the forward slash.  Adding an additional forward slash for sed scripting made for an awful lot of forward slashes in one line and at times made my eyes hurt.  Similar to building a complex Microsoft Excel formula whith a lot of parentheses and trying to keep track of the number of open parens versus the number of close parens. 

Let me show a few examples and maybe you can see what I’m talking about.

Here’s one line of an actual script I use to add the full path display in the COS (there are three / delimiters in this example, see if you can find them):

sed -e “s/\\h \\\W/\\h \\\w/g” /etc/bashrc.old > /etc/bashrc

Forward and backwards slashes that butt up against each other are commonly reffered to as “the picket fence effect”.  In the example above, for my sanity I could have chosen a different delimiter, such as an underscore, so that the script looked like this instead:

sed -e “s_\\h \\\W_\\h \\\w_g” /etc/bashrc.old > /etc/bashrc

Here’s another example which prevents the VMFS2 module from loading at startup on ESX3 hosts:

sed -e “s/echo \”vmfs2 vmfs2\”/\#echo \”vmfs2 vmfs2\”/g” /etc/init.d/vmware.old > /etc/init.d/vmware

More picket fence, not quite as bad though.  Maybe this time I use use the asterisk as a delimiter so that it looks like this instead:

sed -e “s*echo \”vmfs2 vmfs2\”*\#echo \”vmfs2 vmfs2\”*g” /etc/init.d/vmware.old > /etc/init.d/vmware

So it boils down to choosing the right sed delimiter for the line of code you’re working with.  Kind of like choosing the right bottle of wine for your meal, and choosing the right cigar for afterwards.

I’ve always said that much of the fun of this career I have chosen is the opportunity to learn something new every day and put it to practical use.  Today has been no exception.  Some days are more fun to learn than others.  It depends on the conditions and circumstances…