Posts Tagged ‘VMware’

VMWorld 2012 – performance, new features and best practices

October 9th, 2012 No comments

Just rushed into hall B2 , going to go through performance enhancements in vSphere 5.1. Ignore typos please – typing in an iPad and autocorrect is not the most uhhh tech friendly tool…

VSphere 5.1 targets
Big data
Low latency
Monster apps
Large scale deployments
View and vCloud director environments.

Big Data:
Monster VMs mean:
64vCpus (who does this with a Vm?)
1TB Ram (again – surely this would justify a physical?)
VMWare have managed to more than 1 million IOPs out of a single VM (cool and ridiculous)

Big new addition – exposure of new CPU counters in new techs like ivyBridge, SandyBridge and PileDriver

Low latency:
New dropdown available to label VMs as latency sensitive (VM behave accordingly) – use with caution . . And do NOT let the business know about this. Prioritises access to resource, but if overused, loses its effectiveness.

Platform recommendations:
Size VMs correctly
Use resource settings only if needed
Avoid affinity possible
Over provisioning is fine great!
Hyper threading is GREAT – use it.
Double check bios and power management settings

Reduced memory overhead:
VSphere 5.1 allows for swap file creation to reduce memory reservation for backed processes – saving about 1GB per host.
Can be configured from web client under system volumes – edit system swap settings.
Overcommit to about 20% as a guideline. Make sure to use ballooning, transparent page sharing, memory compression, host cache swapping and ESX or guest Level swapping.
When you start seeing the swapping use go up – reduce overcommitte.
Sizing VMs – use reservations as needed and try keep memory within NUMA domain.

Memory – consumed vs active:
Consumed – physical memory used by VM (good measure of actual usage at point in time)
Active is the amount recently touched.

Storage IO control enhanced in vSphere 5.1:
VSphere 5.1 can use percentage based thresholds instead of absolute latency values – this means better throughput on both slow storage as well as low latency for low latency storage,
SIOC monitors and controls the full storage stack latency

Storage DRS enhancements:
Interoperability with vCloud Director – including linked clone (with vCloud only)
Storage DRS correlation detector (so we won’t automatically move storage between data stores that are actually hosted on the same spindles – which would have no benefit)
Can be used with Auto-Tiering – but you would need to follow the storage vendor’s best practice.

Storage performance:
Now support 16Gb CPU – which has lower CPU cost / efficiency.

Jumbo Frames best case throughput improved by:
Hwscsi read 88% write 20%
Swscsi read 11% write 40%
NFS. Read 9% write 32%

Storage best practices:
Size accordingly and keep latency below 30ms
Snapshots are not free!
Use sioc and sdrs
Update storage firmware
Remember the old tricks (multipathing, block size, alignment, paravirtulaised scsi etc)

Networking virtualisation:
New features – VDS snapshots(snapshot your switch’s config), auto-Rollback of configs, port mirroring and net flow enhancements)

Use VDS – Network IO control (eg don’t let a vMotion kill the mic for everyone else)

New feature: SR-IOV – allow one nic to be presented as multiple separate logical adapters. This allows us to allow multiple VMs to directly use the physical NIC – reducing latency.

VXLAN – new feature
Deploy VMs where resources are available, then create a gigantic layer 2 network, making access ‘local’ – possibly a great tool for getting max use out of geographically dispersed vSphere networks that run business hours only – e.g. NY / London office

Networking best practice:
Be mindful of converged networks
Use distributed virtual switches

VMotion enhancements:
Shared nothing migration – no shared storage required and still able to migrate host and storage at the same time (cool)
Parallel storage vMotion – so we do a storage vMotion of a VM with 4 disks – possibly separated by affinity etc. this allows the copies of up to 4 vmdks at the SAME time (previously, copies were sequential) – there is only benefit when the vmdks are moving from different data stores, to different data stores.

