Wednesday, September 19, 2012

VMWARE Troubleshooting Disk and Datastore Related Issues FAQ-Part2

Virtual Machine Clock Reports Time Unpredictably on Multiprocessor Systems
Details

The clocks in my virtual machines run in an unpredictable manner. Sometimes they run too quickly, other times they run too slowly, and sometimes they just stop. What is happening?
Solution

If you are running VMware desktop virtualization products on a multiprocessor system in which the timestamp counters (TSCs) do not remain synchronized between all processors, the operating system clock in each virtual machine can perform unpredictably. In this context, "multiprocessor" includes systems with multiple cores but only one processor socket.

This problem can occur on some 64-bit AMD systems and on some Intel systems. See the relevant information described in the following sections:

64-bit AMD Systems    Intel Systems
64-bit AMD Systems

This problem can occur on some 64-bit AMD multiprocessor (including multicore) systems. If you run VMware products on one of these systems and the clocks in your virtual machines are performing unpredictably, VMware recommends you apply the workaround described below.

Timestamp counters (TSCs) on 64-bit AMD systems should ideally remain synchronized because these systems run all CPUs from a common clock oscillator. However, some 64-bit AMD systems have power management features that can cause the TSCs on some processor cores to lose time in relation to other cores.

You might be able to disable these features:

In your system's BIOS setup windows, look for settings labeled PowerNow or Cool'N'Quiet, and disable them.

If you are running a Linux host operating system, look for a system daemon or applet called cpufreqd, cpuspeed, powernowd, cpudyn, speedy, or cpufreq, and disable it. For example, on some systems the command service cpuspeed stop might work. The instructions to disable the daemon or applet found on your system vary. Refer to your system's documentation for more information.

If you require these features or you cannot find a way to disable them, you need to assign each of your virtual machines to a subset of processor cores on which the TSCs do remain synchronized. In some cases you may need to do this even after turning off power management in your system's BIOS; this occurs if your system only partially disables the power management features involved. See http://kb.vmware.com/kb/2039 for more information.

How to Run VMware Hosted Products on Systems on Which TSCs Are Not in Sync Details

How can I work around problems on multiprocessor systems on which the timestamp counters do not stay in sync, such as IBM x-Series systems and some 64-bit AMD systems?
Solution

You must perform two actions.

Disable a feature in some versions of VMware products that attempts to resynchronize the TSCs whenever a virtual machine is started. See the section Avoiding Forced TSC Resynchronization, below.

Assign each virtual machine to a subset of processors whose TSCs are synchronized with each other. See the section Assigning a Virtual Machine to Processors with Synchronized TSCs, below.

Avoiding Forced TSC Resynchronization

On a Windows host operating system, you may encounter a problem with unwanted resynchronization of timestamp counters (TSCs) when a virtual machine starts. The workaround is to add the following line to your global configuration file:

host.TSC.noForceSync = TRUE

The global configuration file is normally found at:

C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini for VMware Workstation

C:\Documents and Settings\All Users\Application Data\VMware\VMware GSX Server\config.ini for GSX Server If this file does not exist, see http://kb.vmware.com/kb/1754.
====================================
Creating and editing config.ini on Windows Hosts

Details

Some knowledge base articles tell me to edit the config.ini file, but I can't find it. Where is it? How do I create it if it doesn't exist? <br style=""> <br style="">
Solution

The config.ini file may not exist if you have not changed the default configuration setting from the Edit > Preferences menu.

To see if the file already exists, look for it at C:\Documents and Settings\All Users\Application Data\VMware\VMware ProductName, where VMware ProductName is the name of the product you are using.
Notes:

Make sure you are looking on the Windows host on which you have installed the VMware software. You should not look for this file in your virtual machine.On Vista and newer versions of Windows, look for the file at C:\Program Data\VMWare\<VMWare Product>\Config.ini

Note: On Vista and Windows 7 type systems, the C:\Program Data\VMware\<VMware Product>\ folder is normally hidden by default. You will need to go to Control Panel >> Appearance and Personalization >> Folder Options >> Show hidden files and folders, and then check the "Show hidden files, folders and drives" radio button in order to make this folder viewable/accessible.

To create the file if it does not exist, do one of the following: Create a new, empty text file named config.ini in the location above.

Caution: Use a text editor like Notepad. Do not use Word or Wordpad, because these editors create extra characters in the text file that render the configuration settings that you add unreadable.
Make a configuration change from the menu.

From the Edit menu of your virtual machine, choose Preferences > Memory. Note the current value that appears for Reserved Memory.

Enter a new value for Reserved Memory and click OK. Confirm that a config.ini file now exists in the location above.
Repeat steps 1-3 and change Reserved Memory back to its original value.

Note (8/15/07): "Avoiding Forced TSC Resynchronization" is no longer necessary for current versions of VMware products, because the default value for that option is now TRUE. But it doesn't hurt if you have added the option explicitly.

Assigning a Virtual Machine to Processors with Synchronized TSCs

When a system has processors that have timestamp counters which are not all synchronized, the host operating system may move a virtual machine between two processors on which the timestamp counters are out of sync. This can cause the virtual machine clock to perform unpredictably. The clock may run too quickly or too slowly, or may even stop at times.

On an affected IBM x-Series system or its derivatives, each NUMA node (or CEC, in IBM terminology) has processors whose TSCs are synchronized with each other, but the TSCs of different NUMA nodes are not synchronized. So this issue can be solved by assigning each virtual machine to run only on the processors of a single NUMA node.

On affected 64-bit AMD systems, depending on which power management features are in use, every processor core's TSC may be out of sync with the others. (In other cases, the two cores in each dual-core processor may remain in sync.) If disabling power management does not solve this issue for you, it is safest to assign each virtual machine to only one processor core.

The details of how to assign a virtual machine to a subset of processors depend upon whether you are running GSX Server 3.2 or Workstation 5.5, or an earlier version of GSX Server or Workstation.

For Virtual Machines Running on a GSX Server 3.2, VMware Server 1.0, or Workstation 5.5 Host (or later versions)

These VMware products assign each virtual machine to a single NUMA node on an x440-class server running one of the following host operating systems:

Windows Server 2003 Any Linux 2.6.x kernel

Linux 2.4.21 or later kernel

When you power on a virtual machine, the VMware software by default assigns it to a NUMA node at random. You can configure a virtual machine to run on a specific NUMA node if you prefer.

To assign a virtual machine to a specific NUMA node, complete the following steps. Make sure the virtual machine is powered off.
In a text editor, open the virtual machine's configuration file (.vmx file).
Look for a line that starts with processors.NUMAnode =. If the line does not exist, add it.

Change or set the value after the equal sign ( = ) to the number of the desired NUMA node. Put the value in quotation marks. For example, to assign the virtual machine to NUMA node 2, add the following line to its configuration file:
processors.NUMAnode = "2"

To return this virtual machine to the default behavior, in which the VMware software assigns the virtual machine to a NUMA node at random, complete the following steps.
Make sure the virtual machine is powered off.

In a text editor, open the virtual machine's configuration file (.vmx file). Delete the line that starts with processors.NUMAnode =.

Also delete any lines that start with processor<n>.use (where <n> is any number). These lines may be present if you previously applied the older workaround from GSX Server 3.1 and earlier or Workstation 5.0 and earlier, as described below.

