Configuring an ESX host to display FQDN instead of IP address in vCenter without losing performance data

Purpose

This article provides steps for displaying an ESX host's Fully Qualified Domain Name (FQDN) instead of its IP address in the vCenter Inventory without losing performance data for the ESX host while making the change.

Resolution

To configure an ESX host to display the FQDN in the vCenter inventory:

1. Disconnect the ESX host from the Inventory in vCenter. Do not remove it from the Inventory.
2. Log in to the ESX host as root using an SSH client. If login with an SSH client is not possible, log in to the physical console of the ESX host as user root.
3. Delete the vpxuser account with the command:
   
   userdel vpxuser
   
   Note: The vpxuser account facilitates communication between the ESX host and vCenter. It is created again when the ESX host is connected back to the Inventory in vCenter.
   
   
4. Right-click on the ESX host in vCenter and choose Connect.
   
   In vCenter Server 4.0 the following error displays:
   
   Cannot complete due login due to an incorrect username or password
   
   In vCenter Server 2.5 the tasks show the error:
   
   Login failed due to a bad username or password
   
   These messages can be safely ignored.
   
   
5. Enter the FQDN for the ESX host and login credentials for the root user to add the ESX host to the Inventory in vCenter using its FQDN.

Excessive logging for SNMP in the ESX host messages log

Symptoms

• /var/log/messages contains excessive messages similar to:
  
  snmpd[xxxxx]: Received SNMP packet(s) from UDP: [127.0.0.1]:xxxxx

Resolution

This is expected behavior and is normal for a default installation of RedHat net-snmp that is installed on ESX hosts. The agent is configured for this level of logging as a security measure.

Although VMware does not recommend changing the default logging level, you can avoid this excessive logging.

To avoid excessive logging:

1. Log in to the ESX Server service console as the root user.
2. Edit the /etc/init.d/snmpd file in a text editor.
3. Modify the OPTIONS line in the file from:
   
   OPTIONS="-s -l /dev/null -P /var/run/snmpd -a"
   
   to:
   
   OPTIONS="-s -l /dev/null -P /var/run/snmpd"
   
   
4. Restart the snmpd service by running:
   
   service snmpd restart.

Cannot launch VMware Fusion 1.x when using Snow Leopard

Symptoms

You may experience these symptoms:

• Fusion 1.x does not launch under Mac OS 10.6 (Snow Leopard) or higher
• You receive the following error:
  
  unrecoverable error (vcpu-0 NOT_IMPLEMENTED bora/devices/mainmem/mainMEM hosted.c:1967)
  

Resolution

Fusion 1.x is not supported with Mac OS 10.6 (Snow Leopard) or higher.

VMware recommends performing a free upgrade to Fusion 2.x. This allows you to continue to use you virtual machines, as well as providing the latest feature and performance enhancements present in the update.

How to configure VMware Tool to dual boot Operating System

Details

This article applies to the following operating systems:

• SUSE Linux 8.2, 8.1, and 8.0
• Mandrake Linux 9.2, 9.1, 9.0, and 8.2
• Red Hat Linux 7.3

You can choose to dual boot your Linux operating system while installing VMware Tools. When you start installing VMware Tools by typing ./vmware-install.pl in the vmware-toos-distrib directory, the following message appears:

Found an installed version of the VMware SVGA driver for XFree86 4. Some versions of this driver included with the XFree86 4 distributions do not work properly. Would you like to install a stable (but possibly older) version of the driver over the currently installed one?

Solution

If you plan to dual-boot the virtual machine, type Yes to allow the driver to be installed. Type Yes again to back up the existing video driver files and also copy the XF86Config-4.dist file to XF86Config-4.vm. The latter file is used when dual-booting the virtual machine.

If you do not intend to dual-boot the virtual machine, type No to keep the existing driver.

Vmware error: Failed to create lun snapshots

VMware Site Recovery Manager TestFailover task fails with the error: Failed to create lun snapshots

Symptoms

• A TestFailover operation on VMware Site Recovery Manager (SRM) configured with IBM SAN Volume Controller (SVC) storage fails
• You see the error:
  
  Non-fatal error information reported during execution of SRA: Failed to create lun snapshots.
  
  
