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

To Rename vSwitch name in a ESX box , Do the following :

logon to your SC(Esx Concole via ssh)  and Edit the file:

change the following line

/net/vswitch/child0001/name = “vSwitch1”

/net/vswitch/child0001/name = “NEWSwitch_name”

save and reboot your ESX Server.

Ref :

To begin a kickstart installation, you must boot the system from a Red Hat Linux boot diskette, Red Hat Linux boot CD-ROM, or the Red Hat Linux CD-ROM #1 and enter a special boot command at the boot prompt. The installation program looks for a kickstart file if the ks command line argument is passed to the kernel.

Boot Diskette
If the kickstart file is located on a boot diskette as described in Section 7.8.1 Creating a Kickstart Boot Diskette, boot the system with the diskette in the drive, and enter the following command at the boot: prompt:

linux ks=floppy
CD-ROM #1 and Diskette
The linux ks=floppy command also works if the ks.cfg file is located on a vfat or ext2 file system on a diskette and you boot from the Red Hat Linux CD-ROM #1.

An alternate boot command is to boot off the Red Hat Linux CD-ROM #1 and have the kickstart file on a vfat or ext2 file system on a diskette. To do so, enter the following command at the boot: prompt:

linux ks=hd:fd0:/ks.cfg
With Driver Disk
If you need to use a driver disk with kickstart, specify the dd option as well. For example, to boot off a boot diskette and use a driver disk, enter the following command at the boot: prompt:

linux ks=floppy dd
If the kickstart file is on a boot CD-ROM as described in Section 7.8.2 Creating a Kickstart Boot CD-ROM, insert the CD-ROM into the system, boot the system, and enter the following command at the boot: prompt (where ks.cfg is the name of the kickstart file):

linux ks=cdrom:/ks.cfg

Other options to start a kickstart installation are as follows:

The installation program will look for the kickstart file on the NFS server <server>, as file <path>. The installation program will use DHCP to configure the Ethernet card. For example, if your NFS server is and the kickstart file is in the NFS share /mydir/ks.cfg, the correct boot command would be

The installation program will look for the kickstart file on the HTTP server <server>, as file <path>. The installation program will use DHCP to configure the Ethernet card. For example, if your HTTP server is and the kickstart file is in the HTTP directory /mydir/ks.cfg, the correct boot command would be ks=

The installation program looks for the file ks.cfg on a vfat or ext2 file system on the diskette in /dev/fd0.

The installation program will look for the kickstart file on the diskette in /dev/fd0, as file <path>.

The installation program will mount the file system on <device> (which must be vfat or ext2), and look for the kickstart configuration file as <file> in that file system (for example, ks=hd:sda3:/mydir/ks.cfg).

Note Note
The second colon is a syntax chane for Red Hat Linux 9.
The installation program will try to read the file <file> from the file system; no mounts will be done. This is normally used if the kickstart file is already on the initrd image.

The installation program will look for the kickstart file on CD-ROM, as file <path>.

Create Privileges

  1. Click “View | Administration | Roles”
  2. Right client and cick “Add”
  3. Select a name and select the required privileges

Create User

  1. Click on the “Users and Groups” tab
  2. Click on the “Users” button
  3. Right click and select “Add”
  4. Specify the desired User Name, Password, etc and Click “OK”

Create a Local Group

  1. Click on the “Groups” button
  2. Right click and select “Add”
  3. Enter the group name you want and enter the User Name you created above in the User Name field and click Add
  4. Click “OK” to create the group

Assign Permissions

  1. Click on the “Permissions” Tab
  2. Right click and Select “Add Permission”
  3. Click on the “Add” button and select the Group you created above and click on the Add button.
  4. Click on the OK button.
  5. Choose the Assigned Role (Priviages) and click “OK”.

Note : You can use the permissions tab in either the main inventory (main page) or per Virtual Machine. This is useful to know if you need to allow one user to access just one Virtual Machine.