In general, do not use the processor<n>.use option described below together with the processors.NUMAnode option. If both options are present in the configuration file, any processor<n>.use options are ignored.

If you are using GSX Server, VMware Server, or Workstation on a 64-bit AMD multiprocessor system, the VMware product does not assign each virtual machine to a subset of processor cores by default. If you need this assignment to be done on your 64-bit AMD system, choose a specific processor core to which to assign each virtual machine, using the processor<n>.use options as described in the next section.

For Virtual Machines Running on a Workstation 5.0 or Earlier Host, or on a GSX Server 3.1 or Earlier Host

To work around this problem for systems running on Workstation 5.0 or earlier, or GSX Server 3.1 or earlier, choose one NUMA node for each virtual machine and associate the virtual machine with the processors in that NUMA node. You can associate different virtual machines with different NUMA nodes; just make sure you do not allow any single virtual machine to run on multiple NUMA nodes. To associate a virtual machine with the processors in one NUMA node, complete the following steps.
Make sure the virtual machine is powered off.

In a text editor, open the virtual machine's configuration file (.vmx file).

Add the following line for each processor with which you do not want to associate the virtual machine (where <n> is the number of the processor on the host):

processor<n>.use = FALSE

For example, you have an eight-processor host with processors 0 through 3 on NUMA node 0 and processors 4 through 7 on NUMA node 1, and there are two virtual machines on the host. To associate the first virtual machine with NUMA node 0, add the following lines to that virtual machine's configuration file: processor4.use = FALSE

processor5.use = FALSE processor6.use = FALSE processor7.use = FALSE

To associate the second virtual machine with NUMA node 1, add the following lines to that virtual machine's configuration file:

processor0.use = FALSE processor1.use = FALSE processor2.use = FALSE processor3.use = FALSE

If your host has four processors, they may either be located all in one NUMA node or be split between two NUMA nodes. If all the processors are located on the same NUMA node, this problem does not occur. If the processors are split between two NUMA nodes, add the following lines to the virtual machine's configuration file to associate it with NUMA node 0:

processor2.use = FALSE processor3.use = FALSE

Then add the following lines to the virtual machine's configuration file to associate it with NUMA node 1: processor0.use = FALSE
processor1.use = FALSE

Caution: On a Linux host, GSX Server 3.1 (and earlier) and Workstation 5.0 (and earlier) do not honor the processor<n>.use option. You should not run GSX Server 3.1 and earlier, or Workstation 5.0 and earlier, at all on a machine that uses Linux as the host operating system and that has multiple NUMA nodes on which the TSCs are not synchronized. You need to upgrade to GSX Server 3.2 or Workstation 5.5.

Caution: The above examples assume that the GSX Server or Workstation host does not have hyperthreading enabled for its processors. For information about how hyperthreading affects which processors a virtual machine uses, read the next section.

How Hyperthreading Affects the Way in Which a Virtual Machine Is Associated with a Processor in a NUMA Node

When you enable hyperthreading on a host, the processor<n>.use option associates the virtual machine with CPU <n>, which is now a logical processor.

Continuing with the example above, if you enable hyperthreading on an eight-processor host with two NUMA nodes, and you want to associate a virtual machine with NUMA node 0, add the following lines to that virtual machine's configuration file:

processor4.use = FALSE processor5.use = FALSE processor6.use = FALSE processor7.use = FALSE processor12.use = FALSE processor13.use = FALSE processor14.use = FALSE processor15.use = FALSE

When hyperthreading is enabled, an eight-processor Windows host has sixteen logical processors, numbered as follows:

Physical CPU 0: logical CPU 0, 8 Physical CPU 1: logical CPU 1, 9 Physical CPU 2: logical CPU 2, 10 Physical CPU 3: logical CPU 3, 11 Physical CPU 4: logical CPU 4, 12 Physical CPU 5: logical CPU 5, 13 Physical CPU 6: logical CPU 6, 14 Physical CPU 7: logical CPU 7, 15

Each NUMA node includes the following logical processors: NUMA node 0 includes logical CPUs 0, 1, 2, 3, 8, 9, 10, 11 NUMA node 1 includes logical CPUs 4, 5, 6, 7, 12, 13, 14, 15

In enabling or disabling hyperthreading, use caution when associating virtual machines with processors. When you enable hyperthreading on the host, you should modify each virtual machine's configuration file to account for all the logical processors on the host.

However, disabling hyperthreading does not require you to modify the virtual machines' configuration files, as long as you do not make hardware changes to the host (such as adding or removing NUMA nodes or physical processors, or moving processors between NUMA nodes). GSX Server and Workstation ignore any processor<n>.use option where <n> is greater than the highest numbered processor available to the host operating system. Thus, with hyperthreading disabled, the options that you added for the first hyperthread on each physical processor (CPUs 0 through 7 above) now apply to the physical processor itself, while those you added for the second hyperthread (CPUs 8 through 15) are now ignored.

Caution: You must consider the change to the CPU numbering scheme when you add or remove NUMA nodes or physical processors to or from the host. With hyperthreading enabled, the number for each second logical processor changes when you add or remove a NUMA node or physical processor. Adding or removing a NUMA node or physical processor to or from a host requires you to re-associate virtual machines with the correct processors on each NUMA node.
    29

Note: Knowledge base articles 2039, 2040, and 2041 replace knowledge base article 1236.

Note: If you are running Windows XP Service Pack 2 as the host operating system on a multiprocessor 64-bit AMD host that supports processor power management features, you also need to apply the hotfix described in Microsoft knowledge base article 896256 at http://support.microsoft.com/?id=896256. According to this Microsoft knowledge base article, the hotfix is needed for the following operating systems:

Microsoft Windows Server 2003, Standard and Enterprise x64 Editions

Microsoft Windows XP Service Pack 2, when used with Microsoft Windows XP Home and Professional Editions Microsoft Windows XP Tablet PC Edition 2005
No hotfix is needed for Microsoft XP Media Center.
Note: VMware knowledge base articles 2039, 2040, and 2041 replace knowledge base article 1236.

Intel Systems

This problem can occur on some Intel multiprocessor (including multicore) systems. After a Windows host performs a "stand by" or "hibernation", the TSCs may be unsynchronized between cores.

The hotfix described in Microsoft knowledge base article 896256 addresses this issue. See http://support.microsoft.com/kb/896256.

9. Confirm that the networking drivers installed in the virtual machine are the performance optimized drivers, or match the networking mode set on the host for that virtual machine. Typically, installing VMware Tools installs the correct network drivers.

10. Verify that host networking issues are not impacting the performance of the virtual machine. For more information, see Verifying host networking speed (1009527).

Verifying host networking speed Symptoms

Applications running in virtual machines perform poorly It takes a long time to log into a network
It takes a long time to copy a file from a network share
Multi-user services have long transaction times or can handle less simultaneous users than expected
Purpose

This articles assists you in determining if a computer running a VMware hosted product is affected by slow networking. Slow host networking results in slow guest operating system networking.
Resolution

Evaluate these points for validity. A positive result may indicate a networking problem on the physical host that needs to be corrected to ensure optimum virtual machine performance.
If corrective action is taken on the host, test virtual machine networking performance again.

