VMPOOL & TECH BLOG

Symptoms Windows 8 / Windows Server 2012 fails to boot or install on any version of ESXi or ESX Windows 8 / Windows Server 2012 is not working You cannot use Windows 8 / Windows Server 2012 in ESXi or ESX Purpose This article provides information on using Windows 8 / Windows Server 2012 in a vSphere environment. Resolution Like many of you, VMware is becoming familiar with Windows 8 / Windows Server 2012 preview. VMware is testing and enabling the support of Windows 8 / Windows Server 2012 on vSphere. Note : Windows 8 / Windows Server 2012 will not be supported on ESXi/ESX 4.0 or 4.1. Windows 8 / Windows Server 2012 is fully supported for ESXi 5.1. For more information, see What’s New in VMware vSphere 5.1. Consider this guidance, which is based on testing Windows 8 / Windows Server 2012 up to build 8224: Windows 8 Developer Preview / Windows Server 2012 Release Candidate does not boot on ESXi 5.0. To resolve this issue, you must install patch ESXi500-201112001 (Patch

Purpose This article provides the default location of log files on an ESXi 5.0 host. For related information, see the  Logging in vSphere 5.0  in Command-Line Management in vSphere 5.0 for Service Console Users. For other products and versions, see Location of log files for VMware products (1021806). Resolution You can review ESXi 5.0 host log files: From the Direct Console User Interface (DCUI). For more information, see  About the Direct Console ESXi Interface  in thevSphere 5.0 Installation and Setup Guide. From the ESXi Shell. For more information, see the  Log In to the ESXi Shell  section in the vSphere 5.0 Installation and Setup Guide. Using a web browser at  https:// HostnameOrIPAddress /host . For more information, see the  HTTP Access to vSphere Server Files  section in the vSphere Web Services SDK documentation. Within an extracted  vm-support  log bundle. For more information, see Collecting diagnostic information for VMware ESX/ESXi using the vSphere Cl

Symptoms Windows 2000 Terminal Server shows degraded performance when running under ESXi 5.0. Performance Charts for the virtual machine show a much higher CPU usage compared to the same virtual machine running on vSphere ESX/ESXi 4.x. Windows guest operating system task manager shows a very high CPU usage as soon as multiple Terminal Server users are connected. The guest operating system appears to intermittently become unresponsive due to the CPU load. A CPU spike for the System process may occur. Changing the virtual machine's hardware to version 8 or increasing the vCPU count does not resolve the issue. After migrating the virtual machine back to a host running ESX/ESXi 4.x, the virtual machine returns to normal behavior. Cause This behavior is caused by changes to the Binary Translation (BT) Monitor Mode of the VMware Hypervisor in version 5.0. These changes were included to address an issue related to coherency of translated code. Resolution This issue is

Symptoms After upgrading to ESXi 5.0, PXE servers provided by Citrix Provisioning Server report issues while PXE booting a virtual machine. A virtual machine becomes unresponsive during the boot process at: CLIENT MAC ADDR:  xx xx xx xx xx xx If the virtual machine is rebooted from within the guest operating system, the virtual machine fails to PXE boot. However, if the virtual machine is reset or powered off/on, the virtual machine PXE boots correctly. This issue does not occur with earlier versions of ESXi/ESX. This issue may occur on virtual machines regardless of the network adapter (such as  e1000  or  vmxnet3 ). Cause This issue is caused by the mishandling of pending interrupts. Resolution This issue is resolved in vSphere 5.0 Update 1. Note : Before implementing this workaround, confirm with Citrix if the version of Citrix Provisioning Server being used is compatible with vSphere 5.0. To work around this issue, configure the Citrix Provisioning Bootstrap and

Symptoms After installing Windows 8 (64bit) Release Preview or Windows Server 2012 Release Candidate on an ESXi 5.0 Update 1 host or the VMware Workstation Tech Preview, you experience these symptoms:  When starting for the first time after the installation, the virtual machine stops responding and displays a black screen with a white status ring Restarting the virtual machine does not resolve the issue Resolution To resolve this issue, use one of these workarounds: Change the virtual machine to use EFI instead of BIOS. Right-click the virtual machine and click  Power  >  Shut Down Guest. Right-click the virtual machine and click  Edit Settings. Click the  Options  tab. Click  Boot Options. Click  EFI  under Firmware. Click  OK .  Power on the virtual machine. Add  vmGenCounter.enable = FALSE  to the  .vmx  file of the virtual machine. Right-click the virtual machine and click  Power  >  Shut Down Guest. Right-click the virtual machine and click  Edit S

Symptoms The network configuration in the Linux Guest operating system still refers to the original MAC addresses. Mismatch between the MAC addresses in the virtual machine settings and the Linux operating system. Networking does not work in a cloned Linux virtual machine. Cause When a virtual machine is cloned, the network adapter(s) are given new MAC addresses. Resolution To change the MAC address of the Linux operating system:   Redhat Connect the vSphere Client to the vCenter Server. Click the virtual machine. Click  Edit Settings . Click  Network adapter  and take note of the  MAC Address : For example,  00:0c:29:c1:9e:66 Power on the Linux virtual machine. Open a console and log in as root. Change directory to  etc/sysconfig/network-scripts . Edit  ifcfg-eth0  using a plaint text editor and update the MAC address to reflect the MAC address in Step 3. For more information, see  Editing files on an ESX host using vi or nano (1020302) . Activate the e

Symptoms After a storage device has unexpectedly unpresented from the storage array, you are unable to mount it again There was a running virtual machine when storage device went offline ESXi 5.0 host cannot mount the storage after the LUN is online again In the vmkernel log file, you see entries similar to: 2012-02-13T22:47:44.243Z cpu36:5590)Vol3: 1665: Error refreshing FD resMeta: Device is permanently unavailable 2012-02-13T22:47:44.281Z cpu34:5590)VC: 1449: Device rescan time 165 msec (total number of devices 75) 2012-02-13T22:47:44.281Z cpu34:5590)VC: 1452: Filesystem probe time 504 msec (devices probed 48 of 75) 2012-02-13T22:47:44.406Z cpu38:5590)ScsiDevice: 4592: naa.6006016058201700354179be0c6fdf11 device :Open count > 0, cannot be brought online 2012-02-13T22:47:44.654Z cpu34:5590)Vol3: 647: Couldn't read volume header from control: Invalid handle 2012-02-13T22:47:44.654Z cpu34:5590)FSS: 4333: No FS driver claimed device 'control': Not supported 2012-0