• The vmware-dr-X.log file on the VMware SRM server contains the errors:
  
  [#3] [ Thu Aug 27 10:45:05.628 testFailover trivia ] Acquiring lock...
  [#3] [ Thu Aug 27 10:45:05.753 testFailover trivia ] testFailover::ControllerConfigurationService
  [#3] [ Thu Aug 27 10:45:05.768 testFailover trivia ] testFailover::exposePaths()
  [#3] [ Thu Aug 27 10:45:05.784 testFailover trivia ] Attach Volumes returned: 4097
  [#3] [ Thu Aug 27 10:45:05.784 testFailover trivia ] Releasing lock...
  [#3] [ Thu Aug 27 10:45:05.784 testFailover Error ] 1 unmask failed
  [#3] [ Thu Aug 27 10:45:05.800 testFailover trivia ] testFailover::IBMTSSVC_HardwareIDStorageVolumeView
  [#3] [ Thu Aug 27 10:45:05.800 testFailover Error ] testFailover::createSVCFC(): 203
  [#3] [ Thu Aug 27 10:45:05.800 testFailover trivia ] Exit failoverTest End(): 203
  [#3] [ Thu Aug 27 10:45:05.800 testFailover trivia ] End testFailover::createSVCFC()
  [#3] [ Thu Aug 27 10:45:05.800 testFailover trivia ] End testFailover::getArrayTypeAndInfo()
  
  [2009-08-27 10:45:05.862 01836 error 'SecondarySanProvider'] testFailover's errors:
  java.lang.StringIndexOutOfBoundsException
  [#3] at java.lang.String.substring(String.java:1088)
  [#3] at testFailover.createSVCFC(testFailover.java:967)
  [#3] at testFailover.getArrayTypeAndInfo(testFailover.java:207)
  [#3] at testFailover.main(testFailover.java:163)
  .
  .
  [2009-08-27 10:45:05.862 01836 warning 'SecondarySanProvider'] Skipping replica LUN '0' without WWN, host numbers, or NFS name
  [2009-08-27 10:45:05.862 01836 info 'SecondarySanProvider'] Return code for testFailover: 203
  .
  .
  [2009-08-27 10:45:05.862 01836 error 'SecondarySanProvider'] No shadow LUNs found in testFailover/start output
  [2009-08-27 10:45:05.862 01836 verbose 'SecondarySanProvider'] Deleting lun snapshots
  .
  .
  
  [#3] [ Thu Aug 27 10:45:10.143 testFailover Error ] The CIMOM may not be functioning correctly.CIM_ERR_FAILED
  
  [2009-08-27 10:45:10.237 01836 error 'SecondarySanProvider'] testFailover's errors:
  org.sblim.wbem.cim.CIMException: CIM_ERR_FAILED; nested exception is:
  [#3] java.lang.NullPointerException
  [#3] at org.sblim.wbem.client.CIMClientXML.invokeMethod(CIMClientXML.java:778)
  [#3] at org.sblim.wbem.client.CIMClient.invokeMethod(CIMClient.java:2142)
  [#3] at testFailover.deleteSVCFC(testFailover.java:1218)
  [#3] at testFailover.getArrayTypeAndInfo(testFailover.java:210)
  [#3] at testFailover.main(testFailover.java:163)
  [#3] Caused by: java.lang.NullPointerException
  [#3] at org.sblim.wbem.xml.CIMXMLBuilderImpl.createINSTANCENAME(CIMXMLBuilderImpl.java:828)
  [#3] at org.sblim.wbem.xml.CIMClientXML_HelperImpl.invokeMethod_request(CIMClientXML_HelperImpl.java:552)
  [#3] at org.sblim.wbem.client.CIMClientXML.invokeMethod(CIMClientXML.java:734)
  [#3] ... 4 more
  .
  .
  [2009-08-27 10:45:10.237 01836 verbose 'BeginImageTest-Task'] Error set to (dr.san.fault.ExecutionError) {
  [#3] dynamicType = ,
  [#3] faultCause = (vmodl.MethodFault) null,
  [#3] errorMessage = "Failed to create lun snapshots",
  [#3] msg = "",
  [#3] }

Resolution

This issue occurs if a single IBM SVC Console is used to manage both the protected SVC cluster and the recovery SVC cluster.

To resolve this issue, when deploying VMware vCenter SRM with IBM SVC, use a unique SVC Console to manage the protected site and another unique SVC console to manage the recovery site. For more information, see IBM SVC documentation.

If you experience this issue, snapshots on the recovery site SVC may not be cleaned up. You may have to manually log in to the recovery SVC to remove the FlashCopy of the protected LUN.

1. Log in to the recovery IBM SVC using the PuTTY utility on the SVC console.
2. Unpresent the FlashCopy VDisk from the recovery site ESX with the command:
   
   svctask rmvdiskhostmap
   
   
3. Stop the flashcopy between the replicated VDisk and the FlashCopy VDisk with the command:
   
   svctask stopfcmap
   
   
4. Remove the FlashCopy map with the command:
   
   svctask rmfcmap
   
   
5. Remove the FlashCopy VDisk with the command:
   
   svctask rmvdisk

Right Virtual Ethernet Card for Guest Operating System

Choosing a network adapter for your virtual machine

Details

The virtual machine configuration window for network connection allows you to specify a network and a network adapter. The network adapter choices that are available depend on the virtual machine version number and the guest operating system running on the virtual machine.

The Choose Networks window makes available only those network adapters that make sense for the virtual machine you are creating.

Solution

Available Network Adapters

The following network adapters might be available for your virtual machine, depending on the factors discussed above:

• Vlance — An emulated version of the AMD 79C970 PCnet32 LANCE NIC, an older 10 Mbps NIC with drivers available in most 32bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
  
  
• VMXNET — The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
  
  
• Flexible — The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
  
  
• E1000 — An emulated version of the Intel 82545EM Gigabit Ethernet NIC, with drivers available in most newer guest operating systems, including Windows XP and later and Linux versions 2.4.19 and later.
  
  
• VMXNET 2 (Enhanced) — The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESX/ESXi 3.5 and later.
  
  VMXNET 2 is supported only for a limited set of guest operating systems:
  • 32 and 64bit versions of Microsoft Windows 2003 (Enterprise and Datacenter Editions). You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in VMware Infrastructure (VI) Client or vSphere Client. See Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195) if Enhanced VMXNET is not offered as an option.
  • 32bit version of Microsoft Windows XP Professional
  • 32 and 64bit versions of Red Hat Enterprise Linux 5.0
  • 32 and 64bit versions of SUSE Linux Enterprise Server 10
  • 64bit versions of Red Hat Enterprise Linux 4.0
  • 64bit versions of Ubuntu Linux
    
    
• VMXNET 3 — The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery.
  
  VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:
  
  • 32 and 64bit versions of Microsoft Windows XP and later
  • 32 and 64bit versions of Red Hat Enterprise Linux 5.0 and later
  • 32 and 64bit versions of SUSE Linux Enterprise Server 10 and later
  • 32 and 64bit versions of Asianux 3 and later
  • 32 and 64bit versions of Debian 4/Ubuntu 7.04 and later
  • 32/64bit versions of Sun Solaris 10 U4 and later

Adapter Caveats

This section discusses some potential problems you might have.

• Migrating virtual machines that use enhanced vmxnet
  
  VMXNET 2 is new with ESX 3.5 virtual machines configured to have VMXNET 2 adapters cannot migrate to earlier ESX hosts, even though virtual machines can usually migrate freely between ESX 3.0 and ESX 3.0.x.
  
  I f you must migrate a virtual machine between later and earlier hosts, do not choose VMXNET 2.
  
  
• Upgrading from ESX 2.x to ESX 3.x
  
  When a virtual hardware upgrade operation transforms a virtual machine created on an ESX 2.x host to an ESX 3.x host, Vlance adapters are automatically upgraded to Flexible. In contrast, VMXNET adapters are not upgraded automatically because most or all Linux guest operating system versions do not reliably preserve network settings when a network adapter is replaced. Because the guest operating system thinks a Flexible adapter is still Vlance, it retains the settings in that case. If the upgrade replace a VMXNET adapter with a Flexible adapter, the guest operating system erroneously discards the settings.
  
  After the virtual hardware upgrade, the network adapter is still VMXNET, without the fallback compatibility of the Flexible adapter. Just as on the original earlier host, if VMware Tools is uninstalled on the virtual machine, it cannot access its network adapters.
  
  
• Adding virtual disks
  
  Adding an existing earlier (ESX 2.x) virtual disk to an ESX 3.x virtual machine results in a de-facto downgrade of that virtual machine to ESX 2.x. If you are using ESX 3.x features, such as enhanced VMXNET or Flexible network adapters, the virtual machine becomes inconsistent. When you add an existing ESX 2.x virtual disk to an ESX 3.x machine, immediately use the Upgrade Virtual Hardware command to restore the virtual machine to the ESX 3 version. This problem does not arise when you add earlier virtual disks to an ESX/ESXi 4.0 virtual machine.
  
  Note: Executing Upgrade Virtual Hardware changes the ESX 2 virtual disk so that it is no longer usable on an ESX 2 virtual machine. Consider making a copy of the disk before you upgrade one of the two copies to ESX 3 format.

Disk/LUN not available showing in Storage Wizard

No available Disk/LUNs showing in Add Storage Wizard

No available Disk/LUNs showing in Add Storage Wizard

Details

When attempting to create a new datastore, no disks or LUNs are showing in the Add Storage Wizard.

Solution

Follow the steps below to pinpoint and resolve the problem.

1. Rescan the host to ensure storage information is up to date.
   1. Select the appropriate host in the vSphere/VMware Infrastructure Client.
   2. Click the Configuration tab.
   3. Click Storage Adapters.
   4. Click Rescan.
      
2. Verify the targets are visible.
   1. Click the HBA that should be able to see the LUNs.
   2. Look in the bottom half of the screen for the presentation information.
   3. Verify targets are accessible.
   4. Verify the LUNs are accessible.
      
      
3. If the LUNs are accessible, complete the Add Storage wizard, otherwise continue to step 4.
   
4. Ensure the HBAs are zoned correctly. The following command will show you which ports the HBAs are logged in to.
   
   • QLogic HBAs:
     # cat /proc/scsi/qla*/* | grep -A16 "FC Port Information"
     
   • Emulex HBAs:
     # cat /proc/scsi/lpfc/* | grep "DID"
     
   • If the HBA is not logged into a port on the array, verify physical connectivity and switch zoning.
     
     
5. If you are using Qlogic HBAs, you can view the presented LUNs directly from the HBA with the following command:
   #cat /proc/scsi/qla*/* | grep -A2560 "SCSI LUN Information"
   
   
   Otherwise, search the VMkernel log for the LUN(s). Replace x with the LUN number in question:
   1. Rescan the host to ensure updated information is in the VMkernel log
      #egrep "vmhba[0-9]*:C[0-9]*:T[0-9]*:Lx" /var/log/vmkernel
      
      
   2. Verify the LUN is detected, and is reporting VPD pages. You see hex output similar to:
      vmkernel: VMWARE SCSI Id: Supported VPD pages for vmhba2:C0:T0:L4 : 0x0 0x80 0x83 0xc0 0xb0 0xc1
      vmkernel: VMWARE SCSI Id: Device id info for vmhba2:C0:T0:L4: 0x1 0x3 0x0 0x10 0x60 0x8 0x5 0xf3 0x0 0x12 0x4a 0x90 0x6 0xd5 0xbb 0xde 0xb0 0x8b 0x0 0x2a 0x1 0x0 0x0 0x4 0x0 0x0 0x0 0x0 0x2 0x3 0x0 0x20 0x36 0x30 0x30 0x38 0x30 0x35 0x46 0x33 0x30 0x30 0x31 0x32 0x34
      
6. Confirm the LUN number is between 0 and 255.
   • If you see output similar to the above, the LUN is detected. Go through the Add Storage Wizard. If you do not see any output above, the LUN is not presented correctly.
   • Work with your storage team to have the LUN presented correctly. If the LUN is still not detected, please contact your switch and/or array vendor for assistance with zoning or presentation (as appropriate based on the output from steps 4 and 6.
   • If the LUN is showing as presented in step 6, but is not accessible in the Add Storage Wizard, contact file a support request.

How to disable IPV6 in Vmware ESX

How to Disable IPv6 for Vmware ESX

Details

In many Linux distributions if IPv6 is enabled, VMware Tools cannot be configured with vmware-config-tools.pl after installation. In this case, VMware Tools is unable to set the network device correctly for the virtual machine, and displays a message similar to the following:

Unloading pcnet32 module
unregister_netdevice: waiting for eth0 to become free

This message repeats continuously until you reboot the virtual machine. To prevent this problem in virtual machines running Linux, disable IPv6 before installing VMware Tools.

Note: VMware ESX 4.0 and later versions support IPv6. You do not need to disable IPv6 before installing VMware Tools.

Solution

Most Linux Systems:

To disable IPv6 in a virtual machine running Linux

1. If the /etc/sysconfig/network file contains the line NETWORKING_IPV6=yes, change the line to the following:

   NETWORKING_IPV6=no

2. In the file /etc/modules.conf, add the following lines:

alias ipv6 off

alias net-pf-10 off

Ubuntu Systems:
To disable IPv6 in a virtual machine running Ubuntu

1. Log on as root or superuser.
2. If the /etc/modprobe/aliases file change the following line :

   alias net-pf-10 ipv6

   to

   alias net-pf-10 off

3. Save the file and reboot the system.

After you disable IPv6, you should be able to install and configure VMware Tools successfully.