vMotion best practices:
Use the latest version of vmfs. (5.x)
Keep vmknics on same subnet
Separate vmknics across multiple vmnics. VMotion will load balance the traffic

vCenter enhancements:
Web client WITH SSO
Wb client supports 300 concurrent connection
Can collect up to 80 million stats per hour – so max logging (level 4) for an environment of 1000 hosts, with 2000 data stores and 15000 VMs!

VCenter best practices:
Size correctly
Size the db correctly
Keep an eye logging levels, DB performance and networking connectivity between VC, DB hosts etc.
VM or physical is ok
32 hosts per cluster
Use resource pools and affinity rules in clusters as needed.

Categories: VMWare, VMWorld Tags:

Troubleshooting VMware issues with MindMaps

April 7th, 2011 No comments

The guys on VMTN have released a few new mindmaps to help with various bits of troubleshooting.
Initially, I thought, great, another flowchart . . but I run a few scenarios through my lab, thinking that instead of troubleshooting myself, I would simply follow the mind map and I was surprised at how well they cover the kind of problems we see both regularly on our various environments and also how well they cover issues that I regularly see on the VMware communities site.

Oddly, I had never spotted these before – but it seems there are a bunch available at

Below are the 4 that I figure are going to be most pertinent in current environments – a very hany tool indeed.

Mindmap – vSphere Troubleshooting Network Issues
Mindmap – vSphere Troubleshooting Management Issues
Mindmap – VMware Troubleshooting View Management Issues
Mindmap – VMware Update Manager Issues

What I really like about these is not simply that they produce a ‘flow chart’ for troubleshooting, but the fact that once you get to the lowest level on the mind map, there is a little infinity sign that you can click on – which takes you to a knowledge base article for each solution. this means that just about anyone, no matter what their level, can use these

Categories: VMWare Tags:

Upgrading ESXi without VUM / From the Cli

March 24th, 2011 No comments

It seems that VMWare are getting rid of VUM (I assume something new will be released soon to replace it), so more and more people are going to need to manage ESXi upgrades from the command line.
I suspect that the people that will be most affected by this are people running the free version of ESXi.

Anyway, here is a quick how to, for ESXi upgrades.

First enable ssh access to the ESXi4.0 box. – (more info here)

At the ESXi console:
1. alt-f1
2. Type unsupported (You will not see your typing)
3. root pw
4. vi /etc/inetd.conf
5. uncomment the 2 ssh lines, i.e delete the “#” preceding the ssh config lines (esc x to delete a character in vi)
6. :wq to save the changes in vi and quit the vi editor
7. restart (if necessary reboot the ESXi box if ssh still does not work)

If you are running ESX4.1, follow this guide to enable SSH access to ESXi4.1 Host
(again at the console)

1.Press F2 to Customize System Settings
2.Navigate to Troubleshooting Options
3.Select ‘Enable remote Tech support (SSH)

Note – you can also adjust the tech support timeout here – so you could limit how long tech support stays enabled for.

Next, you will need to download your upgrade bundle from VMWare –

You now have 2 Options,

Run the installation – Option 1 – from a webserver
If you are able to store the upgrade bundle on a webserver, you could do the following:
Place the file at the root directory of your web server.
I use Apache Tomcat 7.0 on Windows XP to host the file
Ensure the Windows Firewall allows access from external hosts to your web server (In the case of Apache Tomcat, I had to open port 8080)
VMotion all the VMs off of you host, or Shut down all VMs, and put the host into maintenance mode.
SSH to your ESXi4.0 box and at the CLI type:
esxupdate –bundle http://ipaddress:8080/ update (Of course this value will change dependent on your filename)
The zip file will be downloaded from your web server and installed. Reboot the ESXi server when prompted.

Run the installation – Option 2 – from a local instance of the upgrade bundle
If you do not have a web server handy, you could copy the bundle locally on the ESXi host. – or even on a shared datastore accessed by multiple ESXi hosts if you have shared storage.
Using FastSCP(my preference, but any SCP style tool will work e.g. WinSCP) – Copy the upgrade bundle to the ESXi host(or shared store)
VMotion all the VMs off of you host, or Shut down all VMs, and put the host into maintenance mode.
SSH to the host (I use putty, but any SSH tool will work)
From the command line of the host, execute the command: esxupdate –bundle /vmfs/volumes/<datastorename>/<myfolder>/ update
The zip file will be extracted and installed

Reboot the host
Reboot the host when done. Once that’s complete, take the host back out of maintenance mode, and power on the virtual machines.
You’ll possibly have new VMtools available, so upgrade these.

If your host refuses to start up and you are having issues, you should be able to revert to your previous installation by hitting Shift-R as the host boots up.

Categories: VMWare Tags: ,

Finding VMs with disks on multiple different datastores – Script of the Day

March 23rd, 2011 No comments

I was looking at a VM on one of our hosts and noticed the rather odd configuration showed that the VM had 2 disks provisioned (not unusual), and that the 2 disks had been presented on different storage (very unusual for non clustered VMs in our environment)

I figured, the easiest way to identify all of the VMs that are using VMDKs on multiple different datastores was PowerCli.

The result – just a one liner.

PS:7 >get-vm | ?{$_.DatastoreIdList.count -gt 1}

Name                 PowerState Num CPUs Memory (MB)
----                 ---------- -------- -----------
labserver001     PoweredOn  1        8192
labserver 17a         PoweredOn  2        1280
labserver21        PoweredOn  1        8192
labserver17b         PoweredOn  2        1152

How to Migrate and Convert Physical RDMs

March 21st, 2011 No comments

Ken Gottleib, the Principle Virtualization Consultant at Winchester Systems, Inc. USA recently posted the following very useful bit of info over on the VMWare communities site.

I quickly dropped him a note and asked for permission to duplicate his work, as I have had this same issue before and never documented the process properly.

“This is what you need to do, fully explained the way each and every post should be. You must power the VM down to do this, there is no way to do it live. Period

1) log into ESX console as root
2) navigate to your virtual machine folder: /vmfs/volumes/vmfs-volume-freindlyname/vm-folder/
3) locate the pointer file for your disk, this is not the -rdmp file, this is the servername_1.vmdk, it is only a few KBs, inside it does nothing but point to the actual disk file, which in this case will be the servername_1-rdmp.vmdk. It is this servername_1-rdmp.vmdk file that maps IO to the actual lun which is always represented by ESX as something like vml.xxxxxxxxxxxxxxx and can be viewed in /vmfs/devices/disks/

The source you are looking to migrate (with this method it is actually a copy which is good, because the source is always left intact) can be a virtual disk, virtual rdm, or physical rrdm, it doesnt’ matter, you will always use the servername_x.vmdk file as the source in the command string you are about to see… but before I continune, if you want to migrate from physical compatibility mode lun to a new physical compatibility mode lun, be sure to have provisioned the lun so ESX can see it. If you are to convert the physical mode RDM to virtual RDM, the same applies. If you are to convert it to virtual disk, just be sure you have a vmfs volume with enough space to accomodate the new disk.

4) here it is:
To migrate and convert physical RDM to virtual disk:
vmkfstools -i servername_1.vmdk /vmfs/volumes/vm folder/servername-newdisk_1.vmdk
To migrate and convert physica RDM to virtual RDM, there are two methods
– in vi client edit VM settings of powered down VM, remove rdmp mapped disk, then re-add a new hard disk selecting the same disk only be sure to select virtual as the mode, you will log in and see all of your data and mount points are unchanged.
– from the ESX prompt in the virtual machine folder on the VMFS volume:
vmkfstools -i servername_1.vmdk -d rdm:/vmfs/devices/disks/vml.xxxxxxxxxxxxxxxxxxxxxxxx /vmfs/volumes/vm folder/servername_1-rdm.vmdk
To migrate physica RDM to a new physical RDM:
vmkfstools -i servername_1.vmdk -d rdmp:/vmfs/devices/disks/vml.xxxxxxxxxxxxxxxxxxxx /vmfs/volumes/vm folder/servername_1-rdmp.vmdk

Command strings EXPLAINED:
vmkfstools -i is the import \ clone command
the servername_x.vmdk is the source, the x will stand for the order of the device, in my example I use 1 which means this is the second disk on the VM. the first disk file is servername.vmdk, this is typically always the system disk.
the -d is the disk type for the destination you are converting to
the rdm(p) is part of the disk type telling the destination disk what the raw disk mode is, virtual or physical (the p means physical obviously)
the /vmfs/volumes/vm folder/servername_1-rdm.vmdk tells us the location of where to store the raw disks mapping file, I have chosen to put it in the virtual machine folder as you can see, you can put it on any vmfs file system, I like to keep things neat and clean.

Figuring out which vml.xxxxxxxxxxxxxxx is tricky.. I the ls-lh command on the /vmfs/devices/disks/ directory to list the unfriendly volume names out and figure out which one is mine by the LUN size, there are other ways to do this, there is a VMware KB article that describes other ways to dump out this information. and in some cases, depending, there may be a partition involved and it would look like vml.xxxxxxxxxxxxxxxx:1 or :2 or whatever.. vmware’s KB references it as vml.xxxxxxxxxxxx:p
you can also use vmhbax:x:x: in the string as such: /vmfs/devices/disks/vmhbax:x:x:p to represent the raw LUN
check out this article, it has what you need, but not everything.. the example they use for the disk is naa.xxxxxxxxxxxxxxxxx and I believe this is because there is different storage in use then I have… SO, be sure to navigate to /vmfs/devices/disks/ to see how vmware lists out the disks as the storage presents them

Hope you find this useful, don’t let anyone tell you that you can’t migrate a physical RDM. Its bogus information. This is how its done.”

Categories: VMWare Tags:

Copying data to/from a VM datastore using PowerCli – Script of the Day

March 8th, 2011 No comments

Ever needed to copy data from your local machine to a VMware datastore . .and not felt like messing around with winSCP / FastSCP, the Datastore browser etc?

PowerCli / PowerShell lets you create a new PSProvider item for your datastore, which in turn lets you copy data using the normal Copy-Item syntax. (though using Copy-DatastoreItem instead)

So, if you have a Datastore in your ESX environment called ‘Datatstore1’ and you want to copy an iso from your C:\ISO directory, it would be as simple as

PS: >new-PSDrive -location (get-datastore 7523_local) -name myds -PSProvider VimDatastore -Root '\'
Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
myds                                   VimDatastore  \lonlab001@443\Prod\7523_local
PS: >Copy-DatastoreItem -item C:\ISO\install.iso -Destination myds:\ISOS\Myiso.iso -force

Also, as the drive is now a normal PSProvider path, normal commands like get-childitem work like they do on a local drive

PS: >gci myds:
   Datastore path: [7523_local]

            LastWriteTime            Type       Length Name
            -------------            ----       ------ ----
     21/04/2010     07:40          Folder              esxconsole-4bcdbd...
     08/03/2011     16:31          Folder              ISOS


Of course this gives you full access to all of the datat on your datastores directly form a PowerCli session, so you can run any sort of reports / inventories etc that you may need. Happy days . .

‘Upgrading’ from ESX to ESXi – a multipart series – Part 2b – Installation – ESX Deployment Appliance (EDA)

March 4th, 2011 No comments



Part 2 -Installation Options


Part2b – ESX Deployment Appliance

‘Upgrading’ from ESX to ESXi – a multipart series – Part 2a – Installation – V-PXEServer

ESX Deployment Appliance (0.90 in Marketplace, but 0.95 available at: – this got updated from 0.94 while I was typing this page up)

Setting up of this is quite simple.

You can find a video of the process here:

  1. Download from either Appliance store, or above link
  2. Extract contents of Zip file locally
  3. If you want to run this on ESX / ESXi, you’ll need to convert the vmdk from workstation to ESX / ESXi.

3.1.    Copy contents of zip to a Datastore  (Use WinSCP, or Veeam FastSCP or similar)

3.2.    Using Putty, I connected to an ESX host that has access to the Datastore that the files are stored on and browsed to the Folder path /vmfs/volumes/<datastore>/EDA

3.3.    import  the vmdk from workstation to ESX format file using vmkfstools

3.3.1.   vmkfstools –I ./Eda-v0.94.vmdk ./Eda-v0.94_new.vmdk (Interestingly, this changed the size from 407MB to 1048MB ?

3.4.    Next, I renamed the original vmdk to Eda-v0.94.vmdk.old, and the new one to Eda-v0.94.vmdk

3.4.1.    mv ./Eda-v0.94.vmdk ./Eda-v0.94.vmdk.old

3.4.2.   mv ./Eda-v0.94_new.vmdk ./Eda-v0.94.vmdk

  1. For 0.94 To import the host to VC was now as simple as right clicking the .vmx file using the datastore browser / local browser and selecting ‘import’ then following the wizard. (I know I could have done this from the command line, I was lazy) (If you’d gotten a version that had an OVF file, you’d simply need ti use the ‘Import OVF’ wizard for this) – 0.94 has been configured as an OVF(appliance) , so you can import it the same way all appliances are imported.
  2. The 0.94  VM started with a NIC, but no CDRom (which we’ll need) – I therefore added a CD-ROM so I can attach ISO etc later. As the Vm was imported form Workstation on the ESX installation, we are unable to edit the NIC settings, so I also removed the existing NIC and added a new NIC. (no problems if running on workstation)
  3. Start the appliance
  4. Click on reconfigure to edit the network settings (this will be the IP for the appliance and the web URL you’ll use to do further configuration) – Fill in you information and click on OK to save the settings.
  5. Now you can logon to the EDA to configure the boot options
    Open Internet explorer on a host that has access to the VLAN that you configured the EDA on  and go to the site (The IP address that you configured above)
    Credentials are u: root – pw : root
  6. Once you have loaded the webpage, you’ll need to mount the ISO for the version of ESX(i) that you will be trying to deploy (Select the Appliance VM, edit the CDRom settings and select ‘local ISO’ and connect the ISO for the version of ESX(i) that you are going to install
  7. Once the CD is mounted to your appliance, at the top of the screen on the WebPage, select ‘Import PXE BootFiles” – watch the screen and make sure it deploys successfully. (at this point I had a few problems as my CD was not recognised) – I selected the ‘Patch’ option form a browser, then in the ‘Execute command’ box typed “ln -s /dev/sr0 /dev/scd0” – this mounted the CD. (You could also on the EDA appliance hit Alt-F2, then authenticate and do it from there after login – the ‘CD not Mounted’ message should change to ESXi CD mounted)
  8. A successful import looks like this :
  9. At this point I decided that I was going to use the EDA as a DHCP server, so configured a DHCP scope by clicking on the ‘configure DHCP server’  – clicking on this returns a relatively standard text based DHCP config file. What was pretty cool is that it allowed us to specify reservations ( you’d have to duplicate and uncomment the block that starts with #host fantasia {
  10. Once you have configured your DHCP options, select save, then Restart dhcpd – If you do not save, or you specify invalid config, the DHCP server will not start, e.g. I first time round specified a range that was not valid for any of the NICs presented to my server and it failed. (You need to save the config before restarting the DHCP to commit your changes)
  11. If you now boot a host to PXE, you will be prompted to do one of 3 things:

15.1.   Specify a hostname (this will be the hostname that you have prestaged – we’ll do this shortly)

15.2.   Boot Local (boot the current OS on the host)

15.3.   Run a manual installation.

  1. As the objective of this exercise is zero / limited touch installation, we are going configure / prestage settings for a host.

16.1.   Using the webrowser connected to the EDA appliance, click on the ‘New Host’ button

16.2.   This will create a new entry on your menu screen

If you were to PXE boot a host to your EDA now, you’ll see this host appear.

So if you type the hostname at the boot menu screen, EDA will go ahead and configure that host for you. – At this point we have a flat installation, with the VMKernel port configured and the host named as per our specified config – We have also been able to specify the IP for this host.  Host installation time is again about 4 minutes, but at present requires manual intervention. We know from previous experience that we can reduce the number of key presses required by modifying the install.tgz file in the ISO :

While we are looking at this appliance. We can see that the beautifully (simple is beautiful as far as I am concerned when it comes to techie interfaces) has several additional options available, so let’s explore what we can get out of the enhancements.

  1. Firstly (from the above screen grab of the full web interface), we can see a ‘General ESX host settings’ tab. This pretty much speaks for itself – we can specify the Netmask / gateway / nameserver / licenseserver (older ESX hosts) ksdevice(in case we want to drop kickstart files), an latered root password (obfuscated of course) and a timezone – that’s a bunch of nagging keypresses.
  2. Even better, on the right, we have a block called ‘Post Installation Commands’ – what this basically does is allows us to build some scripts to execute at the end of our source build going down. For example, we may choose to configure our NTP servers or create a user. To do this, we simply select ‘Configure NTP’ from the dropdown and click the ‘ADD Button’ – the base code is generated and copied into the text box beneath – all that we need to do is edit the bits that are added below (Generally, it will be strings like XXXXX, or YYYYY that need to be modified)  –  A little vCli knowledge would be handy here as you can append any addition changes that you would like added, simply by modifying the text in the box. All you will need is in here: – though the generated script blocks on the appliance should be enough.
  3. If you have a large cluster you’d like to deploy, you can go ahead an configure most things here (vSwitches, Portgroups . . in fact with it being vCli, you could really do the full configuration for your host up front in the postbuild script here and just let rip whenever you are ready to go)
  4. I added several config settings on the rights and then dropped a PXE boot build on a new ESXi server and was surprised, even astonished at how smoothly the build went.
  5. One thing that bugged me was that if I was enabling a PXE server on my network, I would want it to wait at a PXe prompt for no more than seconds before booting to the default OS. Fixing this was pretty simple. All you need to do is on the EDA, hit ALT-F2 – you’ll need to authenticate (root:root) and then then you’ll be at the linux shell. Cd to ‘/var/lib/tftpboot/pxelinux.cfg’ you will be able to edit a file called ‘default’ –  nano is not available on this appliance, so use ‘vi default’ – a cheat sheet for vi is available at
  6. Simply edit the timeout value to what you need (it appears that the values are 10ths of a second – so timeout 100 = 10 seconds)  – again, you can make all manner of changes to this if you like (most of the PXE config is in /var/lib/tftpboot) – as it is just one of the basic linux boot disks, just have a look here: Ideas include adding your own logo, adding additional boot option, possibly some integration with other systems etc – maybe even (if you really felt like it) some Mac Address detection that allows for a stateless installation for each host at boot time – meaning that you could simply change the Mac Address on the appliance for a new ESX host and lay that image on a new host, if an old one failed? Or even a forced install on any host that has no drives configured?


On the whole this is another superb piece of work by the VMware community

Ease of setup : Extremely quick and easy to setup (it did take me longer than the V-PXESERVER to get going first time round, due to the CDROM not mounting properly, but the support (based on a simple thread on the VMware communities is excellent) and the tool is in constant development (bug fixed version 0.95 was released while I was working on this)

Watch out as you will be dropping a PXE server on a VLAN and hosts will boot to this PXE server if they are set to boot from network first – though it does come with a 30 seconds timeout configured (which you can amend if you like)

Ease of ESXi deployment :  As with V-PXESERVER, some key strokes are required on ESXi host to specify install location etc, but this can be avoided by using the instruction I have posted before)

Deployment time : 4 minutes per ESXi host (without modifying ISO) – provided you are there for the key presses

Modified ISO :  About 3 minutes per ESXi host, but you’ll need to replace upgrade the install.tgz file each time you upgrade your ISO.

Likes :

  • I like the fact that postbuild options can be handled as part of the scripts that get imported, but unfortunately it seems that the appliance is still using ESX syntax, assumptions so post build functions are going to need some manual tweaking
  • Mounting an ISO and keeping it mounted for builds is nice and simple
  • ESXi gets deployed in about 4 minutes (network depending) once the tool is configured and can have a fair amount of customisation pre-done
  • Excellent support on the VMware communities


  • Being able to create custom postbuild scripts is awesome – but not all my ESX hosts are in the same location / cluster etc – it would be nice to be able to store a customisation with each ‘new host’ that is unique to that host – modifying postinstallation tasks seems to edit all ks files for all hosts that I have created (or it could just be me being stupid) – I will persist and possibly post a comment on the VMware community thread.

Other than the fact that it is Linux based (so difficult to PowerCli from), this is a superb tool! Great work

Categories: VMWare Tags:

Modifying an ESXi ISO to reduce the number of keypresses required for build

March 4th, 2011 No comments

Modifying an ESXi ISO to reduce the number of keypresses required for build

There are several tools available for quickly deploying ESX / ESXi ( I am reviewing these in my ESX to ESXi ‘Upgrade’ series.

But the vanilla config for each of these still requires a coule of manual key presses – ting is, do we really need a welcome screen and a second confirmation of everything we do? Assume for example I have 20 ESX hosts, ready to build, but networking is not yet in place because as usual the Networks team are dragging their heels . .so I decide to take the 20 boxes and drop ESXi on them. I am happy (in this case) to ISO boot them, but do not want to click ‘Next -> Next -> Next  -> Next -> finish’ (If I wanted to do that I would have installed Windows?

Anyway, the way to modify this is to crack open the python script that VMware uses for installation.

  1. First of all, we are installing from an ISO, so let’s crack open the ISO (the easiest way to do this is just mount it to a VM. As it is Linux based, I figure a Linux VM is best) – A quick tip here – it is always handy to keep a linux based VM around for general maintenance. I use the VMware browser appliance which is simply an Ubuntu Linux workstation – anyway, mount your ESXi  ISO and open it up
  2. The content looks like this:  If I were a gambling man I’d guess that we need to modify the install.tgz file?
  3. OK, so as we are doing this from within Ubuntu, we could simply double click the file and extract it, but I am going to assume that you may only have a shell from your Linux (or you’re using something like Cygwin) – so let’s open a terminal shell.
  4. Once we have opened a Terminal shell, we’d like to get access to our CDRom (mounted ISO), so we type ‘mount’ to show mounted objetcs. (on the Browser appliance a CDROM appears as : /media/cdrom)
  5. If we go ‘cd /media/cdrom’ and type ‘ls’ the list of files on the CDRom appears (including of course our install.tgz file)
  6. OK, we need to create a work area in which to edit this file so let’s create a temp location ‘mkdir /tmp/install’
  7. Next we need to extract the install.tgz file so that we can edit it ‘tar –C /tmp/install –xzvf /media/cdrom/install.tgz’
  8. If we now browse to the /tmp/install folder we can view a series of extracted files and folders. We need to edit the file called, we can do this using nano or vi, but it is currectly read only. To change the permissions on the file we type ’chmod 777 /tmp/install/usr/lib/vmware/installer/’
  9. We’ll use nano. In the terminal session, type :’nano /tmp/install/usr/lib/vmware/installer/’
  10. About 20 lines into the file you will find a class called ‘ThinESXInstall’, we need to edit the steps in this section.
  11. We know that we do not want to see a welcome screen, we do not want to be prompted for license details, we do not want to be prompted to confirm anything, and we don’t need to know when the installation is complete(the host of course will have an OS on to show us this?), so we can edit the Steps fields as follows:
    1.  Steps = [ WelcomeStep, LicenseStep, TargetSelectionStep, ConfirmStep, \
       WriteStep, PostConfigStep, CompleteStep, RebootStep ] -should become
    2. Steps = [ TargetSelectionStep, \
  12.  WriteStep, PostConfigStep, RebootStep ]
  13. Once you have edited this as you like, simply hit CTRL – X and when prompted select ‘y’, then save the file back to the original location.
  14. We now need to rebuild the install.tgz – at the terminal shell we type ‘cd /tmp/install’ then  ‘tar –czvf /tmp/install.tgz *’ – this will create a new tarball at /tmp/install.tgz.  YOU HAVE DONE THIS IN THE TEMP DIRECTORY – IT WILL BE DELETED AT REBOOT!
  15. We now have a modified install.tgz that simply needs to be replaced in our ISO.
  16. We can copy this Install.tgz file up to a network location (or from our Linux host) using something like WinSCP. As the file is only 21k in size, I simply connect a virtual floppy to the Browser appliance and copy the file to there, then mount it to a windows VM on my network (If your appliance is already on the network, just copy it using the network)
  17. Using your favourite ISO editor (Google UltraIso 9.3 PC Users readers) simply replace the old install.tgz file with your new one. If you now boot from the ISO (or even use it with one of the various PXE server solutions out there (UDA / EDA / V-PXESEERVER etc) – you will suddenly have a bunch fewer prompts at boot.
  18. Mounting this using something like V-PXESERVER, or EDA now returns a 1 button build from PXE (Select storage)
  19. Happy days . . enjoy!
Categories: VMWare Tags:

‘Upgrading’ from ESX to ESXi – a multipart series – Part 2 – Installation Options

March 3rd, 2011 No comments

Deploying a new ESXi installable instance (I’ll be creating posts for the following options and create a composite summary at the end)

Some research has returned 7 viable options for deployment here:

1. Manual Installation
2. UDA (Ultimate Deployment Appliance)


3. EDA (ESX Deployment appliance) – (0.90 in VMware appliance Marketplace, but 0.94 available at:

  1. a.
  2. b.

4. VMware’s own ‘Auto Deploy’

  1. a.

5. V-PXEServer


6. SD / USB duplication

7. Custom PXE Server

Categories: VMWare Tags:

‘Upgrading’ from ESX to ESXi – a multipart series – Part 2a – Installation – V-PXEServer

March 3rd, 2011 No comments



Part 2 -Installation Options


Part2b – ESX Deployment Appliance

In my ESX to ESXi upgrade, I’ll look at a few tools for hands free installation, first in the series is  V-PXEServer –  This is a simple WinPe boot disk that effectively hosts TFTP, DHCP and PXE.

Simon Long’s blog has installation instructions and has done a really good write up on the deployment process. In addition, he has added some handy customisations like speeding up the deployment and providing customised company backgrounds etc while the process runs – though it appears that the author of the appliance has made changes to the build as it now seems to deploy in about 5 minutes, where Simon was getting 15 minute deploy times.

To install the appliance on ESX, I pretty much followed Simon’s blog, word for word, but if you were to need to run this without a copy of VMware workstation, you’d need to do the following convert the VM first (Simon includes details on using converter for the migration, but this required the VM to be accessible – you can get a 30 day trial of workstation at

Read more…

Categories: VMWare Tags: