Archive for March, 2010

I just finished installing vSphere ESXi 4.0 update 1, I used all the default settings. I expected that all my portgroups would inherit all their settings from the vSwitch that was configured during installation… unfortunately this is not the case as can be seen in the screenshots below.

Default install with no redundancy:

VM Network inherits from vSwitch:

Management Network does not inherit from vSwitch:

For the default “VM Network” portgroup everything works as expected. But for the “Management Network” it doesn’t. So what’s the problem? Well it might not be a huge issue but it is something you will need to keep in mind. I wanted to add two NICs to my vSwitch0 and expected that both would be marked as “active” on the vSwitch. And this is what happens on the vSwitch, BUT the “Management Network” does not inherit the vSwitch settings so what do you think will happen? Again see the screenshot below for the details:

For some weird reason one of the vmnics is set to “unused” instead of active… Keep this in mind when installing / configuring ESXi as you might end up with less redundancy then expected. I just did a quick search if it was a known/documented change and it appears that I am not the only one who ran into this, but is does not seem to be a commonly known “issue”/change.

Bonding is a way for a linux server with 2 network cards to share a virtual interface which represents both real interfaces. I’m not sure if you get a boost in throughput or if it is only failover. On a redhat ES4 server, all I did was edit these files and reboot (the modules were alredy loadable by the kernel):

ifcfg-bond0 (I made this one, as per instructions)

Snipits (all you need to add before rebooting):

From – modprobe.conf ->

probeall bond0 eth0 eth1 bonding
alias bond0 bonding
options bonding miimon=100 mode=1

From -> ifcfg-eth0


From -> ifcfg-eth1


From -> ifcfg-bond0


vSphere Virtual Machine Upgrade Process

Upgrading a VMware Infrastructure 3.x environment to VMware vSphere 4 involves more than just upgrading vCenter Server and upgrading your ESX/ESXi hosts (as if that wasn’t enough). You should also plan on upgrading your virtual machines. VMware vSphere introduces a new hardware version (version 7), and vSphere also introduces a new paravirtualized network driver (VMXNET3) as well as a new paravirtualized SCSI driver (PVSCSI). To take advantage of these new drivers as well as other new features, you’ll need to upgrade your virtual machines. This process I describe below works really well.

Please note that this process will require some downtime. I personally tested this process with both Windows Server 2003 R2 as well as Windows Server 2008; it worked flawlessly with both versions of Windows. (I’ll post a separate article on doing something similar with other operating systems, if it’s even possible.)

  1. Record the current IP configuration of the guest operating system. You’ll end up needing to recreate it.
  2. Upgrade VMware Tools in the guest operating system. You can do this by right-clicking on the virtual machine and selecting Guest > Install/Upgrade VMware Tools. When prompted, choose to perform an automatic tools upgrade. When the VMware Tools upgrade is complete, the virtual machine will reboot.
  3. After the guest operating system reboots and is back up again, shutdown the guest operating system. You can do this by right-clicking on the virtual machine and selecting Power > Shutdown Guest.
  4. Upgrade the virtual machine hardware by right-clicking the virtual machine and selecting Upgrade Virtual Hardware.
  5. In the virtual machine properties, add a new network adapter of the type VMXNET3 and attach it to the same port group/dvPort group as the first network adapter.
  6. Remove the first/original network adapter.
  7. Add a new virtual hard disk to the virtual machine. Be sure to attach it to SCSI node 1:x; this will add a second SCSI adapter to the virtual machine. The size of the virtual hard disk is irrelevant.
  8. Change the type of the newly-added second SCSI adapter to VMware Paravirtual.
  9. Click OK to commit the changes you’ve made to the virtual machine.
  10. Power on the virtual machine. When the guest operating system is fully booted, log in and recreate the network configuration you recorded for the guest back in step 1. Windows may report an error that the network configuration is already used by a different adapter, but proceed anyway. Once you’ve finished, shut down the guest operating system again.
  11. Edit the virtual machine to remove the second hard disk you just added.
  12. While still in the virtual machine properties, change the type of the original SCSI controller to VMware Paravirtual (NOTE: See update below.)
  13. Power on the virtual machine. When the guest operating system is fully booted up, log in.
  14. Create a new system environment variable named DEVMGR_SHOW_NONPRESENT_DEVICES and set the value to 1.
  15. Launch Device Manager and from the View menu select Show Hidden Devices.
  16. Remove the drivers for the old network adapter and old SCSI adapter. Close Device Manager and you’re done!

If you perform these steps on a template, then you can be assured that all future virtual machines cloned from this template also have the latest paravirtualized drivers installed for maximum performance.

a simple way is to grep it from netstat
netstat | grep nfs

Also if u want to count the connection parapeter

netstat | grep nfsd | wc -l

Redhat – Sort Folder with size

Posted: March 19, 2010 in Redhat

du -skh * | sort -nr

VCDX – Preparation Matarial

Posted: March 15, 2010 in VMware

Please Check the Website . Best for Preparing VCDX

VCDX – Preparation Matarial

Posted: March 15, 2010 in VMware

Please Check the Website . Best for Preparing VCDX