Resolution To workaround this issue, boot into the ESXi host's BIOS and disa ble   UEFI (Unified Extensible Firmware Interface) or  EFI. For more information on how to perform this change, consult your hardware vendor. reference http://kb.vmware.com

Purpose This article provides information about running vSphere Command Line Interface (CLI) 4.x commands on ESXi 5.0 hosts. Resolution As ESXi 5.0 is a new architecture with new features, VMware strongly recommends that you use vSphere CLI 5.0 to manage ESXi 5.0 hosts. If you have to use vSphere CLI 4.x, this table outlines support for the commands: Command Support   svmotion.pl Not Supported vicfg-advcfg.pl  Supported vicfg-cfgbackup.pl Supported vicfg-dns.pl Supported vicfg-dumppart.pl Supported vicfg-hostops.pl Supported vicfg-ipsec.pl Supported vicfg-iscsi.pl Not Supported vicfg-module.pl Supported vicfg-mpath.pl Not Supported vicfg-nas.pl Supported vicfg-nics.pl Supported vicfg-ntp.pl Supported vicfg-rescan.pl Supported vicfg-route.pl Supported vicfg-scsidevs.pl Not Supported vicfg-snmp.pl Supported vicfg-syslog.pl Supported vicfg-user Supported vicfg-vmknic.pl  Supported vicfg-vswitch.pl Supported vifs.pl  Supported vicfg-volume Not Su

ESXi 5.0 host stops saving logs to storage Details The ESXi host stops saving log to local storage for various reasons: The local storage is out of space. There is a network or SAN failure or interruption for remote storage locations. The log file is corrupt. There is a disk failure. Solution To resolve this issue, perform one of the following workarounds: Use the following command to inspect the "Log Output" field to find where the directory logs are stored. # esxcli system syslog config get Test the connectivity if the location is a remote datastore (NFS or SAN). Use the following command to determine the amount of free datastore disk space. # esxcli storage filesystem list Inspect the file  /var/log/.vmsyslogd.err  for low-level debugging information. After you identify the cause of the problem, use the following command to reload the syslog server and enable disk logging to continue. # esxcli system syslog reload

Solution Existing VMware Products and Features To support certain internal operations, ESX installations include a subset of standard Linux configuration commands, for example, network and storage configuration commands. Using these commands to perform configuration tasks can result in serious configuration conflicts and render some ESX functions unusable. Always work through the vSphere Client when configuring ESX unless otherwise instructed in vSphere documentation or by VMware Technical Support. Prior to manually moving or copying virtual machine disk files, consider using existing VMware features which can accomplish similar desired results. These VMware features include: Converting Virtual Machines with VMware Converter. For more information, see  VMware Converter Standalone Documentation . Converting Virtual Machines with VMware vCenter Converter. For more information, see  VMware vCenter Converter Administration Guide under the applicable VMware product version . Li

Symptoms In VMware vCenter Server 5.1: You configured a vCenter Server alarm to send alarms when virtual machines are running from snapshots The alarm is falsely triggered even when the virtual machine does not have snapshots You created the  VM Snapshot Size (GB)  alarm in vCenter Server You see false alarms for multiple virtual machines in the inventory Resolution This is a known issue, and is currently being reviewed by VMware. This article will be updated as information becomes available. To work around this issue, disable the  VM Snapshot Size (GB)  alarm in VMware vCenter 5.1. reference http://kb.vmware.com

Purpose This article guides you through the process of increasing the size of a virtual disk. This procedure is necessary to accommodate data requirements that have changed since the creation of the virtual disk. Resolution Important information before you begin Even though this article provides steps to increase the size of your virtual disk, the size of the disk partition does not increase as observed inside the guest operating system. You must follow steps related to your specific operating system to increase the size of the disk partition(s). For more information, see  Increasing the size of a disk partition (1004071) . Caution : VMware recommends that you back up your virtual machine before increasing the size of virtual disks. The procedure for increasing the size of a virtual disk differs between VMware products. Follow the section below that matches your product. In all cases, confirm the following before increasing the size of the virtual disk: All