VMWARE WORLD

Want to Develop a game for IPhone and Android ?..

2011-12-18T10:33:00.000+05:30

Destroyer package is a complete 3d jet plane shooter game project for unity3d, supports android /ios and PC versions. This package is designed to aim for new unity3d learners,lots of clearly commented code .

*supports both keyboard || mouse ||touch inputs
*complete game project ready to build .

webplayer preview
http://dl.dropbox.com/u/19384507/Des...WebPlayer.html

Assetstore link
http://u3d.as/content/kiran-kumar/destroyer-3d-plane-shooting-game/2wb
Price : 40$

Replacing a SAN LUN Causes ESX Server to Behave Unexpectedly

2011-10-25T00:22:00.000+05:30

Details

If your SAN administrator replaces a LUN your ESX Server has access to, the behavior of your ESX Server host depends on whether the replaced LUN is actively used or not.
If the replaced LUN is actively used by your ESX Server system, the ESX Server system and its virtual machines act in an unpredictable manner, and the ESX Server log file reports the following critical error:
Warning "The physical media represented by vmhba1:0:0 has changed." "The device cannot be re-synchronized with the system." "This is a critical error."
There is no solution in this case.
If the storage administrator removes a LUN that is not actively used by your ESX Server system and then later creates a new LUN with the same LUN #, you can use your ESX Server system to access the new LUN and format it with a VMFS datastore. After the server is rebooted, the system will treat the new LUN as a snapshot and will not be able to mount the VMFS datastore created on this LUN. To resolve this issue, you need to resignature the VMFS datastore.

Solution

For Resignaturing specific issues, see Resignaturing VMFS3 volumes that are not snapshots 9453805.

To enable volume resignaturing, follow this procedure:

In the VI Client, select the host in the inventory panel.
Click the Configuration tab and click Advanced Settings.
Select LVM in the left panel, and set the LVM.EnableResignature option to 1.
Rescan for any new LUNs or VMFS volumes. Volumes that are detected to be snapshots or replicas are resignatured.
Set the LVM.EnableResignature option to 0 after resignaturing is complete.
Rename the VMFS datastore to its original name.

VMware recommends that you vacate the ESX Server system and reboot it before creating a VMFS datastore if you are aware in advance of the LUN changes of this type. This prevents unexpected behavior.

Verifying and troubleshooting networking connections that may cause VMware Converter to fail

2011-09-16T10:33:00.003+05:30

Symptoms

Using VMware Converter fails
Unable to complete all of the steps in the VMware Converter conversion wizard
The conversion process fails between 1% and 2%
You receive one or more of these errors:
- Unknown error returned by VMware Converter Agent
- P2VError UFAD_SYSTEM_ERROR(Internal Error)
- Failed to connect
- Giving up trying to connect
- Failed to establish Vim connection to hostname.domain.com. Vmacore::Exception: The requested name is valid, but no data of the requested type was found.
- Image processing task has failed with MethodFault::Exception: sysimage.fault.IncompatibilityFault
- ERROR: Unable to open file %s
- [NFC ERROR] NfcNewAuthdConnectionEx: Failed to connect to peer. Error: Host address lookup for server hostname.domain.coml failed: The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for
- sysimage.fault.FileOpenError
- Task failed: P2VError FILE_OPEN_FAILED
- Unable to find server

Resolution

For VMware Converter to function correctly, all servers involved in the process must be able to communicate with each other and resolve each other's hostnames to IP addresses. In particular, the source server must be able to communicate directly with both the server running VMware Converter (whether it is installed on a workstation or the vCenter Server), and the destination (ESX/ESXi server).

Ensure that DNS name resolution is working between the source and target servers involved in the conversion.

To ensure DNS name resolution is working between these connections:
1. Open a command prompt on the source server. For more information, see Opening a command or shell prompt (1003892).
2. Use this command to test name resolution for each server, using separate commands each time:
  
  nslookup <hostname>
  
  where <hostname> is the host name of the ESX/ESXi host or destination server, or VMware Converter server that you are testing.
3. If you are unable to resolve the DNS name to the IP address of the server, ensure the servers are registered in your DNS server on the network, or use the local hosts file to manually map the IP address to the DNS name.
If the destination server is an ESX/ESXi host, verify that ports 443 and 902 are open directly between the source server and the ESX/ESXi host. For more information, see Testing port connectivity with Telnet (1003487).
If the source and destination servers are on different non-connected networks, you can enable IP forwarding on the server running VMware Converter (using Windows XP) to pass traffic from the source to the destination. For more information, see the Microsoft Knowledge Base article 315236. If VMware Converter is installed on Windows Server, you can use Routing and Remote Access services to accomplish forwarding.

Note: The preceding link was valid as of April 26, 2011. If you find the link to be broken, provide feedback on the article and a VMware employee will update the article.
If the source a virtual machine on an ESX/ESXi server managed by vCenter Server and the destination is a different vCenter Server, the connection may fail. To resolve this, connect the source ESX/ESXi server to the same vCenter Server as the destination.

Note: To reduce the number of variables to troubleshoot and network ports that are required, install VMware Converter on the source and specify an ESX/ESXi host as the destination directly, rather than the vCenter Server, where applicable.

VMware Converter Agent fails to install due to a connection error

2011-09-16T10:33:00.000+05:30

Details

VMware Converter fails to locate a physical server or running virtual machine.
You are unable to establish a connection to the source system.
VMware Converter Agent does not install.
You receive one or more of these errors:
- Failed to connect to \\<hostname>\pipe\vmware-ufad-p2v30-vmdb .
  Reason: The network path was not found. . Error code: 53.
- Error 1219: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
- Unknown error returned by VMware Converter Agent
- P2VError UFAD_SYSTEM_ERROR(Internal Error)
- Failed to connect
- Giving up trying to connect
- Failed to establish Vim connection to hostname.domain.com.
  Vmacore::Exception: The requested name is valid, but no data of the requested type was found.
- Image processing task has failed with MethodFault::Exception: sysimage.fault.IncompatibilityFault
- ERROR: Unable to open file %s
- [NFC ERROR] NfcNewAuthdConnectionEx: Failed to connect to peer. Error: Host address lookup for server hostname.domain.coml failed: The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for
- sysimage.fault.FileOpenError
- Task failed: P2VError FILE_OPEN_FAILED
- Unable to find server

Solution

If you receive any of these errors when trying to connect to a source system or install the Converter Agent, it is because VMware Converter is using an interprocess communication (IPC) named-pipe network connection with multiple sets of credentials between the local Windows Redirector and the remote host. Windows Redirector does not allow IPC connections with multiple credentials from the same user session.
Note: This restriction also applies to mapped network drives as they are also a type of named-pipe connection.
To ensure the Converter Agent connection succeeds, perform these steps on the source system that is to be converted and the system running VMware Converter (whether it be vCenter Server or a workstation):

Close any application views or Windows Explorer windows showing files, Active X components, or Microsoft Management Console (MMC) snap-ins in the server you are trying to convert.
Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
Disconnect any mapped drives from the remote host by running this command:

net use \\<remote_hostname> * /delete
Open My Computer and check for any mapped network drives to the remote host. if you find any, disconnect them.
Log off from the server running VMware Converter and log on again to disconnect any open IPC named-pipe connections established by any remaining applications.

If issues with VMware Converter persist:

Restart the server running VMware Converter.
Restart the server running vCenter Server if you are using the vCenter Server Converter plug-in.

For more information, see Troubleshooting when VMware Converter fails to complete a conversion of a physical or virtual machine (1006284).

Troubleshooting damaged operating system components that can cause conversion failures with VMware Converter

2011-09-16T10:31:00.002+05:30

Symptoms

Using VMware Converter, you are unable to take a snapshot of a volume.
The free disk space or used disk space reported in the New Conversion wizard is incorrect.
The conversion may fail almost immediately after clicking Finish in the New Conversion wizard
You receive one or more of these errors:
- Failed to take snapshot of the source volume
- Error opening disk device: Incorrect function (1)
- Failed to get capacity for \\.\PhysicalDrive0 : error opening disk device: Incorrect function (1)
- sysimage.fault.OsVersionNotFound
- Warning: no attached disks were detected.
- The COM Server with CLSID {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} and name SW_PROV cannot be started. [0x80070422]

Cause

Damaged operating system components can cause VMware Converter to fail when trying to convert a physical or virtual machine.

Resolution

Windows XP, 2003, 2008, and 7

To troubleshoot damaged operating system components that cause a conversion failure in Windows XP, 2003, 2008, and 7:

Update the disk controller driver to the latest version.
Confirm that the VMware Converter related services are started on the source operating system.

To ensure the VMware related services are started:
1. Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
2. Run these commands:
  
  net start vstor2-p2v30 (VMware Converter 3.x only)
  net start vstor2-converter (VMware Converter 4.x only )
  net start vmware-converter (VMware Converter 4.x only)
  net start ufad-p2v net start "tcp/ip netbios helper" net start swprv net start vss
3. Confirm that there are no errors in the system Event Log from these sources: VSS, COM, DCOM, Service Control Manager (SCM), VMware Converter. Check for errors during the time period when the conversion was attempted.
  
  To view the Event Log, go to Start > Control Panel > Administrative Tools > Event Viewer.
4. Verify that there are no Group Policies (GPOs) in effect that are restricting the Volume Shadow Copy services from running.
  
  Click Start > Run , type rsop.msc, and press Enter. If you are unsure of the GPOs in place, try removing the source server from the domain. This disables the GPOs from Active Directory.
5. If you are running Windows 2008 or 7, ensure that you have installed the hot-fix available to fix issues with VSS. For more information, see the Microsoft Knowledge Base article 2495295.
  
  Note: The preceding link was correct as of August 31, 2011. If you find the link is broken, provide feedback and a VMware employee will update the link.
6. For Windows 2003, try to re-register the Volume Shadow Copy Services (VSS).
  
  Caution: Re-registering the components is only valid for Windows 2003. Do not attempt this on Windows 2008 or Windows 7, as those operating systems are manifest based. Manually registering the components can cause unpredictable results.
  
  Open a command prompt and run these commands for Windows 2003:
  
  cd %systemroot%\system32 net stop vss net stop swprv regsvr32 ole32.dll regsvr32 vss_ps.dll vssvc /Register regsvr32 /i swprv.dll regsvr32 /i eventcls.dll regsvr32 es.dll regsvr32 stdprov.dll regsvr32 vssui.dll regsvr32 msxml.dll regsvr32 msxml3.dll regsvr32 msxml4.dllNote: For more information, see Opening a command or shell prompt (1003892).
7. Restart the server.
8. Verify that the VSS writers are working correctly. Open a command prompt and run the command:
  
  vssadmin list writersNote: For more information, see Opening a command or shell prompt (1003892).
  
  If you encounter an error, see the Microsoft Knowledge Base article 940184. Then, follow the Microsoft Knowledge Base articles list in the Additional Information section of this article, or contact Microsoft support for further assistance.
  
  Note: The preceding link was correct as of August 31, 2011. If you find the link is broken, provide feedback and a VMware employee will update the link.

Windows NT and Windows 2000

To troubleshoot damaged operating system components that cause a conversion failure in Windows NT and Windows 2000:

Update the disk controller driver to the latest version. For related information, see Conversion fails on a source running Windows NT with a Dell PERC 3 or 4 disk controller (1001559).
Confirm that the VMware Converter related services are started on the source operating system.

To ensure the VMware related services are started:
1. Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
2. Run these commands:
  
  net start vstor2-p2v30 (VMware Converter 3.x only)
  net start vstor2-converter (VMware Converter 4.x only )
  net start vmware-converter (VMware Converter 4.x only)
  net start ufad-p2v net start "tcp/ip netbios helper" net start swprv net start vss
Confirm that there are no errors in the system Event Log. Check for errors during the time period when the conversion was attempted.
- For Windows NT:
  1. Go to Start > Run, type eventvwr, and press Enter.
  2. Check for errors from these sources: RPCSS, COM, DCOM, Service Control Manager, vstor2-p2v30, vstor2-converter, vmware-converter, ufad-p2v.
- For Windows 2000:
  1. Go to Start > Control Panel > Administrative Tools > Event Viewer .
  2. Check for errors from these sources: COM, DCOM, Service Control Manager (SCM), VMware Converter .

NIC team failover, failback, or vMotion results in loss of network connectivity

2011-09-16T10:30:00.000+05:30

incase of conversion fails....

Symptoms

When utilizing a NIC team configuration and one of the network adapters in the team fails, network connectivity is lost for all portgroups on the virtual switch on failover or failback.
Loss of network connectivity on a virtual machine after vMotion to another ESX/ESXi host.

Resolution

When a network adapter or link within a NIC team fails, all traffic is rerouted over the available adapter in the team (in an Active/Standby configuration, the Standby adapter takes over for the failed Active adapter). After a vMotion of a virtual machine, its network traffic is directed over one of the destination's network adapters. If this does not occur and network connectivity is lost after either of these events, perform these troubleshooting steps.

Validate that each troubleshooting step below is true for your environment. Each step provides instructions or a link to a document, in order to eliminate possible causes and take corrective action as necessary. The steps are ordered in the most appropriate sequence to isolate the issue and identify the proper resolution. Please do not skip a step.

Verify that the physical network adapters are supported. For more information, see ESX/ESXi host network adapter compatibility (1003685).
Verify that all network links in the team are up. For more information, see Verifying a network link (1003724).
Verify that the physical switch ports are configured consistently among all network adapters in the team.
Verify that port security is not configured on the physical switch ports. For more information, see Loss of network connectivity when port security is configured on the physical switch (1002811).
Verify that portfast (or equivalent) is enabled on all of the ESX host's physical switch ports. For more information, see STP may cause temporary loss of network connectivity when a failover or failback event occurs (1003804).
If connecting the NIC team adapters to separate physical switches, apply the following patches:
- For ESX 3.0.1 – Patch ESX-1002093
- For ESX 3.0.2 – Patch ESX-1002424
Verify the integrity of the physical network adapter. For more information, see Verifying the integrity of the physical network adapter (1003686).
Verify that the network configuration on the ESX host is optimized for the best performance, including speed and duplex settings. For more information, see Configuring the speed and duplex of an ESX/ESXi host network adapter (1004089).
Check if there are available ports on the vSwitch by running the command # esxcfg-vswitch -l.For more information, see No network connectivity if all ports are in use (1009103).

Note: If your problem still exists after trying the steps in this article:

Gather the VMware Support Script Data. For more information, see Collecting Diagnostic Information for VMware ESX Server Problems (653).
File a support request with VMware Technical Support and note this KB Article ID (1003969) in the problem description. For more information, see How to Submit a Support Request.

Ensuring proper installation of VMware Converter and functionality of the Converter Agent

2011-09-16T10:28:00.000+05:30

Symptoms

Cannot take snapshot of source physical or virtual machine.
Unable to establish communication with the source system.
Converter Agent may not install or installs partially.
You may receive one or more of these errors:
- Failed to take snapshot of the source volume
- stcbasic.sys not installed or snapshot creation failed. err=2
- vsnap does not have admin rights

Resolution

VMware Converter relies on the Converter Agent to transfer information from the source server to the designated target, whether it be an ESX/ESXi host, vCenter Server, or an image file. VMware Converter relies on the Agent for communication, so if the Converter Agent is not installed, conversions are not possible. There are numerous reasons why the Converter Agent may have issues installing.

Minimum requirements

To ensure that you meet the minimum requirements:

If the source is a physical or virtual server that is powered-on and running Windows NT or 2000, verify that the server was restarted after the Converter Agent is installed during the connection and preparation phase of the Conversion wizard.
Install the Agent using an account that has local Administrator rights. If you are unsure of the rights, use the local Administrator account built-in to the server.
If the source is Windows NT server, ensure that you have Service Pack 6 or 6a installed.
If the source is Windows 2000 servers, ensure that Service Pack 4 and Security Rollup Package, Version 2 (Sep 13, 2005) or higher are installed. To determine the which package is installed, see the Microsoft Knowledge Base article 922979. For more information, the Microsoft Knowledge Base article 904374.
If the source is a Windows 2003 server, have Service Pack 1 or higher installed.
If the server has been converted previously with a different version of VMware Converter or a mix of VMware Converter and VMware vCenter Converter Plug-in, remove the previous Converter agent before attempting again.
Ensure that VMware Converter is not already installed on the source. To verify, see Troubleshooting the Converter Agent in this article.

Troubleshooting the Converter Agent

To troubleshoot VMware Converter installation and functionality:

Log on the source server as an Administrator or use a the local Administrator account.
Click Start > Control Panel > Add/Remove Programs.
Check for multiple copies of VMware Converter and VMware Converter Enterprise. Remove any and all installations of Converter.

Note: The agents, managers, and plug-ins for Converter Enterprise cannot be used with VMware Converter (standalone), and vice-versa.
Attempt a conversion again. This process reinstalls the Converter Agent.

Note: If the source is running Windows NT or Windows 2000, you must restart the server before completing conversion. This will require downtime of the source system.
If the automated installation fails, use VMware Converter Standalone and manually install the Agent software:
1. Install VMware Converter (standalone) on the server assigned to perform conversion.
2. Copy and install the VMware Converter installation package on the source server.
3. During installation, select Custom. Deselect all components, except Converter Agent.
Restart the server if prompted.
Attempt a conversion again.
If the process fails, continue to manually start the dependent services:
1. Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
2. The commands to start the services differ for versions of VMware Converter.
  - On VMware Converter 4.x:
    - For Windows NT and 2000, run:
      
      net start vstor2-converter
      net start vmware-converternet start "tcp/ip netbios helper service"net start stcp2v30
    - For Windows XP and 2003, run:
      net start vstor2-converter
      net start vmware-converter
      net start "tcp/ip netbios helper"
      net start swprv
      net start vss
  - On VMware Converter 3.x:
    - For Windows NT and 2000, run:
      
      net start vstor2-p2v30net start ufad-p2vnet start "tcp/ip netbios helper service"net start stcp2v30
    - For Windows XP and 2003, run:
      net start vstor2-p2v30
      net start ufad-p2v
      net start "tcp/ip netbios helper"
      net start swprv
      net start vss
3. Verify that the service startup process completed successfully from the system Event Log:
4. 1. Click Start > Run, type eventvwr, and press Enter.
  2. Check for errors from these sources, where applicable: rpcss, com, dcom, scm, vstor2-p2v30, vstor2-converter, ufad-p2v, vmware-converter, VSS, COM, DCOM, or Service Control Manager (SCM), VMware Converter.
  3. Check for errors during the time period when you attempted to start the services in Step 5 above, or when you restarted the server.

Converting a physical blade server fails (vmware kbs)

2011-09-16T10:27:00.000+05:30

Details

Conversion of a blade server fails
A media tray is attached to the blade server
You may receive the following errors:
- Operating system could not be found
- Unable to determine guest operating system
- Unable to read OS info from system disk: sysimage.fault.PlatformError
- VmiQuerySourceInfoTask::task{0}: Image processing task has failed with MethodFault::Exception: sysimage.fault.UnableToDetermineGuestOs
- Failed to get info for \\.\PhysicalDrive0: error Reading disk \\.\PhysicalDrive0's geometry: The device is not ready (21)
- Fatal error occurred. The most common reason for this is loss of network connection. The wizard will now be closed.

Solution

Many blade systems use a specialized USB pass-through device to emulate the floppy and CD-ROM when the media tray is connected. The presence of these devices can confuse the operating system into incorrectly presenting the devices as a hard disk type to Converter which attempts to find the system volume on these devices. This causes a guest operating system detection failure. This issue can also happen with non-blade servers when similar devices are connected or virtual machines when performing a hot clone.

To ensure converting a blade server does not fail:

Disconnect the media tray from the blade server management console. This should disconnect any floppy or CD-ROM drives from the physical server.
If removing the media tray does not solve the problem, disable the USB devices in the operating system (virtual machines) or disconnect the devices from the physical computer. You can re-enable the USB devices or reattach the devices to the physical computer after conversion is complete.

For more information related to conversion failing, see Troubleshooting when the Conversion wizard does not complete successfully (1006284).

Adjusting ESX host Time Zone

2011-08-19T20:06:00.002+05:30

Details

During installation, a time zone was selected for ESX host that does not match the desired time zone. This article provides steps to change the time zone.

Note: An ESX host with the wrong date and time or time zone passes on that wrong information. When a virtual machine boots up it seems to get its initial time from the BIOS hardware clock which comes from the ESX host.

Solution

ESX

To change the time zone:

Note: It is not necessary to reboot the ESX host after following this procedure.

Log into the ESX service console as root.
Find the desired time zone under the directory /usr/share/zoneinfo . Some regions have multiple files in a subdirectory. For example, US contains several files, each representing a time zone.

Note: The example below uses /usr/share/zoneinfo/US/Pacific as the new time zone file.
Use nano ( or another text editor) to open /etc/sysconfig/clock . At the command prompt, type:
nano /etc/sysconfig/clock

Edit this file to show the relative path to the file representing the new time zone, and ensure that UTC and ARC are set as shown:ZONE="US/Pacific"
UTC=false
ARC=false
Copy or link the desired time zone file to /etc/localtime . Continuing the example using US/Pacific :
- To copy, run:
  cp /usr/share/zoneinfo/US/Pacific /etc/localtime
- To link, run:
  ln -s /usr/share/zoneinfo/US/Pacific /etc/localtime
  
  Note: If you receive a overwrite `/etc/localtime'? prompt, answer y to replace the file representing the old time zone. Again, it is not necessary to reboot the ESX host after updating /etc/localtime .
Confirm that /etc/localtime has been updated with the correct zoneinfo data:
1. Reference the zoneinfo file used in step 2 and compare it to / etc/localtime using the diff command:[root@esxhost]# diff /etc/localtime /usr/share/zoneinfo/US/Pacific
  If the files are identical, your prompt returns without any output.
2. If /etc/localtime is not the same as the /usr/share/zoneinfo/<your location> , the output from the diff command appears similar to:Binary files /etc/localtime and /usr/share/zoneinfo/US/Pacific differ
  
  If the files are not the same, repeat step 4.

After updating /etc/localtime with the correct zoneinfo data, confirm the system and hardware clocks are correct. Use the Linux date command to check and set the correct time if necessary. Set the hardware clock to match the correct system time:

Set the system clock to the local date and time:
date MMDDhhmmYYYY
Update the hardware clock with current time of the system clock:
/sbin/hwclock --systohc

Notes:

Upon booting, ESX runs /etc/rc.d/init.d , which reads /etc/sysconfig/clock to set the system clock based on the hardware clock's current time and the configured time zone information. To synchronize ESX to an external time reference, see Installing and Configuring NTP on an ESX host (1339) .
You may be required to restart the vSphere Client for the timezone information to be updated within the GUI.

For more information about timezones, including issues with Daylight Saving Time (DST), see the VMware Knowledge Base.

ESXi

ESXi uses UTC time and does not support changing time zones.

In ESXi 3.5, you see the message:

Note: The date and time of the host have been translated to the local time of this VI Client.

In ESXi 4.0, you see the message:

Note: The date and time of the host have been translated to the local time of this vSphere Client.

In ESXi 4.1, you see the message:

Note: The date and time of the host have been translated to the local time of this vSphere Client.

Note: For further information on vi or nano, see Editing files on an ESX host using vi or nano (1020302).

Configuring an ESX/ESXi host to capture a VMkernel coredump from a purple diagnostic screen

2011-08-18T20:53:00.002+05:30

Details

This article provides steps for adding a VMKcore diagnostic partition on a local or shared disk post installation.
The diagnostic coredump partition is used to capture the output of a purple diagnostic screen in the event of an ESX or ESXi host failure. A diagnostic partition is automatically created during installation of VMware ESX or ESXi and does not normally need to be created manually. For more information on disk partitioning during an ESX or ESXi installation, see the Installation Guide for your version of ESX or ESXi.
If an ESX or ESXi host has a diagnostic coredump partition active but does not successfully record a coredump to disk during a purple diagnostic screen, there may be a problem with either the storage medium or the connection to the storage medium. To successfully capture diagnostic information from a subsequent outage, create a VMKcore partition on an alternate disk such as local parallel or block devices, iSCSI or Fibre Channel LUN.
To extract contents from the VMKcore diagnostic partition after a purple screen error, see Collecting diagnostic information from an ESX or ESXi host that experiences a purple diagnostic screen (1004128).
Note: VMware ESX can also generate a coredump from the service console Linux kernel. The VMKcore diagnostic coredump partition is used to store the VMkernel coredump, but the service console coredump is placed on a VMFS datastore. Depending on the type of failure, a coredump can be generated from one or both components. For more information, see Configuring an ESX host to capture a Service Console coredump (1032962).

Solution

Listing currently configured diagnostic coredump partition on disk

To display the currently configured diagnostic coredump partition:

Open a console to the ESX or ESXi host, or the location the vSphere Command-Line Interface (vCLI) is installed. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807), Using Tech Support Mode in ESXi 4.1 (1017910) or the vSphere Command-Line Interface documentation.
Retrieve the currently active diagnostic partition using the esxcfg-dumppart command line utility:

esxcfg-dumppart --get-active

The output appears similar to:

mpx.vmhba2:C0:T0:L0:7 /vmfs/devices/disks/mpx.vmhba2:C0:T0:L0:7

Creating and activating a diagnostic coredump partition on disk

To create a new diagnostic coredump partition on disk:

Open a console to the ESX or ESXi host. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807) or Using Tech Support Mode in ESXi 4.1 (1017910).

Note: Diagnostic partitions cannot be created using the vCLI, but existing diagnostic partitions can be activated. For more information, see the vicfg-dumppart command in the vSphere Command-Line Interface documentation.
Select a storage device with at least 100MB of free space that is accessible by the ESX/ESXi host. For more information, see Identifying disks when working with VMware ESX (1014953).
Use the partedUtil command line utility to create a new partition, 100MB in size, with type 0xFC = 252. Take care not to affect other existing partitions on the same disk. For more information, see Using the partedUtil command line utility on ESX and ESXi (1036609).
Use the esxcfg-dumppart command line utility to list all accessible diagnostic partitions. Validate that the list of partitions includes the one created in step 3.

esxcfg-dumppart --list

The output appears similar to:

VM Kernel Name Console Name Is Active Is Configured vmhba1:0:0:0:7 /dev/sda7 no yes
mpx.vmhba2:C0:T0:L0:7 /dev/sdb7 no yes
Set and activate one of the accessible diagnostic partitions using the esxcfg-dumppart command line utility. Either specify a device explicitly, or use the Smart Activate feature to automatically select one of the accessible diagnostic partitions:
- To activate a specific device by its VMkernel name, use the command:
  
  esxcfg-dumppart --set "<VM Kernel Name>"
  
  For example:
  
  esxcfg-dumppart --set "mpx.vmhba2:C0:T0:L0:7"
- To automatically select and and activate an accessible diagnostic partition, use the command:
  
  esxcfg-dumppart --smart-activate
Validate that the diagnostic partition is now active using the command:

esxcfg-dumppart --list

The output appears similar to:

VM Kernel Name Console Name Is Active Is Configured vmhba1:0:0:0:7 /dev/sda7 yes yes
mpx.vmhba2:C0:T0:L0:7 /dev/sdb7 no yes

vmkcore,memory dump,zdump

2011-08-18T20:49:00.002+05:30

Vmkcore (vmkcore)
The core dump partition where the Vmkernal puts memory dump information in the event of a "purple screen of death" or a "kernel panic"

Hostd :

This is the process or daemon for vi connectivity to the ESX server.

core dump partition:

This is the partition created while installing ESX, this partition is used to dump the core's created when the machine PSOD's.

esxcfg-dumppart -l , this command will give you the information of core dump partition.

PSOD:

Purple screen of Death, if any exceptions or asserts are created by any process or memory handlers for MCE (memory check exception) this PSOD is gnenerated, this will bring machine to halt. you have to reboot to bring mahcine to normal state.

Zdump:

this is the core dump file created when machine generates an exception or assert (PSOD).

vmkdump --zdumpname < zdump file >, this command will unzip the core dump generated into human readable file.

vCenter Server installation fails with ODBC and DSN errors

2011-07-29T20:12:00.001+05:30

Symptoms

vCenter Server installation fails
You see the error:
re-configure your DSN to use one of the supported drivers
The VirtualCenter Server service does not start.
If vCenter Server is using Microsoft SQL, the vpxd.log shows the error:
ODBC error: (08001) - [Microsoft][ODBC SQL Server Driver][DBMSLPCN]SQL Server does not exist or access denied
If vCenter Server is using Oracle, the vpxd.log shows one of these errors:
- ODBC error: (HY000) - [Oracle][ODBC][Ora]ORA-01017: invalid username/password; logon denied
- ODBC error: (HY000) - [Oracle][ODBC][Ora]ORA-12541: TNS:no listener

Purpose

During the initial installation of vCenter Server, if you are using a dedicated database server, you are asked to create an ODBC Data Source that vCenter Server uses to connect to the database. If there are changes made to the physical environment, vCenter Server may fail and not start until the information in the Data Source is corrected.

This article provides steps to:

Check which Data Source vCenter Server is using
View and modify the Data Source used for vCenter Server (for both Miscrosoft SQL and Oracle)
Modify the username and password vCenter Server uses to connect to the database server

Resolution

Checking which Data Source vCenter Server is using

To check which Data Source is currently being used for vCenter Server:

Log in to the vCenter Server as an administrator.
Click Start > Run, type regedit, and press Enter.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB.
The name of the Data Source that is currently being used is in the 1 registry key. Make note of this name for use in subsequent steps of this article.
Click File > Exit without making any changes.

Viewing and modifying the database server and/or database used by vCenter Server (Microsoft SQL)

To view or modify the database server and/or database that vCenter Server is configured to use when using Microsoft SQL:

Log in to the vCenter Server as an administrator.
Click Start > Control Panel > Administrative Tools > Data Sources (ODBC). (For vCenter Server 4.0 running on a 64-bit host, Start > Run > %systemdrive%\Windows\SysWoW64\Odbcad32.exe)
Click the System DSN tab.
Select the Data Source that vCenter Server is using, as noted in the previous section of this article.
Click Configure.
On the Configure pane you see the name of the configured database server in the server text box. To change the Database server, type the name or IP address of the new server to be used in this box.
Click Next.
Enter the appropriate login credentials on the next page.

Note: The login information here is not saved, it is simply used for the configuration and testing of the Data Source.
Click Next.
On this pane you see the database that has been configured. To change the database, ensure that the check box for Change the default database to is checked and select the database that you want to use for vCenter Server.

Note: If the database has not been selected, the default database for the account is used. To confirm you have selected the database you need, you must need to login to SQL.
Click Next.
Click Next on the next screen, making no changes.
Click Finish.
Click Test Data Source to verify the information entered.
When the test completes review the information presented and click OK.
If the test was successful click OK to exit the wizard. If the test did not complete successfully, click Cancel and review the information entered to make sure it is valid.
Once the test is successful click OK to exit the ODBC Data Source Administrator window.

Note: For information on modifying the SQL username and password, see Changing the vCenter Server database user ID and password (1006482).

Viewing and modifying the database server and/or database tablespace used by vCenter Server (Oracle)

To view or modify the database server and/or database that vCenter Server is configured to use when using Oracle:

Log in to the vCenter Server as an administrator.
Click Start > Control Panel > Administrative Tools > Data Sources (ODBC). (For vCenter Server 4.0 running on a 64-bit host, Start > Run > %systemdrive%\Windows\SysWoW64\Odbcad32.exe)
Click the System DSN tab.
Select the Data Source that vCenter Server is using.
Click Configure.
On the Oracle ODBC Driver Configuration window, note the TNS Service Name.
Edit the tnsnames.ora file with a text editor. This file is generally located in C:\Oracle\Oraxx\NETWORK\ADMIN (where xx is either 9I or 10g). There is an entry similar to the following, where VPX is the TNS Service name noted in Step 6:

VPX =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=<server>)(PORT=1521))
)
(CONNECT_DATA =
(SERVICE_NAME = <ServerTableSpace>)
)
)
HOST =
In this example, HOST=<server> is the managed host to which the client needs to connect, and SERVICE_NAME = <ServerTableSpace> is the TNS Service name that is being used from the Oracle server.
To change the host that is being connected modify <server>, to the name of the new server that the Data Source connects to.
To change the tablespace that is being used, modify <ServerTableSpace> to the name of the tablespace being used on the Oracle server.
When this is complete, save and close the file.

To confirm that the changes are successful:

Click Start > Control Panel > Administrative Tools > Data Sources (ODBC). (For vCenter Server 4.0 running on a 64-bit host, Start > Run > %systemdrive%\Windows\SysWoW64\Odbcad32.exe)
Click the System DSN tab.
Select the Data Source that vCenter Server is using.
Click Configure.
Click Test Connection.
Enter the username and password, and click OK.
Review the message that is presented. If the change was successful, click OK and exit out of the driver configuration wizard. If the test fails, review and correct the changes to the configuration and try the test again.

Modifying the username and password vCenter Server uses to connect to the database server (Only for 2.5.x and below)

A common misconception is that the username and password used for vCenter Server is stored within the Data Source. The username and password for vCenter Server are stored in the registry. Instructions on reseting the password from the the installer and resetting the password manually are described below.

Note: Ensure that you are using SQL authentication if you are using a Microsoft SQL server because Windows NT authentication is not supported.

To reset the username and password from the Installer:

Log in to the vCenter Server as an administrator.
Click Start > Control Panel > Add or Remove Programs.
Click VMware VirtualCenter Server or VMware vCenter Server from the list of currently installed programs.
Click Change.
Click Next.
Select Repair.
Click Next.
Ensure that the Use an existing database server is highlighted.

Note: If you are using an MSDE or SQL Express installation of vCenter Server, it is setup to use Windows Authentication by default and uses the account the service is set to start with. It is not recommended to change this configuration.
Click Next.
This page is where the is where the new username and password are entered. Ensure that the Data Source name is correct, then enter the new username and password.
Click Next.
Click No when you are prompted with the following message:

The DSN points to an existing VMware VirtualCenter repository. Do you want to reinitialize the database and start over with a blank configuration?

Warning: If you select yes, you overwrite your existing configuration, with a blank new one.
Click Next through the remainder of the installation, leaving the default options selected.
On the Ready to Repair the program screen click Install.
When the repair is complete close out of the installer by clicking Finish.

To reset the username and password manually, without running the installer (Valid for all versions of vCenter Server)

Log in to the vCenter Server as an administrator.
Click Start > Run.
Type regedit.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB.
The user that is configured for database connectivity is in the 2 registry key.
Right-click on the 2 key, and select modify.
Change the Value data to the name of the new user account.
Click OK.
Click File > Exit without making any changes.
Click Start > Run.
Type cmd.
Click OK.
Navigate to the directory in which vCenter Server is installed. In VirtualCenter 2.0.x, it is installed by default in C:\Program Files\VMware\VMware VirtualCenter 2.0\. In VirtualCenter 2.5.x and vCenter Server 4.x, it is installed by default in C:\Program Files\VMware\Infrastructure\VirtualCenter Server\.
Type vpxd.exe -p.
When prompted, enter the new password and press Enter.
Retype the password and press Enter again to complete the password change.

Note: You must change the password through the command line, as it is encrypted in the registry.

Additional Information

If you can log in to the vSphere Client, there is an alternative way to reset the password:

Log in to vCenter Server as an administrator from the vSphere Client.
Click Administration > vCenter Management Server Configuration > Database.
Enter the new password in the Database Password fields.
Click OK.

Note: You need to manually restart the VMware VirtualCenter Server service when this change is made, or reboot the host. This method only allows for you to change the database password. If you need to change the username follow the steps in the article above.

VWARE VCENTER CONVERTER

2011-07-21T17:14:00.000+05:30

services and ports

2011-07-21T13:35:00.000+05:30

THESE SERVICES,PORTS AND PROTOCOLS DEFAULT IN WINDOWS FILES

U CAN FIND THESE FILES IN THIS PATH

C:\Windows\System32\drivers\etc

esx25_SAN_CONFIGURATION

2011-07-21T13:31:00.002+05:30

UDA(ULTIMATE DEPLOYMENT APPLIANCE)

2011-07-21T13:30:00.000+05:30

USING THIS TOOL U CAN DEPLOY MULTIPLE OPERATING SYSTEMS AT TIME

OS: ESX SERVER 3.XX,4.XX
: WINDOWS 2003,XP,2000,WINDOWS 7

U CAN DEPLOY THIS TOOL IN WORKSTAION, AND FOLLOW THE PDF,

CREATE A VIRTUAL MACHINE WITH PXE BOOT(DHCP ENABLED), U CAN NOTICE THE OS AND SELECT WHICH OS U WANT TO INSTALL...............

Best Practices for Java in Virtual Machines on ESX

2011-07-21T13:24:00.003+05:30

Oracle DatabaseVirtualization Strategies

2011-07-21T13:24:00.000+05:30

vmware esxi remote management

2011-07-21T13:23:00.000+05:30

vmware update Manager 4.1 (from vmworld)

2011-07-21T10:56:00.002+05:30

Vmware Troubleshooting doc

2011-07-21T09:52:00.000+05:30

Vcenter issues,
Vclient,
Storage,
Vmtion,
Virtual Machine,

Cannot use iSCSI or NFS over an etherchannel bond switch

2011-07-18T14:42:00.002+05:30

Cannot use iSCSI or NFS over an etherchannel bond switch

Details

If the VMkernel virtual switch has more than one physical network adapter that are plugged into a switche and the uplinks are using Etherchannel, you may experience these symptoms:

Cannot access iSCSI LUNs
The ESX host is using the software iSCSI initiator
Cannot mount NFS volumes
Cannot ping or vmkping the storage processors on the array from the service console of the bonded virtual switch

Solution

This issue may occur if network adapter teaming is set to Route based on the originating virtual port ID. You must change the setting to Route based on ip hash.

To change the network teaming settings to Route based on IP hash:

Log into the ESX host or VirtualCenter using VMware Infrastructure Client.
Select the ESX host.
Click the Configuration tab.
Click Networking.
Identify the virtual switch that is used for storage traffic and click on Properties.
Click on vSwitch.
Click Edit.
Click on NIC Teaming.
Change Load Balancing to Route based on ip hash.
Click OK.
For iSCSI, perform a rescan to detect the LUNs. For NFS, follow the Add Storage wizard. For more information, see Creating an NFS-Based Datastore in the ESX Server 3 Configuration Guide.

Troubleshooting ESXi 4.1 Scripted Install errors

2011-07-15T13:40:00.002+05:30

Purpose

This article provides troubleshooting assistance for ESXi 4.1 Scripted Install issues.

Note: This is not a comprehensive guide on setting up Scripted Install. For more information on setting up Scripted Install, see the ESXi Installable and vCenter Server Setup Guide.

Resolution

Logs

The installer parses a log file before running any of the commands. If there are syntax errors or incorrect command entries, these are displayed by the installer during the parsing phase.

If the Scripted Install breaks at any point during the deployment, the /var/log/weasel.log file (located on the host) may indicate the reason. To check the contents the weasel.log file, press ALT+F1 from the install screen and log in as root with no password.

Caution: Do not reboot the ESXi host after the install fails, or the weasel.log file is lost. Weasel is VMware’s boot loader for ESX/ESXi.

Common errors

This list of errors may help you troubleshoot common Scripted Install issues:

Error 1:
Error (see log for more info):An error has occurred while parsing the installation scripterror:nfs://xxx.xxx.xxx.xxx/mnt/array1/SERVER/scripted/ks.cfg:line 8: The disk (mpx.vmhba1:C0:T0:L0) specified in autopart is too small
To resolve this error, ensure that the boot disk is at least 5 GB (the minimum size required for Scripted Install).
Error 2:
Error (see log for more info)Error copying / downloading fileNFS mount failure for URL nfs://xxx.xxx.xxx.xxx:/install
To get more information about this error:
1. Press ALT+F1.
2. Login as root with no password.
3. Change to the /var/log folder.
4. Read the contents of the weasel.log. You may see an entry similar to:
  2010-01-14 09:37:30.285 INFO NFS source was not already mounted. Mounting....2010-01-14 09:37:30.285 INFO NFS mount failure (Unable to resolve hostname xxx.xxx.xxx.xxx:) for host xxx.xxx.xxx.xxx.xxx:. root /2010-01-14 09:37:30.285 ERROR Could not open file over NFS nfs://10.21.74.192:/install2010-01-14 09:37:30.285 ERROR Exception: Error (see log for more info):Error copying / downloading fileNFS mount failure for URL nfs://xxx.xxx.xxx.xxx:/install
  
  This log entry indicates that the file install does not exist. You must manually recreate the file. For more information, see the ESXi Installable and vCenter Server Setup Guide.
Error 3:
Error (see log for more info):Error connecting to the networkDid not get an IP Address from DHCP server
This error may occur if the ks= command does not contain static IP information and if no DHCP server is reachable or configured. If there is no DHCP server, then you must assign a static address. Scripted Install defaults to DHCP when static addresses are not defined. If there is no DHCP server on the network, then the installer has no way of retrieving files over the network.
Error 4:
The following warnings were encountered while parsing the installation scriptwarning:nfs://xxx.xxx.xxx.xxx:/SI_NFS/ks.cfg:line 5: bootproto was set to static but "--hostname=" was not set. Hostname will be set automatically.
To avoid this warning and ensure a hands-off installation, specify a hostname when setting a static IP. If you do not specify a hostname, this warning continually displays and you have to press Enter each time to complete the installation.

Deploying ESXi 4.1 using the Scripted Install feature

2011-07-15T13:35:00.002+05:30

Purpose

This article provides information on the new Scripted Install feature of ESXi 4.1 Installable.

Resolution

The ESXi 4.1 Scripted Install is a boot script that directs an ESXi host on how it should be configured during installation. The script automates the installation task and ensures that all deployed ESXi hosts are configured the same way.

The Scripted Install feature has these benefits:

It allows you to rapidly deploy ESXi to multiple machines
Configurations can be duplicated to multiple ESXi hosts with minimal manual intervention
Modifying an ESXi configuration is easier and faster because you need to modify only the script file
You can boot the scripted installation with a CD-ROM drive or over the network using PXE booting
It supports scripted installations of ESXi to local and remote disks
All configuration directives initiated by the installation script are logged in the /var/log/weasel.log file of the ESXi host, which helps in troubleshooting deployment issues
The errors and warnings displayed by the installer are elaborate and help in troubleshooting issues

When using Scripted Install, consider these limitations:

Scripted Install is available only with the Installer version of ESXi and is not available in the Embedded version of ESXi
You cannot use Scripted Install to install ESXi Installable to a USB device

Note: For information on setting up ESXi 4.1 Scripted Install, see the ESXi Installable and vCenter Server Setup Guide.

Additional Information

For issues with Scripted Install see Troubleshooting ESXi 4.1 Scripted Install errors (1022308).

Installing VMware Tools fails with the error: Error 1935: An error occurred during the installation of assembly

2011-07-12T22:40:00.002+05:30

Symptoms

Cannot install VMware Tools
Installing VMware Tools fails
You see the error:

Product: VMware Tools -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC80.CRT,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762", processorArchitecture="x86"'. Please refer to Help and Support for more information. HRESULT: 0x8007054F. assembly interface: IAssemblyCacheItem, function: Commit, component: {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E} Activation context generation failed for "c:\program files\microsoft sdks\Windows\v7.1\Bin\guidgen.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.

Resolution

This issue occurs when the Microsoft Installer is unable to find the Microsoft Foundation Classes.

To resolve this issue:

Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
Run this command:

regsvr32 mfc90.dllThis command re-registers the library needed by the installer.

If the installation continues to fail, download and install the Microsoft Visual C++ 2008 SP1 Redistributable Package from the Microsoft Download Center.