It takes longer to copy a file from a network location to this host than it does to copy the same file to a different host

Logging into a network from the host takes the same amount of time as it does when logging into the same network from the guest operating system

There are multiple virtual machines running on the host and they are all equally slow

Running an application that is slow when run from the guest operating system is just as slow when run on the host

The networking settings of host network adapters have been manually set to a speed or duplex lower than their capability
The firmware and driver versions for host network adapters are not current

There is a firewall, network shaping software, or network monitoring software on the host affecting network speed

There is software running on the host that makes extensive use of networking traffic, like a heavily used Web server or file share

11. Verify that the host operating system is working properly and is in a healthy state. When the host is not working correctly it may draw excessive resources from the guests. For more information, see Verifying the health of an operating system (1003956).

Verifying the health of an operating system

Symptoms
A guest or host operating system:
Has stopped responding and displayed a blue screen with a stop code

Has experienced a core dump Has experienced a kernel panic Has stopped responding

Keeps rebooting for no apparent reason Has performance problems
Is slow

Has an application that is not working properly Is experiencing network problems
Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system or on a host computer where a VMware product is installed, are related to VMware. The steps outlined here eliminate the possibility that the problem is related to the operating system itself, to another application installed to the operating system, or to the physical hardware of the host computer.

Note: While this article addresses problems related to the guest operating system of a virtual machine running on an ESX Server host, it does not address problems related to the ESX Server host itself. For more information about ESX Server issues, see Verifying the health of an ESX Server operating system (1004019).


Resolution

A VMware product may behave unexpectedly if the operating system on which it is installed is experiencing problems. Follow the section that matches your operating system.

Note: If you perform a corrective action in any of the following steps, determine if the problems initially encountered are still being experienced.
Common Windows Problems

Verify there are no problems with the filesystem by performing a disk check on your hard drives. For more information, see Performing a disk check (1004003).

Performing a disk check Symptoms

VMware Workstation unrecoverable error: (vcpu-0) Exception 0xc0000006 (disk error while paging) has occurred.

Purpose

This article describes how to perform a disk check. This is required to address problems encountered with an operating system as a result of file system errors. Problems can include data loss, virtual machine crashes, slow performance, virtual machine resume and suspend failures, and other unexpected behaviour.

Resolution

Determine if there are problems with your file system by performing a disk check. A disk check can be done by using a 3rd party application or by using tools native to your operating system.

The method of performing a disk check differs between operating systems. Refer to the section below that matches your operating system.
Windows

Note: The exact procedure differs between versions of Windows. If one procedure below does not work try the other. If neither method works, consult the manual for your version of Windows.

To perform a disk check from the user interface: Double-click the My Computer icon. Right-click the entry for your local disk.

Click Properties. Click the Tools tab. Click Check Now.

Select Scan for and attempt recovery of bad sectors. Click Start.
To perform a disk check from a command line:

Open a command prompt. For more information, see Opening a command or shell prompt (1003892). Type chkdsk c: /r and press Enter.
Note: If the local disk being scanned is not c: , replace c: with its drive letter.

Note: A scan of the system drive requires that the operating system be rebooted.
Linux

Note: The exact procedure may differ between distributions of Linux. If the following commands do not work for you, consult the manual for your distribution of Linux. The following commands may also fail if you are not logged in as a user with root access.

Open a shell prompt. For more information, see Opening a command or shell prompt (1003892). Type touch /forcefsck and press Enter.
Type shutdown -r now and press Enter.
Note: Issuing the shutdown command restarts your operating system.
Mac OS

To perform a disk check: Press Shift + Command + U. Double-click Disk Utility.

Click the entry for the disk or volume to check. Click Verify Disk.

Note: You cannot use this utility to verify the integrity of the startup volume. Instead, use Safe Boot. For more information, see Using Safe Boot (1004017).

Note: You can also click on Verify Disk Permissions to confirm that there are no problems being experienced due to incorrect permissions. If you find that there are permission problems, they can be corrected by clicking on Repair Disk Partitions.

2. Verify that there is no disk fragmentation on your hard drive. For more information, see Defragmenting a disk (1004004).


De fragmenting a disk Purpose

This article describes how to defragment a disk. Defragmenting a disk is required to address problems encountered with an operating system as a result of file system fragmentation. Fragmentation problems result in slow operating system performance.

Resolution
Determine if fragmentation of your file system is causing problems by defragmenting.

Note: Linux file systems do not require disk defragmentation and Mac OS performs disk defragmentation as required. To manually defragment a disk in either of these operating systems, a 3rd party application is required.
Defragmenting a disk under Windows

This can be done by using a 3rd party application or by using tools native to Windows. If you have more than one hard drive, perform the defragmentation on each hard drive.

Note: The exact procedure differs between versions of Windows. If one procedure does not work, try the other. If both do not work, consult the manual for your version of Windows.

To defragment a disk from the user interface: Double-click the My Computer icon. Right-click the entry for your local disk. Click Properties.

Click the Tools tab. Click Defragment Now. Click Defragment.

To defragment a disk from a command line:

Open a command prompt. For more information, see Opening a command or shell prompt (1003892). Type defrag c: and press Enter.

Note: If the local disk being defragmented is not c: , replace c: with its drive letter. 3. Check if there are sufficient resources in the following areas:
Memory

For more information, see Investigating operating system memory usage (1004014). Disk
For more information, see Investigating operating system disk space (1004007).

CPU
For more information, see Investigating operating system CPU usage (1004016).

Note: If your operating system is installed to a virtual machine, and you have determined that there are insufficient resources, you need to increase the resource that is lacking:
Memory

For more information, see Increasing the amount of memory assigned to a virtual machine (1004059). Disk

For more information, see Increasing the size of a virtual disk (1004047). CPU

If this is a virtual machine running under an ESX Server host, see Increasing the amount of CPU assigned to a virtual machine (1004060).

Note: If this is a virtual machine running under any other product, there is no direct way of increasing the amount of assigned CPU. If your host has multiple CPUs or CPU cores, it is possible to set processor affinity among virtual machines so that one or more CPUs are not used by any other virtual machine. For more information, see Associating a Virtual Machine With a Particular Host Processor (110). Alternatively, the host hardware must be upgraded or the virtual machine moved to a different host.

4.If a virtual machine with multiple CPUs is performing poorly, see Determining if multiple virtual CPUs are causing performance issues (1005362).

Determining if multiple virtual CPUs are causing performance issues Symptoms

You may experience these performance issues with a multiple CPU virtual machine running on an ESX host: Poor transfer speeds when copying data to or from a virtual machine

Backup jobs time out or are very slow A virtual machine performs poorly
Purpose
This article helps you determine if multiple virtual CPUs (vCPUs) are causing performance issues.
Resolution

To determine if multiple vCPUs assigned to your virtual machine is causing poor performance:

Open a console prompt on the ESX host or initiate an SSH connection to it. For more information, see Opening a command or shell prompt (1003892).

Type esxtop and press Enter.

On the CPU screen, check the %CSTP value. If this number is higher than 100, the performance issues may be caused by the vCPU count. Try lowering the vCPU count of the virtual machine by 1.

Note: The %CSTP value represents the amount of time a virtual machine with multiple virtual CPUs is waiting to be scheduled on multiple cores on the physical host. The higher the value, the longer it waits and the worse its performance. Lowering the number of vCPUs reduces the scheduling wait time.

To lower the vCPU count:

Note: The virtual machine must be powered off to perform these steps. Right-click on the virtual machine and click Edit Settings.
Click CPUs.

Use the Number of virtual processor drop-down to lower the vCPU count by 1. Click OK.

If your virtual machine still experiences performance issues, and if its kernel or HAL can handle switching to a single vCPU, lower the vCPU count to 1.

Warning: If your virtual machine's kernel or HAL cannot handle switching to a single vCPU, unexpected behaviour may occur.

5.Confirm that there is no virus compromising the operating system. For more information, see Detecting viruses (1004008).

Detecting viruses
Symptoms
A guest or host operating system:

Stops responding.
Keeps rebooting for no apparent reason.
Has performance problems.
Is slow.

Has an application that isn’t working properly. Has applications that keep closing.
Has network problems.
Experiences excessive disk access for no apparent reason.
Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system, or on a host computer where a VMware product is installed, are related to a virus infection.
Resolution

If an operating system is suddenly behaving unexpectedly it may be because of a virus. VMware recommends that a virus scan be performed to confirm a virus infection as the cause of this behaviour.

VMware does not provide a virus scanner. You must obtain from a virus scanner from the operating system vendor or through a third party application. Examples of third party utilities include

Confirm that there is no spyware interfering with the operating system. For more information, see Detecting spyware (1004009).

A guest or host operating system: Stops responding.

Has performance problems. Is slow.

Has an application that isn’t working properly.

Has browser pop-ups or application windows appear randomly. Has network problems.
Experiences excessive disk access for no apparent reason.

Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system or on a host computer where a VMware product is installed, are related to spyware.
Resolution

Note: Having some Spyware removal software installed can cause unpredictable connectivity issues in some environments.

If an operating system is suddenly behaving unexpectedly it may be because of spyware. VMware recommends that a spyware scan be performed to confirm spyware as the cause of this behaviour.

VMware does not provide a spyware scanner. Spyware scanners must be obtained from the operating system vendor or through a third party utility.

Use the Windows System Configuration (msconfig) utility to eliminate software and processes as possible causes. For more information, see Using the Windows System Configuration utility (1004010).

Note: Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

A guest or host operating system: Fails
Stops responding

Stops responding and displays a blue screen with a stop code Keeps rebooting for no apparent reason

Has performance problems Performs slowly

Has applications that are not working properly Is experiencing network problems
Purpose

This article describes how to use the Window's System Configuration utility. The Windows System Configuration utility helps determine if a service or application being loaded into Windows is causing unexpected operating system behaviour. This utility allows services and applications to be selectively disabled. If the unexpected behaviour stops after disabling a service or application then the source of the problem is identified. <br style=""> <br style="">

Resolution
To launch the Windows System Configuration utility:
Note: Not all versions of Windows include this utility. If you have a version of Windows where the following
procedure does not work, you must use a third party utility to selectively disable services and applications. Windows 2000 does not include this utility, but you can use the version that comes with Windows XP. Locate a Windows XP computer and copy the file msconfig.exe from the C:\WINDOWS\pchealth\helpctr\binaries directory to the Windows 2000 computer.

Click Start > Run.
Type msconfig and click OK.

To use the Window's System Configuration utility to disable services and applications: Click the Services tab.

Click Hide all Microsoft services. Click Disable all.

Click OK.
Reboot the computer.

If the issue no longer occurs, it is likely that one of the service or startup applications was the source of the problem. To selectively disable individual services from the Window's System Configuration utility select or deselect each service from the Services tab. To selectively disable individual startup applications, select or deselect each application from the Applications tab.

Note: Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

8. Boot into Safe Mode to eliminate software and processes as possible causes. For more information, see Booting into Safe Mode (1004011).

Booting into Safe Mode Symptoms

A guest or host Windows operating system: Has failed.

Has stopped responding and displayed a blue screen with a stop code. Has stopped responding.

Keeps rebooting for no apparent reason. Has performance problems.
Is slow.

Has an application that is not working properly. Is experiencing network problems.
Purpose

This article describes how to boot any version of a Windows operating system in Safe Mode. Safe Mode disables all third party applications and non-essential Windows services. If the symptoms are resolved when using Safe Mode then the source of the symptoms are related to a third party application or nonessential Windows service, not Windows itself.

Resolution

To boot any version of a Windows operating system in Safe Mode:

Caution: Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

Restart the operating system or power off and power on the computer. When the computer start, press and hold F8.

Note: You may see a series of messages that display information about hardware and memory. This is called POST information. If you see POST information, you do not need to press F8 until the screen goes black. Make sure the mouse focus is inside the virtual machine, by clicking inside the console window.

You are presented with a text menu of boot options.

Note: If you do not see this text menu and Windows boots normally, repeat steps 1-2. Select a safe mode and press enter.

If the operating system issues involve networking, select Safe Mode with Networking. If the operating system issues do not involve networking, select Safe Mode.

If the symptoms are resolved when using Safe Mode then the source of the symptoms are related to a third party application or nonessential Windows service, not Windows itself. You can try selectively disabling individual services and startup applications to narrow the cause of the problem. For more information, see Using the Windows System Configuration utility (1004010). If the problem reoccurs, you may have to investigate uninstalling third party software and Microsoft applications.

Note: Safe Mode eliminates more software and processes than the System Configuration utility, but it also further reduces operating system functionality. Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

9 .Confirm that the problem is not linked to your username by logging in as a different user. Additionally, verify that the problem is not linked to your username having or lacking administrator rights by logging in as a user whose rights are the opposite.

10. Verify that the memory on the host computer is healthy. For more information, see Validating host memory (1004012).

Validating host memory Symptoms

A guest or host operating system: Has failed

Has stopped responding and displays a blue screen with a stop code Has experienced a core dump

Has experienced a kernel panic Has stopped responding

Keeps rebooting for no apparent reason
Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system or on a host computer where a VMware product is installed are related to a memory problem on the physical host.

Note: This article does not address memory problems unique to an ESX host.
Resolution

VMwrae products may behave unexpectedly if there is a problem with the memory being used on the physical host computer.
To ensure that host memory is healthy:

Note: If you perform a corrective action in any of the following steps, determine if the problems initially encountered are still being experienced.
Ensure that the RAM in the host computer is seated correctly.

Note: The computer must be powered down and its case removed. Proper maintenance procedures based on the manual provided by the hardware vendor must be followed.

Verify that the memory has not been overclocked. Overclocking is the process of forcing a computer component to run at a higher clock rate than it was designed for by its manufacturer. Overclocking improves performance but may result in instability. VMware does not recommend overclocking.

Conform to memory compatibility guidelines provided by the server or system vendor. Where the server or system vendor does not provide specific guidance, or in the case of a user-assembled system, VMware recommends that all memory be from the same manufacturer to ensure compatibility and maximum stability. Run a memory diagnostic utility that was provided by the hardware vendor.

Run a third party memory diagnostic utility:

Note: This is required if the computer is a clone system or a computer where a memory diagnostic utility was not provided by the hardware vendor.

Note: VMware cannot endorse or recommend any particular third party utility, nor can it take responsibility for anything that may occur as a result of its use.

Note: This list is not meant to be exhaustive. Any inclusion or exclusion of a particular third party utility from this list is not an implicit or explicit indication of VMware's recommendation or lack of recommendation for that utility.

10. Verify that the hardware devices on the host computer are healthy and supported. For more information, see Performing hardware diagnostics (1004013).

Performing hardware diagnostics
Symptoms
A guest or host operating system:

Has failed
Has stopped responding and displayed a blue screen with a stop code
Has experienced a core dump
Has experienced a kernel panic Has stopped responding

Keeps rebooting for no apparent reason
Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system or on a host computer where a VMware product is installed, are related to a hardware problem on the physical host.

Note: This article does not address hardware problems unique to an ESX Server host.
Resolution

VMware may behave unexpectedly if there is a problem with the hardware being used on the physical host computer.
To ensure that host hardware is healthy:

Note: For more information about problems related specifically to memory, see Validating host memory (1004012).

Validating host memory Symptoms

A guest or host operating system: Has failed

Has stopped responding and displays a blue screen with a stop code Has experienced a core dump

Has experienced a kernel panic Has stopped responding
Keeps rebooting for no apparent reason

Purpose

This article guides you through the process of determining if problems encountered on a virtual machine's guest operating system or on a host computer where a VMware product is installed are related to a memory problem on the physical host.

Note: This article does not address memory problems unique to an ESX host.
Resolution

VMwrae products may behave unexpectedly if there is a problem with the memory being used on the physical host computer.
To ensure that host memory is healthy:

Note: If you perform a corrective action in any of the following steps, determine if the problems initially encountered are still being experienced. Ensure that the RAM in the host computer is seated correctly. Note: The computer must be powered down and its case removed. Proper maintenance procedures based on the manual provided by the hardware vendor must be followed.

Verify that the memory has not been overclocked. Overclocking is the process of forcing a computer component to run at a higher clock rate than it was designed for by its manufacturer. Overclocking improves performance but may result in instability. VMware does not recommend overclocking.

Conform to memory compatibility guidelines provided by the server or system vendor. Where the server or system vendor does not provide specific guidance, or in the case of a user-assembled system, VMware recommends that all memory be from the same manufacturer to ensure compatibility and maximum stability. Run a memory diagnostic utility that was provided by the hardware vendor.

Run a third party memory diagnostic utility:

Note: This is required if the computer is a clone system or a computer where a memory diagnostic utility was not provided by the hardware vendor.

Note: VMware cannot endorse or recommend any particular third party utility, nor can it take responsibility for anything that may occur as a result of its use.

Note: This list is not meant to be exhaustive. Any inclusion or exclusion of a particular third party utility from this list is not an implicit or explicit indication of VMware's recommendation or lack of recommendation for that utility.

Note: If you perform a corrective action in any of the following steps, determine if the problems initially encountered are still being experienced.
Ensure that all of the components are seated and attached correctly.

Note: The computer must be powered down and its case removed. Proper maintenance procedures based on the manual provided by the hardware vendor must be followed.

Verify that none of the components have been overclocked. Overclocking is the process of forcing a computer component to run at a higher clock rate than it was designed for by its manufacturer. Overclocking improves performance but may result in instability. VMware does not recommend overclocking.

Run a diagnostic utility that was provided by the hardware vendor. Run a third party diagnostic utility.

Note: This is required if the computer is a clone system or a computer where a diagnostic utility was not provided by the hardware vendor.

Note: VMware cannot endorse or recommend any particular third party utility, nor can it take responsibility for anything that may not occur as a result of its use.

Note: This list is not meant to be exhaustive. Any inclusion or exclusion of a particular third party utility from this list is not an implicit or explicit indication of VMware's recommendation or lack of recommendation for that utility.

CheckIt Diagnostics http://www.smithmicro.com/default.tpl?group=product_full&sku=CKDWINEE


DIAG

http://www.diagnoseprogramm.de/indexe.htm

EVEREST
http://www.lavalys.com/

Fresh Diagnose

http://www.pc-certified.com/

Sandra

http://www.sisoftware.net/

Test My Hardware

http://www.testmyhardware.com/

TuffTEST
http://tufftest.com/

Ultra-X QuickTechPRO

http://www.uxd.com/qtpro.shtml

—11. If the operating system having the problem has been installed to a virtual machine, power on the virtual machine from a different host. If the problem continues, the issue is with the virtual machine itself. Continue to step 11. If the problem disappears, the issue is with the original host. Repeat steps 1-11 for the host operating system.


— 12. If none of the above steps resolved the problem, reinstall the operating system to confirm if there is something about the particular installation that is causing the problem.

13. If none of the above steps resolved the problem, it is recommended that the operating system be reinstalled to confirm if there is something about the particular installation that is causing the problem.
=============================
Common Linux Problems

Verify there are no problems with the filesystem by performing a disk check on your hard drives. For further information, see Performing a disk check (1004003).

Check if there are sufficient resources in the following areas: Memory

For more information, see Investigating operating system memory usage (1004014). Disk

For more information, see Investigating operating system disk space (1004007). CPU

For more information, see Investigating operating system CPU usage (1004016).

— Note: If your operating system is installed to a virtual machine, and you have determined that there are insufficient resources, you need to increase the resource that is lacking:

Memory

For more information, see Increasing the amount of memory assigned to a virtual machine (1004059). Disk

For more information, see Increasing the size of a virtual disk (1004047). CPU

If this is a virtual machine running under an ESX Server host, see Increasing the amount of CPU assigned to a virtual machine (1004060).


Note: If this is a virtual machine running under any other product, there is no direct way of increasing the amount of assigned CPU. If your host has multiple CPUs or CPU cores, it is possible to set processor affinity among virtual machines so that one or more CPUs are not used by any other virtual machine. For more information, see Associating a Virtual Machine With a Particular Host Processor (110). Alternatively, the host hardware must be upgraded or the virtual machine moved to a different host.

If a virtual machine with multiple CPUs is performing poorly, see Determining if multiple virtual CPUs are causing performance issues (1005362).

Confirm that there is no virus compromising the operating system. For more information, see Detecting viruses (1004008).


Confirm that there is no spyware interfering with the operating system. For more information, see Detecting spyware (1004009).


Switch to run level 3 to eliminate software and processes as possible causes. For more information, see Changing Linux run levels (1004015).


Changing Linux run levels

Purpose

This article describes how to change Linux run levels. Changing Linux run levels is useful in troubleshooting problems where it is suspected that there is a daemon or application being loaded into Linux that may be causing unexpected operating system behavior. Examples of such unexpected behavior include crashes, the operating system failing to respond or being slow, and network problems. If the unexpected behavior stops after disabling a service or application then the source of the problem is identified. Other reasons for changing the run level include not having a requirement for an X-Windows environment and needing to perform system maintenance.



Resolution

To change the run level of a Linux operating system:

Note: If the run level is being changed to troubleshoot a problem with the operating system or an
application, following this procedure may remove a software environment that is required to test the health of your operating system.

Ensure that you are logged in as a user with root privileges. Edit the file /etc/inittab in the text editor of your choice.

Note: To perform this from a shell prompt using the VI text editor, refer to the Additional Information section at the end of this document.

Look for the line of text id:X:initdefault: where X is replaced by a number. This number represents the default Linux run level.

Edit the line of text and replace X with the run level you want to change to: 1

Single User Mode

3

Full multiuser

5

X-Windows (X11)

Note: The above is a list of run levels that are generally used. If the full list is not displayed at the top of the inittab file and you need to change to a level not listed, refer to the manual for your distribution of Linux.

Warning: Do not set X to 0 or 6.
Save the edited file.
Reboot the operating system.

Note: Linux boots into the new run level each time it is started. To return it to its former behavior, repeat steps 1-6 and edit the file to use the original value of X .

Note: It is possible to change the run level without rebooting the operating system and without affecting the run level the operating system defaults to when it is started:

Open a shell prompt. For more information, see Opening a command or shell prompt (1003892). Type init X and press Enter, where X is replaced by the run level you want to change to.

Note: If this command does not work, refer to the manual for your distribution of Linux.

Caution: This command exits all running applications. Save all work before entering this command.

Note: Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

7. Switch to Single User Mode to eliminate software and processes as possible causes. For more information, see Changing Linux run levels (1004015).

Note: Single User Mode eliminates more software and processes than run level 3 does, but it also further reduces operating system functionality. Depending on your problem, following this procedure may remove a software environment that is required to test the health of your operating system.

Confirm that the problem is not linked to your username by logging in as a different user. Additionally, verify that the problem is not linked to your username having or lacking root privileges by logging in as a user whose rights are the opposite.

Verify that the memory on the host computer is healthy. For more information, see Validating host memory (1004012).
10 Verify that the hardware devices on the host computer are healthy and supported. For more information, see Performing hardware diagnostics (1004013).

11. If the operating system having the problem has been installed to a virtual machine, power on the virtual machine from a different host. If the problem continues, the issue is with the virtual 12.machine itself. Continue to step 11. If the problem disappears, the issue is with the original host. Repeat steps 1-11 for the host operating system.

13.If none of the above steps resolved the problem, reinstall the operating system to confirm if there is something about the particular installation that is causing the problem.

New Topic:- Troubleshooting FC SAN storage in ESX

All the information in given in the below link
http://www.megaupload.com/?d=QR3EH0Y0


NEW TOPIC:- Using vmkfstools

The vmkfstools command supports the creation of a VMware ESX Server file system (VMFS) on a SCSI disk. Use vmkfstools to create, manipulate and manage files stored in VMFS volumes. You can store multiple virtual disk images on a single VMFS volume.

Note: You can also do most of the vmkfstools operations through the VMware Management Interface.

vmkfstools Command Syntax Note: You must be logged in as the root user to run the vmkfstools command.

vmkfstools Syntax When Specifying a SCSI Device The format for the vmkfstools command, when specifying a SCSI device, is:

vmkfstools <options> <device_or_VMFS_volume>[:<file>]

where <device_or_VMFS_volume> specifies a SCSI device (a SCSI disk or a partition on a SCSI disk) being manipulated or a VMFS volume, and <options> specifies the operation to be performed.

If <device_or_VMFS_volume> is a SCSI device, then it is specified in a form such as:

vmhba1:2:0:3

Here, vmhba1 specifies the second SCSI adapter activated by the command vmkload_mod .../XXX.o vmhba. (See VMkernel Module Loader for details on vmkload_mod.) The second number specifies the target on the adapter, the third number specifies the LUN (logical unit number) and the fourth number specifies the partition. Partition 0 (zero) implies the whole disk; otherwise, the number specifies the indicated partition.

<device_or_VMFS_volume> may also be a VMFS volume label, as set in the management interface or with the vmkfstools --setfsname command.

<file> is the name of a file stored in the file system on the specified device.

vmkfstools Syntax When Specifying a VMFS Volume or File The format for the vmkfstools command, when specifying a VMFS volume or file, is:

vmkfstools <options> <path>

where <path> is an absolute path that names a directory or a file under the /vmfs directory.

For example, you can specify a VMFS volume by a path such as:

/vmfs/vmhba1:2:0:3

You can also specify a single VMFS file:

/vmfs/lun1/rh9.dsk

vmkfstools Options This section includes a list of all the options used with the vmkfstools command.

Some of the tasks in this section include options that are suggested for advanced users only. These advanced options are not available through the VMware Management Interface.

Note: The long and short (single letter) forms of options are equivalent. For example, the following commands are identical:

vmkfstools --createfs vmfs2 --blocksize 2m --numfiles 32 vmhba1:3:0:1

vmkfstools -C vmfs2 -b 2m -n 32 vmhba1:3:0:1

If the vmkfstools command fails, and you don't know why, then check the log files in /var/log/vmkernel or use the management interface to view the latest warning.

Log in to the VMware Management Interface as root. The Status Monitor page appears. Click the Options tab. The Options page appears.
Click System Logs.

Basic vmkfstools Options Basic options are common tasks that you may perform frequently. You may also perform through the management interface.

Creates a VMFS on the specified SCSI device -C --createfs [vmfs1|vmfs2] -b --blocksize #[gGmMkK]

-n --numfiles #

This command creates a VMFS version1 (vmfs1) or version 2 (vmfs2) file system on the specified SCSI device.

For advanced users:

Specify the block size by using the -b option. The block size must be 2x (a power of 2) and at least 1MB. (The default file block size is 1MB.) You can specify the size in kilobytes, megabytes, or gigabytes by adding a suffix of k (kilobytes), m (megabytes), g (gigabytes) respectively.

Specify the maximum number of files in the file system with the -n option. The default maximum number of files is 256 files.

Lists the attributes of a VMFS volume or a raw disk mapping -P --querypartitions <VMFS_volume_name>
-P --querypartitions <VMFS_volume:fileName>

For a VMFS_volume_name, the listed attributes include the VMFS version number (VMFS-1 or VMFS-2), the number of physical extents (partitions) comprising the specified VMFS volume, the volume label (if any), the UUID (if any), and a listing of the SCSI device names of all the physical extents comprising the VMFS volume.

For a VMFS_volume:fileName, the listed attributes include the vmhba name of the raw disk or partition, corresponding to the mapping referenced by fileName, and any identification information for the raw disk.

Creates a file with the specified size on the file system of the specified SCSI device -c --createfile #[gGmMkK]

The size is specified in bytes by default, but you can specify the size in kilobytes, megabytes, or gigabytes by adding a suffix of k (kilobytes), m (megabytes), g (gigabytes) respectively.
Exports the contents of the specified file on the specified SCSI device to a virtual disk on the file system of the service console -e --exportfile <dstFile>

After the export, you may transfer the virtual disk to another server machine and import it to a SCSI device on the remote machine.

If your virtual disk has redo logs, you have the following options:

If you use the exportfile option on the base virtual disk, only the base virtual disk is exported. Any uncommitted redo logs are not exported, but can be copied out separately.

If you use the exportfile option on a ESX Server redo log, the exported virtual disk contains the redo log, any previously created redo logs, and the base virtual disk. That is, the newly created exported virtual disk appears as if the redo log(s) was committed to its base virtual disk. Note: However, your original source redo log(s) and base virtual disk remain unchanged.

If you want to export your redo logs and base virtual disk separately, then use the exportfile option to export the base virtual disk, and the cp command to export each redo log separately.

Use the combination of exportfile and importfile together to copy VMFS files to remote machines. The virtual disk should take less space than the full size of the VMFS file, since the virtual disk does not include zeroed sectors of the VMFS file.

Imports the contents of a VMware virtual, plain, or raw disk on the service console to the specified file on the specified SCSI device -i --importfile <srcFile>

This command is often used to import the contents of a VMware Workstation or VMware GSX Server virtual disk onto a SCSI device. You may also run this command to import a virtual disk, that was created by exporting the contents of a disk from another SCSI device.

Note: The destination device must have space for the entire size of the virtual disk, even if it is mostly free space, as the complete contents of the source disk are copied.

Caution: The vmkfstools command may fail when attempting to import plain disks created with version 2.5 or earlier of GSX Server. If vmkfstools returns an error when importing a plain disk, see Path Name Failures When Importing GSX Server Virtual Machines.

Lists the files on the file system on the specified device -l --list -h --human-readable

-M --verbosemappings

The output includes permissions, sizes and the last modification time for redo logs, virtual disk files, and swap files. You can use the -h option to print the sizes in an easier-to-read format; for example, 5KB 12.1MB, and so on.

(Advanced users only) The -M option lists the vmhba name that corresponds to each raw disk mapping.

Sets the name of the VMFS on the specified SCSI device -S --setfsname <fsName>

You can see the VMFS name by running the vmkfstools command with the -l option, vmkfstools -l.

Advanced vmkfstools Options Advanced options are tasks that you may perform infrequently. These tasks are not available through the management interface, or are available in a limited form, and are suggested for advanced users only.

Commits the redo log of the specified file, making the associated changes permanent -m --commit

If a virtual machine is in undoable or append mode, then the redo log is created automatically. The name of the redo log is derived by appending .REDO to the name of the file that contains the base disk image. You can commit the changes to the disk that are stored in the redo log by using the commit option or eliminate the
changes by using the rm command to delete the redo-log file.

Sets the VMFS on the specified SCSI device to the specified mode -F --config [public|shared|writable]

Note: In ESX Server 2.1, private VMFS volumes are deprecated. If you have existing VMFS version 1 (VMFS-1) or VMFS version 2 (VMFS-2) private volumes, then change the access to public.

Public — With public VMFS-2 volumes, multiple ESX Server computers can access the same VMware ESX Server VMFS volume concurrently. VMware ESX Server file systems with a public access mode use an automatic per-file locking to ensure file system consistency.

With a public VMFS-1 volume, multiple ESX Server computers have the ability to access the VMware ESX Server VMFS volume, as long as the VMFS volume is on a shared storage system (for example, a VMFS on a storage area network). However, only one ESX Server can access the VMFS-1 volume at a time.

Note: ESX Server creates VMFS volumes as public by default.

Shared — The shared access mode allows virtual machines on multiple servers to access the same virtual disk on a VMFS-2 volume simultaneously. (In public mode, virtual machines can only access the same VMFS volume, never the same virtual disk, at the same time.)

Note: A VMFS volume that is used for failover-based clustering should have its mode set to shared.

Writable — When virtual machines access a file on a shared VMFS, the file system metadata becomes read-only. That is, no virtual machine or user command can create, delete or change the attributes of a file.

If you need to create, remove, or change the length of a file (vmkfstools -X), then you need to change the volume to "writable". First, be sure that no virtual machines are accessing the VMFS volume (all virtual machines are powered off or suspended), then change the file system metadata to writable with the command, vmkfstools --config writable. Once you power on or resume a virtual machine, the file system metadata reverts to being read-only.

Extends an existing logical VMFS-2 volume by spanning multiple partitions -Z --extendfs <extension-SCSIDevice>
-n --numfiles #

This option adds another physical extent (designated by <extension-SCSIDevice>), starting at the specified SCSI device. By running this option, you lose all data on <extension-SCSIDevice>.

Note: A logical VMFS-2 volume can have at most 32 physical extents.

This operation is not supported on the VMFS-1 file system and in fact, returns an error if the specified SCSI device is formatted as VMFS-1. Each time you use this option and extend a VMFS-2 volume with a physical extent, the VMFS volume supports, by default, an additional 64 files. You can change this default number of files by using the -n option.

Maps a Raw Disk or Partition to a File on a VMFS-2 Volume -r --maprawdisk <raw-SCSI-device>

Once this mapping is established, you can access the raw disk like a normal VMFS file. The file length of the mapping is the same as the size of the raw disk or partition. The mapping can be queried for the raw SCSI device name by using the -P option.

By mapping a raw disk or partition to a file, you can manipulate this raw disk or partition as any other file. In addition, this mapping enables you to have undoable, append, and nonpersistent "raw disks".

All VMFS-2 file-locking mechanisms apply to raw disks.
Displays Disk Geometry for a VMware Workstation or GSX Server Virtual Disk -g -- geometry <virtual-disk>

The output is in the form: Geometry information C/H/S is 1023/128/32, where C represents the number of cylinders, H represents the number of heads, and S represents the number of sectors.

When importing VMware Workstation or VMware GSX virtual disks to VMware ESX Server, you may see a disk geometry mismatch error message. A disk geometry mismatch may also be the cause if you have problems loading a guest operating system, or running a newly created virtual machine.

View the events log through the VMware Management Interface (Users and Events page for the virtual machine) or through the service console (the vmware.log file, found, by default, in the <user>/vmware/<guest_operating_system> directory). Look for C/H/S and compare this with the output of the vmkfstools -g command.

If the disk geometry information is different, then specify the correct information, from the output of the vmkfstools -g command, in the configuration file of the newly created virtual machine.

See Migrating VMware Workstation and VMware GSX Server Virtual Machines for complete details on specifying the disk geometry in a virtual machine's configuration file.

Extends the specified VMFS to the specified length -X --extendfile #[gGmMkK]

Use this command to extend the size of a disk allocated to a virtual machine, after the virtual machine has been created. The virtual machine that uses this disk file must be powered off when you enter this command. Also, the guest operating system must be able to recognize and use the new size of the disk, for example by updating the file system on the disk to take advantage of the extra space.

You specify the size in kilobytes, megabytes, or gigabytes by adding a suffix of k (kilobytes), m (megabytes), g (gigabytes) respectively.

Manages SCSI reservations of physical targets or LUNs -L --lock [reserve|release|reset]

Caution: Be careful when using these commands. The reserve, release, and reset commands can interrupt the operations of other servers on a storage area network (SAN), so use these commands with great caution.

The -L reserve command reserves the specified raw disk, or the disk containing the specified VMFS volume. After the reservation, other servers will get a SCSI reservation error if they attempt to access that disk, but the server that did the reservation will be able to access the disk normally.

The -L release command releases the reservation on the specified disk, or disk containing the specified VMFS volume. Any other server can access the disk again.

The -L reset command does a SCSI reset to the specified disk. Any reservation held by another server is released.

Recovers a VMFS -R --recover

This command enables you to recover a VMFS (accessible by multiple ESX servers) when other vmkfstools commands indicate that the file system is locked by another ESX Server machine, but, in fact, no other server is currently accessing this file system. This situation may occur if the VMFS was being accessed by a server (for example, running a virtual machine) and that server crashed.

Note: You should only use this command if you are certain that no other ESX Server is still accessing the file system.
Scans the specified vmhba adapter for devices and LUNs -s --scan <FC_SCSI_adapter>

This option is particularly useful for adapters connected to storage area networks, particularly if you are reconfiguring your SAN. If a new device or LUN becomes accessible through the adapter, then ESX Server registers this new virtual device for use by virtual machines. If an existing device or LUN is no longer used and appears to be gone, then it is removed from use by virtual machines.

Note: Only use this -s option for Fibre Channel adapters.

You can see the results of the scan by using ls /vmfs or looking at the contents of /proc/vmware/scsi.

Create or Resize a Swap File in a VMFS Volume of the specified SCSI device -k --createswapfile #[gGmMkK]

The size is specified in bytes by default, but you can specify the size in kilobytes, megabytes, or gigabytes by adding a suffix of k (kilobytes), m (megabytes), or g (gigabytes), respectively.

Note: You must be logged in to the Service Console with root user permissions to create a swap file.

You can resize an existing swap file by specifying the new file size as an argument to the -k option: Deactivate the swap file, if it is active, with vmktools -y.
Resize the swap file with the -k option.
Activate the swap file with vmktools -w filename.

If you try to resize an active swap file, ESX Server returns an error message.

ESX Server does not automatically activate a swap file after it is created. Use vmkfstools with the -w option to activate a swap file. You can set a swap file to be activated automatically after a system reboot with the Activation Policy option of the Swap Management section in the Options tab of the Management Interface.

Activate a Swap File -w --activateswapfile

This command activates the specified swap file.

Note: You must be logged in to the Service Console with root user permissions to activate a swap file.

Deactivate a Swap File -y --deactivateswapfile <fileID>

ESX Server assigns a fileID tag to a swap file when it is activated. You must identify a swap file by its fileID tag when specifying which swap file to deactivate with the -y option.

Note: You must be logged in to the Service Console with root user permissions to activate a swap file.

You can find the fileID tag assigned to a swap file in the swap status file, /proc/vmware/swap/stats.

Note: You must shutdown all virtual machines before deactivating a swap file. Entering a vmkfstools -y command returns an error message if any virtual machines are powered on.

Migrate a VMFS from VMFS-1 to VMFS-2 -T --tovmfs2

This command converts the VMFS volume on the specified partitions from VMFS-1 to VMFS-2, while preserving all files in the volume. ESX Server's locking mechanism attempts to ensure that no remote ESX Server or local process is accessing the VMFS volume that is being converted.

Note: If you have an active swap partition, you must deactivate it before running this command. Deactivate
swap through the VMware Management Interface and reboot your server. Once this vmkfstools -T command completes, you can reactivate your swap file.

This conversion may take several minutes. When your prompt returns, the conversion is complete.

Note: In ESX Server 2.1, private VMFS volumes are deprecated. If you have an existing VMFS version 1 (VMFS-1) private volume, then the newly created VMFS-2 volume's access mode is automatically changed to public.

Before starting this conversion, check the following: Back up the VMFS-1 volume that is being converted

Be sure there are no virtual machines powered on using this VMFS-1 volume (SAN only) Be sure no other ESX Server is accessing this VMFS-1 volume

(SAN only) Be sure this VMFS-1 volume is not mounted on any other ESX Server

Caution: The VMFS- 1 to VMFS-2 conversion is a one-way process. Once the VMFS volume is converted to VMFS-2, you cannot revert it back to a VMFS-1 volume.

Note: The first time you access a newly converted VMFS-2 volume, the initial access will be slow, because of internal volume consistency checking.

Examples Using vmkfstools This section includes examples using the vmkfstools command with the different options described previously.

Create a new file system vmkfstools -C vmfs2 -b 2m -n 32 vmhba1:3:0:1

This example illustrates creating a new VMFS version 2 (vmfs2) on the first partition of target 3, LUN 0 of SCSI adapter 1. The file block size is 2MB and the maximum number of files is 32.

Extends the new logical volume by spanning two partitions vmkfstools -Z vmhba0:1:2:4 vmhba1:3:0:1

This example illustrates extending the new logical file system by adding the 4th partition of target 1 (and LUN 2) of vmhba adapter 0. The extended file system supports a maximum of 64 (2 X 32) files, and spans two partitions — vmhba1:3:0:1 and vmhba0:1:2:4.

You can address the file system by using the name of its head partition; for example, vmhba1:3:0:1.

Names a VMFS volume vmkfstools -S mydisk vmhba1:3:0:1

This example illustrates assigning the name of mydisk to the new file system.

Creates a new VMFS virtual disk file vmkfstools -c 2000m mydisk:rh6.2.dsk

This example illustrates creating a 2GB VMFS file with the name of rh6.2.dsk on the VMFS volume named mydisk. The rh6.2.dsk file represents an empty disk that may be accessed by a virtual machine.

Imports the contents of a virtual disk to the specified file on a SCSI device vmkfstools -i ~/vms/nt4.dsk vmhba0:2:0:0:nt4.dsk

The example illustrates importing the contents of a virtual disk (that contains Windows NT 4.0) from the service console's file system to a file named nt4.dsk on target 2 of SCSI adapter 0.

You can configure a virtual machine to use this virtual disk by adding the following lines to its configuration file:

scsi0.virtualDev = vmxbuslogic
scsi0:0.present = TRUE
scsi0:0.name = vmhba0:2:0:0:nt4.dsk

Migrate virtual machines to VMware GSX Server or VMware Workstation, then back to VMware ESX Server Note: The following example, illustrating the -e and -i options, result in the export or import of a virtual disk.

This example illustrates migrating a virtual machine's virtual disk file from ESX Server to VMware GSX Server or VMware Workstation, then migrating the virtual disk back to ESX Server.

vmkfstools -e winXP.vmdk vmhba0:6:0:1:winXP.dsk

The preceding command exports the winXP.dsk virtual disk file to one or more .vmdk files, maximum size 2GB, that you can use as a virtual disk in a virtual machine on GSX Server or Workstation. The resultant winXP.vmdk file(s) can reside on a VMFS volume, or an /ext2, /ext3, or NFS file system.

The following example imports a GSX Server or Workstation virtual disk file into the VMFS volume on the specified SCSI device.

vmkfstools -i winXP.vmdk vmhba0:6:0:1:winXP.dsk

By contrast, if you are importing directly into a raw partition, the example becomes:

vmkfstools -i winXP.vmdk vmhba0:6:0:1

Lists the files on the VMFS of the specified device vmkfstools -l vmhba0:2:0:0

This command illustrates listing the contents of the file system, including redo logs, virtual disk files, and swap files on target 2 of SCSI adapter 0.

Scans a vmhba adapter This example illustrates scanning the vmhba1 adapter for any new or removed targets or LUNs.

vmkfstools -s vmhba1
============================================
New Topic :- Admission Control Policy on Next Post.Keep Visiting For more

0 Responses to “VMWARE Troubleshooting Disk and Datastore Related Issues FAQ-Part2 ”