Category: VMWare

When creating virtual disks in ESXi there are lots of questions that most people ignore.  90% of the time you can ignore them but a few can really help performance.

 

Device Type

• Create a new virtual Disk
• Use an existing virtual Disk – Used to connect to a shared disk or a disconnected one
• Raw Device Mapping – Raw device direct access to a physical lun – Used in microsoft clustering performance uses etc..

 

Disk-provisioning

• Thick Provision Lazy Zeroed – Space required for virtual disk is allocated at creation time but the disk is zeroed out on demand when requested by the guest operating system (like a fast format in Windows).  Fast creation, fully allocated blocks on datastore, high chance of contiguous file blocks
• Thick Provision Eager Zeroed – Space required for virtual disk is allocated at creation time and every sector of the disk is zeroed during disk creation.  Slow creation, fully allocated blocks on datastore, highest chance of contiguous file blocks
• Thin Provision – Disk only uses as much space as it initially needs.  Fastest creation, Allocated and zeroed out on demand, low chance of contiguous file blocks, uses less disk space

 

Which one do you choose?

Well that depends on your needs.  If performance is your critical issue then Thick provisioned is the only choice.  If you need to save disk space or doubt that your customer will really use the 24TB’s of disk space they have requested then thin provisioned is the choice.  Lazy Zeroed is something between the two.

 

How do I switch?

As of ESXi 5 you have two choices: storage vmotion and inflate.  When initiating a storage vmotion you have the option to choose any of the three options above and convert it.  You can also turn a thin into thick by finding the flat file using the datastore browser and selecting inflate.

 

SCSI Controller type (Only on first disks):

Much like disk type there are many choices:

• BusLogic Parallel

• LSI Logic Parallel

• LSI Logic SAS – Requires Hardware 7 or later

• VMware Paravirtual – Requires Hardware 7 or later

Paravirtual is a physical adapter that requires vmtools drivers in order to use.  Paravirtual adapters provide the best performance but can be only used in new operating systems.  Also they cannot be used on boot devices.   Normally your OS selection handles the best scsi type for you.

 

SCSI Bus Sharing:

When you add a new SCSI Bus you have options on the scsi type but it also gives you the following options (can only be changed when added or vm is powered down)

• None – Virtual disks cannot be shared
• Virtual – Virtual disks can be shared between virtual machines on the same server
• Physical – Virtual disks can be shared between virtual machines on any server

Of course you still need a cluster file system but if you plan on using this system then select Physical.

 

Scsi bus location:

Each virtual machine can have up to 4 scsi buses each with their own controller.  Lots of people have questioned the advantage of multipe buses in vmware.  In traditional hardware you have multiple buses to provide redundancy in case of a bus failure.  This does not apply to virtual hardware.  But it still provides the virtual operating system multiple channels to handle I/O which is always a good thing.

Mode:

• Independent (Not affected by snapshots)
• Virtual (Default)

 

Independent Mode:

• Persistent (Changes are written to disk) – great for databases and other data where a snapshot does not make sense.
• Nonpersistent (Changes to this disk are discared when you power off or revert to the snapshot) – Used on lab computers, kiosks etc..

 

 

Classic question there are all these virtual networking adapter types which one do I choose?  99% of the people you talk to will tell you they let vmware choose when then select the operating system.  This will choose a compatible network adapter type but not always the best type. Gaming and enterprise level servers usually require a few scratches on the head before the run smoothly, but still for better gameplay is better to get one of those fps gaming mouse that give a better time reaction in the game. Each generation of virtual adapter brings better performance and features.  As a rule of thumb you want the highest vmxnet adapter your system supports.  As of ESXi 5 the following adapters are available listed in order preference (worst to best):

 

• Flexible – Has two functions can function as a vlance or vmxnet (will be vlance unless vmware tools is installed)  vlance is an emulated 10Mbps nic available on almost all operating systems.  vmxnet is the first generation of virtualized only network cards and requires vmware tools to be installed.
•  e1000 – is an emulated Intel 82545EM Gigabit ethernet NIC with support in most operating systems.  It is the default adapter for all 64-bit operating systems and is required for guest VLAN tagging.
• vmxnet2 – Updated version of vmxnet that contains VLAN tagging, jumbo frames and hardware off-load with additional high-performance features
• vmxnet3 – Is not really related the vmxnet2 but does represent the next generation of nic drivers it includes all features of vmxnet2 plus multiqueue support, IPv6 offloads, MSI/MSI-X interrupt – this driver has limited OS support requires vmware tools like all vmxnet adapters and requires Esxi hardware version 7 (Esxi version 4 at least)

 

How do I choose?  The best answer is consult vmwares knowledge base for information:

http://kb.vmware.com/kb/1001805

 

Here are some samples:

Vmxnet3

• 32- and 64-bit versions of Microsoft Windows XP,7, 2003, 2003 R2, 2008, and 2008 R2
• 32- and 64-bit versions of Red Hat Enterprise Linux 5.0 and later
• 32- and 64-bit versions of SUSE Linux Enterprise Server 10 and later
• 32- and 64-bit versions of Sun Solaris 10 U4 and later

 

 

For the longest time I always wondered what exactly all those files inside your directory do and their purpose so here is a handy guide:

 

Configuration File -> VM_name.vmx

Swap File -> VM_name.vswp or vmx-VM_NAME.vswp

BIOS File -> VM_name.nvram

Log files -> vmware.log

Disk descriptor file -> VM_name.vmdk

Disk data file -> VM_name-flat.vmdk

Suspended state file -> VM_name.vmss

Snapshot data file -> VM_name.vmsd

Snapshot state file -> VM_name.vmsn

Template file -> VM_name.vmtx

Snapshot disk file -> VM_name-delta.vmdk

Raw Device map file -> VM_name-rdm.vmdk

 

.vmx – Contains all the configuration information and hardware settings for the virtual machine, it is stored in text format.

 

.vswp – is a file that is always created for virtual machines during power on.  It’s equal to the size of allocated ram minus any memory reservation at boot time.   This swap file is used when the physical host exhausts all of its allocated memory and guest swap is used.

 

.nvram – is a binary formated file that contains BIOS information much like a BIOS chip.   If deleted it is automatically recreated when the virtual machine is powered back on.

 

.log – Log files are created when the machine is power cycled the current log is always called vmware.log

 

dvSwitches are great unless you have to add 100 port groups to them with some pattern.  Power CLI can solve that issue.   You have to identify your dvSwitch by right clicking on the switch then you should be able to add port groups from PowerCLI using the output of this snippet of code.  This is desgined to be run from a linux machine with the output to a file which can be run in PowerCLI

#!/bin/bash
i=300
        echo "# ------ Add VLAN $i -----------"
        echo "\$spec = New-Object VMware.Vim.DVPortgroupConfigSpec[] (1)"
        echo "\$spec[0] = New-Object VMware.Vim.DVPortgroupConfigSpec"
        echo "\$spec[0].name =\"VLAN ${i}\""
        echo "\$spec[0].numPorts = 20"
        echo "\$spec[0].defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting"
        echo "\$spec[0].defaultPortConfig.vlan = New-Object VMware.Vim.VmwareDistributedVirtualSwitchVlanIdSpec"
        echo "\$spec[0].defaultPortConfig.vlan.inherited = \$false"
        echo "\$spec[0].defaultPortConfig.vlan.vlanId = $i"
        echo "\$spec[0].type = \"earlyBinding\""
        echo "\$_this = Get-View -Id 'VmwareDistributedVirtualSwitch-dvs-1246'"
        echo "\$_this.AddDVPortgroup_Task(\$spec)"
for (( i=403 ; i <= 704; i++ ))
do
        echo "# ------ Add VLAN $i -----------"
        echo "\$spec = New-Object VMware.Vim.DVPortgroupConfigSpec[] (1)"
        echo "\$spec[0] = New-Object VMware.Vim.DVPortgroupConfigSpec"
        echo "\$spec[0].name =\"VLAN ${i}\""
        echo "\$spec[0].numPorts = 8"
        echo "\$spec[0].defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting"
        echo "\$spec[0].defaultPortConfig.vlan = New-Object VMware.Vim.VmwareDistributedVirtualSwitchVlanIdSpec"
        echo "\$spec[0].defaultPortConfig.vlan.inherited = \$false"
        echo "\$spec[0].defaultPortConfig.vlan.vlanId = $i"
        echo "\$spec[0].type = \"earlyBinding\""
        echo "\$_this = Get-View -Id 'VmwareDistributedVirtualSwitch-dvs-1246'"
        echo "\$_this.AddDVPortgroup_Task(\$spec)"
done
	

So everytime you setup ESX you need to max out your service console memory to 800MB’s this can be done two ways.. the service console or gui both require that you reboot the node after making the change.

Via Service console:

Log in via root and type

1. vmkpcidivy -i
2. Press enter when prompted for the boot image
3. Press enter when prompted for the name of the configuration
4. Type 800mb when asked about memory
5. Press enter to accept defaults until you exit
6. Reboot node

Via gui

1. Goto Inventory
2. Configuration
3. Memory
4. Enter 800mb
5. reboot node