Posts Tagged ‘VMware’

‘Upgrading’ from ESX to ESXi – a multipart series – Tools

March 2nd, 2011 No comments

Setting up the test environment

In order to get this whole build tested, we need a repeatable and accessible Lab environment.

If you are unfortunate enough to not have an ESX lab environment that you can play on, you could build a workstation and emulate your production environment right on your desktop using VMware workstation.

Tools that we’ll require (so need to download if you do not have them already) are as follows:


You favourite script editor

A VMware ESXi Server, or VMware workstation to run tests on, along with a copy of the ESXi Installable media

A linux guest

Cygwin for Linux commands in Windows

Copies of the various tools we’ll be testing

Assuming that not everyone has spare hardware at their disposal, I guess it would be useful to create VMs to act as ESXi hardware on which to test our installations.

If you’re using VMWare workstation as your lab  – Full guide at:

Quick Video:

If you are using an ESX(i) host to run your test ESXi VMs on, follow the guide at :

For each appliance based deployment method, we’ll create a new VM – these will be detailed as we test each appliance.

I’ll revisit this thread as I discover further required tools

Categories: VMWare Tags:

‘Upgrading’ from ESX to ESXi – a multipart series – Intro

March 2nd, 2011 No comments



Part 2 -Installation Options


Part2b – ESX Deployment Appliance

‘Upgrading’ from VMWare ESX 4.0 to ESXi 4.1(u1) – with as few button clicks as possible.

Anyone reading the official docs from VMware at : is likely to be annoyed and frustrated at the lack of actual information as to how to manage the ‘upgrade’ (migration) from ESX to ESXi.

We all know that at VMWolrd 2010, VMware announced that we are on our last Major release of ESX.

There is no direct way to upgrade directly as the 2 products are effectively 2 different operating systems that behave in exactly the same way. (well not really, but they are installed totally differently and are managed slightly differently)

Anyway, we have about 80 ESX hosts to migrate to ESXi, so I decided to find the easiest method to do so.

A scour of the web found several great resources. – and some valuable information. It seems that nobody has yet delivered a full ‘upgrade’ solution, but several people have provided automated deployments of the core installation and several other people have created configuration scripts for the newly installed ESX. So I have decided to add an additional ‘information gathering’ step, then ‘borrow’ some of the work done elsewhere and put together an ‘upgrade’ solution.

Scratching my head, I have been working on a simpler way to manage the deployment / upgrade.

The way I see it, the ‘upgrade’ needs 3 parts:

1) Capture configuration from the existing ESX host that we will be replacing (we may need to interpret and reformat it for our new ESXi Host

2) Deploy new ESXi instance on the hardware(6 options below)

  • UDA (Ultimate Deployment Appliance) –
  • EDA (ESX Deployment appliance) – (0.90 in VMware appliance Marketplace, but 0.94 available)
  • VMware’s own ‘Auto Deploy’
  • SD / USB duplication
  • V-PXEServer
  • Manual installation (I will include this as a benchmark – remember ESXi requires very few clicks as is to get running, so manual may still be the way to go)

I will not recreate any posts that already exist to deploy any existing methods, though will highlight any tweaks I have found to make these smoother / easier and identify my preferred source for deployment.

3) Deploy captured config to our new ESXi host.

Whilst I realise that this probably will not be enough to make it a full ‘upgrade’ the idea is to get as much done as quickly as possible.

Coming up will be several posts, documenting comparisons of 6 methods of deployment, as well as some PowerCli code and a look into Host Profiles for easing this process.

On the off chance that one of the vendors that do ‘migration’ tools feel like offering me a free license to trial their tool and write up a process doc, I may even be inclined to review that for people with $$$ – but it is important that it is noted that I promise no allegiance to any tools, as would like this review to be fair and open to all. The end product of the series should provide a decision as to my preferred FREE method for doing the migration.

At the end of the series, I’ll create a comparison table comparing the various products, as a springboard for anyone who’ll soon be in the same situation as me.

For environments where there are only 2 or 3 ESX hosts, I’d consider building a solution like this going overboard, so I will make the assumption that readers of the series are people who have large numbers of hosts to upgrade and therefore will be wanting to work on ESX / ESXi rather than VMware workstation. As such, I will endeavour to get all tools working on ESXi and will highlight tweaks required (several of the tools I have tested so far were created on VMware workstation and therefore do not import directly to ESX hosts)

Products that I will be including in my review for the deployment include the 6 above – I will go through the options for the deployment of ESXi, before doing the capture and deploy steps above (I need a deployment workframe to work on, so it makes sense in this case) –

All tests for now will be run in my isolated lab, with the convenient luxury of the deployment servers being located on the same subnets etc as the Hosts I’ll be deploying to, but once I have selected a solution and start the migration of 80 ESX hosts to ESXi, I will of course post details of any further tweaks required for deployment.

Please note, all opinions and information posted will be post on my experience of the process and is open to debate. I will be quoting and using tools form several VMWare heavyweights (e.g Mike Laverick, Simon Long and so on)

Categories: VMWare Tags: ,

Script of the Day – Scripted start of Virtual Center (and supporting servers) when hosted as a VM

February 25th, 2011 No comments

There are many threads on the VM communities, debating whether it is better to run a VC on a physical host, or a VMWare host.

My answer is always that running it as a VM is better, but the arguement always comes back that if I have catastrophic faiilure and don’t know where my VC last lived . . I will be in trouble.

Of course, plan a is to simply set the restart policy on the VM to start with the host, but people tell me they have had mixed results with this approach.

The alternative is a quick PowerCli script that quickly connects to each ESX host in the cluster, checks if it owns the VM, then starts the VM.

$vCenters = "ESXHost1", "ESXhost2", "ESXHost3"
$VCServer = "VCServer"
$userName = "username"
$passwd = Read-Host ("Password for " + $userName) -AsSecureString:$true
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $userName,$passwd

One catch to be aware of though is that if you are using AD for DNS and all AD servers are VMs, you will be unable to resolve the ESX host names for the script to work, so you’ll need to specify IP addresses to the ESX hosts.

You do not however need to specify the DNS server IP for the VM, as the script look s as VM Names and

You could extend the above script then to start a series of VMs with a set wait time between VMs (e.g. start the DC for DNS etc, then start the SQL server, then start the VC, wait 60 seconds between each start)

Disconnect-VIServer * -Confirm:$false
$vCenters = "", "", ""
$vms = "DNSServer", "SQLServer", "VCServerName"
$userName = "root"
$passwd = Read-Host ("Password for " + $userName) -AsSecureString:$true
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $userName,$passwd
# time to wait before starting next VM
$waittime = 60

Foreach ($vm in $vms){
 ForEach ($vCenter in $vCenters) {
 connect-VIServer -Server $vCenter -Credential $cred
 If (get-vm $VCServer -ea 0)
 Start-VM $vm
 Write-Host "VM $VM Starting on $vCenter" -ForegroundColor Green
 Write-Host "Sleeping for $waittime to allow $vm to start up"
 sleep $waittime
 disconnect-VIserver -confirm:$false

And if you are feeling really flash, you could get each VM start, then monitor that VM for a particular services on that VM to run, before starting the next VM (if you have relevant access rights etc)

Prime example here is where I need a VM running my AD/DNS to start, before I can start the SQL server. Then, I want te SQL server to start and the service running, before I can start the Virtual Center.

# remove any VI connections that you may create in your PS Profile
Disconnect-VIServer * -Confirm:$false
# List of ESX hosts (by IP here as we are assuming DNS lives on a VM)
$ESXHosts = "", "", ""
# 2 dimensional array, each row reflecting the VM to start and the service that I need to monitor
$vms = ("ADDNSServerName", "DNS"), ("SQLServerName","MSSQLSERVER"),("VCServerName","vpxd")
$userName = "root"
$passwd = Read-Host ("Password for " + $userName) -AsSecureString:$true
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $userName,$passwd

# Connect to all ESX hosts in array $ESXHosts
ForEach ($ESXHost in $ESXHosts) {connect-VIServer -Server $ESXHost -Credential $cred}
Foreach ($vm in $vms){
 Write-Host "Searching for $vm[0]" -ForegroundColor Blue
 ForEach ($ESXHost in $ESXHosts) {
 If (get-vm -Name $vm[0] -server $ESXHost -ea 0)
 Start-VM -VM $vm[0] -Server $ESXHost
 Write-Host "VM $VM Starting on $ESXHost" -ForegroundColor Green
 $i = 0
 $running = "no"
 do {$running = Get-Service -ComputerName $vm[0] -Name $vm[1] -ea 0 | % {$_.status}; sleep 1; $i++; Write-Host "Waiting for $vm[1] service to start on $vm[0]- $i seconds elapsed" -ForegroundColor Yellow}
 while ($running -ne "Running")
 Write-Host "$vm[1] service started on $vm[0]" -ForegroundColor Green
Write-Host "VC should now be up and running" -ForegroundColor Red

so all you now need to do is keep a copy of the above script and make sure the few fields in the first few rows remain up to date with your ESX hostnames and the Servers / Services that you require to run your VC.

It is kind of a vApp in a script . .
have a great weekend

Manually assigning Mac Addresses to VMs

February 24th, 2011 No comments

So let’s say we have a VM and it has a VMWare assigned Mac Address – but we want to specify a different MAC for the VM (either a previously assigned automatic VM one, or a 3rd Party one)

You have a few options.

1)    VMware provide this: – but I have had mixed results and sometimes needed to use MAC addresses that are not VM specific

2)    3rd party tools for changing the MAC in the OS (Windows in this case)

3)    Edit the Mac Address on the NIC itself in TCPIP properties for the NIC (though often software can get around this .

4)    Have a hack around the VMX files:

Read more…

Categories: VMWare Tags:

Script of the day – Powercli one liner to get ESX host versions

February 24th, 2011 No comments

So I was looking at an ESX estate that is managed by someone else and was hoping to do a few ‘Get-EsxCli’ queries.
Of course Get-EsxCli only works properly from 4u2, so I needed to find a host that was patched up to date.

The easy way? PowerCli of course.

get-view -ViewType HostSystem -Property Name,Config.Product | select Name,@{N="Build";E={$_.Config.Product.FullName}} | sort build,name

Script of the Day – new(ish) Powercli cmdlets Get-ESXTop – part 1

February 18th, 2011 No comments

Ignore this post – found it written up far better than I could ever manage:

When I have some time, I’ll write a wrapper for get-ESXTOP and get-esxcli to make these easier to use. In the mean time, head over to for a decent guide!

Yes I know, some of you noticed these a while ago, but I have not been paying attention.

Back in December, the PowerCli guys released a new version of the Cli for us : Of course, I installed straight away, but did not go through the release notes.

Anyway, long story short, I noticed 2 particularly useful little cmdlets have appeared:

Get-Esxtop (no more SSH access required) –

and Get-ESXCli -

Of course, this is very exciting news. As a rule, I try user PowerCli as my first port of call for everything – SSH / Console access is a distant second as far as I am concerned (call me lazy)

Anyway, generally, when I need to view counters for a VM, I go to and use those values as a guide as to what I should be tracking.

We run (we have to connect direct to an ESX host to use these tools – so connect using the normalsyntax first)

 connect-viserver <hostname>

Well first things first, using get-esxtop we may not know what exactly we’d like to query, so to return the set of cuonters available to us,

PS:6 >get-esxtop -Counter
Name                 Fields
----                 ------
Server               {MinFetchIntervalInUsec:U64, IsVMVisor:B, TimeStampInUsec:U64, Time:S64}
COS                  {UserTimeInUsec:U32, NiceTimeInUsec:U32, SysTimeInUsec:U32, IdleTimeInUsec:U3...
PCPU                 {NumOfLCPUs:U32, NumOfCores:U32, NumOfPackages:U32}
LCPU                 {LCPUID:U32, CPUHz:U64, UsedTimeInUsec:U64, HaltTimeInUsec:U64...}
PMem                 {PhysicalMemInKB:U32, COSMemInKB:U32, KernelManagedInKB:U32, NonkernelUsedInK...
NUMANode             {NodeID:U32, TotalInPages:U32, FreeInPages:U32}
Sched                {HostCPUInPct1Min:U32, HostCPUInPct5Min:U32, HostCPUInPct15Min:U32, NumOfSche...
SchedGroup           {GroupID:U32, GroupName:STR, IsValid:B, IsVM:B...}
CPUClient            {CPUClientID:U32, IsValid:B, NumOfVCPUs:U32}
HiddenWorld          {HiddenWorldID:U32, HiddenWorldName:STR}
VCPU                 {VCPUID:U32, WorldName:STR, IsValid:B, Affinity:U64...}
VMem                 {MemClientID:U32, IsValid:B, CurrentSwapInKB:U32, ToBeSwappedInKB:U32...}
VMNUMANodeMem        {NodeID:U32, IsValid:B, GuestMemInKB:U32, OverheadMemInKB:U32}
SCSI                 {NumOfReservations:U64, DurationInUsec:U64, NumOfConflicts:U64, ConfigNumOfOu...
Adapter              {AdapterName:STR, IsValid:B, QueueDepth:U32, NumOfChannels:U32}
Channel              {ChannelID:U32, IsValid:B, NumOfTargets:U32}
Target               {TargetID:U32, IsValid:B, NumOfLuns:U32}
Lun                  {LunID:U32, IsValid:B}
Path                 {PathName:STR, DeviceName:STR, IsValid:B, NumOfCommands:U64...}
WorldPerDev          {WorldID:U32, IsValid:B, NumOfActiveCmds:U32, NumOfQueuedCmds:U32...}
Partition            {PartitionID:U32, IsValid:B, NumOfCommands:U64, NumOfBlocksRead:U64...}
SCSIDevice           {DeviceName:STR, IsValid:B, QueueDepth:U32, BlockSizeInBytes:U32...}
Nfs                  {NumOfNfsClients:U32}
NfsClient            {MountName:STR, NumOfReads:U64, ReadByte:U64, ReadTimeInUsec:U64...}
Net                  {NumOfPortsets:U32, NumOfPNICs:U32}
NetPortset           {PortsetName:STR, IsValid:B, NumOfPorts:U32}
NetPort              {PortID:U32, IsValid:B, IsUplink:B, ClientName:STR...}
PNIC                 {PNICName:STR, UplinkPort:U32, IsValid:B, IsLinkUp:B...}
Interrupt            {NumOfInterruptVectors:U32}
InterruptVector      {VectorID:S64, Devices:STR, NumOfCPUs:U32}
InterruptPerCPU      {CPUID:U32, Count:U64, SysTimeInUsec:S64}
Power                {NumOfLCPUs:U32}
CStateInfo           {StateID:S32}
PStateInfo           {StateID:S32}
TStateInfo           {StateID:S32}
LCPUPower            {LCPUID:U32, NumOfCStates:U32, NumOfPStates:U32, NumOfTStates:U32}
CState               {StateID:S32, ResidentTimeInUsec:S64}
PState               {StateID:S32, ResidentTimeInUsec:S64}
TState               {StateID:S32, ResidentTimeInUsec:S64}

hmm, seems to provide a long list (more than 200 once you go into each of the branches) – but most importantly, they are nicely distributed by what they monitor.

to get a slightly easier to read output of this, we can run

$out = @()
foreach($counter in (Get-EsxTop -Counter)){
 foreach($field in $counter.Fields){
 $row = "" | Select Counter,Field,Type
 $row.Counter = $counter.Name
 $row.Field = $field.Name
 $row.Type = $field.Type
 $out += $row
$out | Export-Csv "C:\counters.csv" -NoTypeInformation -UseCulture

OK, so now we have a list of counters – and looking at ESXTOp these seem to align directly with the normal column headers. We know what we have, we have a list of counters in the doc above from VMware, to help us know what to view . . so how do we view these counters?

Well pretty simple really – let’s say we want to read all VCPU related counters, it is as simple as

Get-EsxTop -CounterName  VCPU | select * | ft -AutoSize

Right, this is about where I started scratching my head – no number of select statements or cleverness seems toreturn info for just the one VM, so what do we do?

well….with a little help from our other new cmdlet we’ll soon be churning out pretty live stats. …. Watch this space….I’ll post the rest of the solution early next week.

Categories: Powershell, VMWare Tags: ,

Using Vyatta as firewall in ESX/ESXi for Private network simulation, routing, firewalls, DHCP and identifying port requirements

February 18th, 2011 No comments

VMware is an amazing tool for emulating physical Firewalls, Routers, DHCP servers. It is especially useful for helping identify port requirements of various applications and tools.
Quite often, as a consultant, people ask you to implement some new product and expect you to provide all port requirements for the product, so that relevant firewall rules etc can be created – but they won’t allow you to drop anything like Wireshark on their live network.

My normal solution is to create my own ‘Private’ network on an ESX host (which could be your mobile lab)
This allows me to isolate traffic behind an ‘appliance’ firewall / router and if I like, drop a VM on that private network, to do port capture etc.

Of course, this is also a great tool for simulating routing / firewalls in your home lab, providing DHCP and so on.

In the following example, I’ll use Vyatta to build a Private network and then do some port monitoring.
Read more…

Categories: Toolbox, VMWare Tags: ,

vFiler Non disruptive array migrations

February 17th, 2011 No comments

Fletch over at has posted a great article on Non dispruptive Array migrations, using NetApp 3040s.

Using vFilers, they managed to migrate 15 Dayatsore, totalling about 25TB in a week – without any disruption.

Have a look at : for a walk through the process.

Categories: VMWare Tags:

Script of the Day – quick and easy VMware Powershell scripts

February 16th, 2011 No comments

Today’s script of the day is more a collection of scripts (or rather an easy way of generating a bunch of scripts)

Over at the VMware labs ( they have released an awesome tool (in Alpha at the moment) that interecepts instructions sent to your Virtual Center and in the background generates PowerCli (or javascript or C# or Soap) code for you. Read more…

Sizing your ESX LUNs

February 15th, 2011 No comments

I regularly get asked how LUNs should be sized for VMware..

Firstly, this is one of those ‘how long is a piece of string’ type questions.

It of course depends on the number of VMDKs you’ll be running, the storage available, the type of storage, the i/o of the storage, type of VMs etc etc etc,

Things to consider for example are, do you have storage that does de-duplication and is cost of storage a major factor (and so on)
Of course . . pretty much always, a cost savings equals a performance hit.

Anyway, as a very loose rule of thumb, I (in most cases) find that I size LUNs somewhere between 400GB and 750GB and seldom (if ever) have more than 30 vmdks per LUN.

Pretty much always, I redirect the request to the following resources:

first of all, the configuration Maximums:,289483,sid179_gci1350469,00.html

and of course the composite created by Andrethegiant on the VMware communities

Categories: VMWare Tags: