Archive for June, 2010

The last part of Upgrading VMware VI 3.X to vSphere 4 involves upgrading the individual virtual machine (VM) VM tools and virtual hardware. Although guests can still run hosted on ESX 4 if the virtual hardware is not upgraded, there are some great features of Hardware version 7 (v7) that are worth the reboots required.

This post is a summary of my notes and various cut and pastes from several VMware vSphere presentations and documents. I’ve tried to organize them to where the content can be read in a logical flow. I’ve directly copied a lot of this information from the What’s New in vSphere 4.0 VMTN community document, so I’ll just recognize VMware as the provider of this information. Check out the whole document for features and maximums of vCenter and ESX 4 as well.

This VMware slide shows all the configuration maximums for vSphere 4 VMs using v7 hardware.

// //

From the VMTN community document:

Hardware version 7 is the default for new ESX/ESXi 4.0 virtual machines. ESX/ESXi 4.0 will continue to run virtual machines created on hosts running ESX Server versions 2.x and 3.x. Virtual machines that use virtual hardware version 7 features are not compatible with ESX/ESXi releases prior to version 4.0.

Virtual Machine Scalability and Functionality

New Virtual Hardware — ESX/ESXi 4.0 introduces a new generation of virtual hardware (virtual hardware version 7) which adds significant new features including:

  • New storage virtual devices:
    • Serial Attached SCSI (SAS) virtual device for Microsfot Cluster Service — Provides support for running Windows Server 2008 in a Microsoft Cluster Service configuration.
    • IDE virtual device — Ideal for supporting older operating systems that lack SCSI drivers.
  • VMXNET Generation 3 — VMXNET3 is the third generation para-virtualized NIC from VMware. New VMXNET3 features over previous version of Enhanced VMXNET include:
    • MSI/MSI-X support (subject to guest operating system kernel support)
    • Receive Side Scaling (supported in Windows 2008 when explicitly enabled through the device’s Advanced configuration tab)
    • IPv6 checksum and TCP Segmentation Offloading (TSO) over IPv6
    • VLAN off-loading
    • Large TX/RX ring sizes (configured from within the virtual machine)
  • 8-way Virtual SMP — ESX/ESXi 4.0 provides support for virtual machines with up to 8 virtual CPUs allowing larger CPU-intensive workloads to be run on the VMware ESX platform. It is also possible to assign any integer number of virtual CPUs between 1 and 8 to a VM. See the Guest Operating System Installation Guide for a list of guest operating systems that support 8-way SMP.
  • 256GB RAM — Up to 256GB RAM can be assigned to ESX/ESXi 4.0 virtual machines.
  • Enhanced VMotion Compatibility — Enhanced VMotion Compatibility (EVC) automatically configures servers whose CPUs feature Intel FlexMigration and AMD-V Extended Migration technologies to be VMotion-compatible with servers that use older CPUs. ESX/ESXi 4.0 adds additional flexibility when configuring EVC clusters over earlier ESX releases that have EVC support.
  • Virtual Machine Hot Plug Support— The new virtual hardware introduced in ESX/ESXi 4.0 provides support for adding and removing virtual devices, adding virtual CPUs, and adding memory to a virtual machine without having to power off the virtual machine. See the Guest Operating System Installation Guide for the list of operating systems for which this functionality is supported.

The following slides illustrate information about the configurations necessary to hot add virtual hardware.

Ref :

// //

A lot of information about the upcoming 4.0 release of VMware’s Enterprise Virtualization product, vSphere, has been released at VMworld Europe 2009.  I’d like to share some of the exciting new capabilities in this upcoming release.

Virtual Machine Maximums
Virtual CPUs per Virtual Machine – 8
Size of RAM per Virtual Machine – 255GB
NICs per Virtual Machine – 10

ESX Host Maximums
Hosts per Cluster – 32
NFS Datastores per Host – 64
Virtual Machines per Host – 256
Physical CPUs per Host – 64
Logical Processors per Host – 64
Total Cores per Cluster – 4096
Virtual CPUs per Core – 20
Size of RAM per Host – 512GB
Total RAM per Cluster – 32TB
Maximum Network Throughput – 40GB/s (Maximum of 4-10GbE Network Cards per ESX Host)

Ref :

From the  root Console of Scalix , do the following

[root@Server|scalix]#  sxdu -h  | sort -nr  | grep G | more

Hope this Helps.

If you have several Redhat Server and want to have Customize Label on each Shell Prompt for easily Identifying , Do the following .

[root@localhost]#vi /etc/profile

Look for the paragraph like below and edit

for i in /etc/profile.d/*.sh ; do
if [ -r “$i” ]; then
. $i
unset i
unset pathmunge

Then save and exit , logout and log in back again , You will see the shell prompt like this.


Hope This helps..

After transferring and/or trying to restart a VM in ESX you may be presented with the error message “Unable to access a file since it is locked”.

Now what you need to do is work out what is actually locking this file and then (unsurprisingly) find a way to unlock it. Generally the problem will be caused by one of three things.

VMware ESX Unable to  access a file since it is locked

1. Process Lock: There is a process on the ESX server that still has hold of a file(s) used by the VM.  This is one of the most common causes.  To resolve this there have been a couple of good VMware Forum postings here and here that have been consolidated to this useful posting over at (*Note: It is worth checking out the comment by Kent at the bottom of the posting). Also, check out Tecumseh’s posting here.

2. Disk Naming Conflict: Two or more disks with the same VMDK name. This can be caused by another disk with the same VMDK file name being referenced by the VM.  This may have occurred due to a VM move where the VM used have disks located on different LUN’s or similar which have now been moved onto the same LUN and VM directory.  If this is the case rename one of the matching VMDK files (preferably not the one used as the boot drive) and with the VM powered down remove the renamed disk and reattach it (using its new name).

3. Corrupt VMX file: There is a possibility that the VM’s VMX file has corrupted.  You can look through the VMX file and try and troubleshoot the issue though it is quite often quicker to recreate a new VMX file.  This can be achieved by creating a new VM and attaching the existing disks to it (ie: rather than creating a new VM with new a new disk).

So here are three potential problem areas that you may want to consider when getting a “Unable to access a file since it is locked” within ESX.

Solution 3 works for me most of the Time.

Ref :

Error :

I was trying to take snapshot of one of my VM and after a while it is comming up with an error “Canot Take snapshot , Another task in progress”

Solution :

U have tried with server thing according to VM Community but one that works for me to to do the following .

Restart Vmware Management service from ESX console. And it was solved

[root@uesx03]# /etc/init.d/mgmt-vmware restart

VM installation requirements on VMware Workstation:

  • VMware Workstation 6.5.0 build 118166
  • RAM: 2 GB (Minimum)
  • Storage: 12 GB (Minimum)

Click Link for live example.

ESX 4.0 Version/Release:

[root@localhost ~]# uname -a
Linux localhost 2.6.18-92.ESX #1 Sun Dec 14 23:27:11 PST 2008 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost ~]# vmware -v
VMware ESX 4.0.0 build-140815

Reference : akns.wordpress