Archives: 'VMWare'

Upgrading the HP Proliant ML115 G5 from Dual to Quad Core

Friday, October 28th, 2011

I bought an HP Proliant ML115 G5 servers just before they were upgraded to include a quad core CPU.  I’ve been running VMware ESXi 4.0 and 4.1 on it without any issues, mainly due to the fact that I also bought an HP SC44Ge Raid Controller and an Intel Pro 1000 NIC (Gigabit, as the name implies).

Although it’s running quite happily I wanted to max out the spec of the box in order to have the option of hosting more VMs.  The CPU it shipped with was an AMD Opteron 1214, a 64bit dual core CPU running at 2.2GHz.  I was doing a little reading up after I bought the server and several news sites suggested that it might be possible to install a quad core Opteron 135x CPU.  At the time the quad cores had only just been released and so I didn’t pursue the idea.  Fast forward several years to the present day (28th October 2011) and the Opteron 135x CPU’s are now becoming hard to find; eBay has several sources but all in the US (I’m UK based).

Anyway, to cut the story short I ended up ordering a second hand (used) AMD Opteron 1356 2.3GHz quad core CPU from a source in the US for the grand total of £25 including delivery to the UK.

To prepare for the CPU upgrade I knew I also had to upgrade the firmware on the server.  The machine is physically capable of accepting the CPU but the firmware won’t know what it is unless it’s told.  So, looking on HP’s support site I found the latest firmware, version 2009.07.06 (A) (29 Jul 2009 in Softpaq SP44683 available here.

Also of note is the recommendation from HP: “***Please Note: BMC Firmware version 3.11 or later must be installed on the ML115 G5 when upgrading to this 07/06/2009 BIOS.”  You’ll definitely want to download load the Baseboard Management Controller (BMC) firmware in Softpaq SP44085 from this page.  You’ll note that the firmware is for the Lights-Out 100 Remote Management card, which you may or may not have installed (it’s not a standard feature AFAIK).  It doesn’t matter.  What’s important is that this firmware package also includes the BMC firmware you’re going to need.

In order to upgrade the firmware you’ll need a USB memory stick and to have set up the BIOS on the ML115 to allow booting from USB devices.  Once you’ve done that simply run the ML115 firmware update package (SP44683) and it will do everything necessary to turn your memory stick into a bootable device.  Put the USB stick into the server, reboot it and the firmware package will do the updating for you.

On rebooting the server you’ll notice that the fan will continue running at what sounds like full speed.  This is why HP recommended you also update the BMC firmware at the same time.  Simply repeat the firmware flashing process by running the second firmware package (SP44085) to create another bootable USB device with the BMC firmware on it, reboot the server with the USB stick in the machine and let the updater do its thing.  Reboot one more time and the fans will return to normal speed.

Finally, for anyone with the SC44Ge Raid controller the latest firmware appears to be version “ ( (3 Sep 2009)” in Softpaq SP45154 available here.

One final suggestion: remember to check the BIOS settings after flashing the firmware.  Although my settings were preserved between firmware versions your mileage may vary.

VMWare Converter 4.0 Standalone – converter.agent.internal.fault.PlatformError

Wednesday, August 11th, 2010

I’ve been playing with ESXi 3 v3.5.0 Update 2 (yes, I know update 4 is available for 32bit machines) and VMWare vCenter Converter 4.01 (build 161434) Standalone trying to convert one of a pair of cluster nodes running Windows 2000 Advanced Server (SP4) and it’s collection of local and shared volumes across to a VM.

Without much success.

Every time I try the conversion it fails with the error:

[Task] Caught an exception while waiting on the agent task to complete.
Gathering agent logs before propogating the exception further.
Exception message: converter.agent.internal.fault.PlatformError

VMWare note a “known issue” with Converter 4.0 and Windows 2000 machines here:

Unfortunately the issue appears to be slightly different and their suggested workaround of re-trying the conversion task doesn’t work for this problem.  Googling for the problem turned up several fixes one of which sounded a plausable fix for my environment  Sadly that didn’t work either as all my network cards have their link speed and duplex set manually rather than auto.

Thankfully I came across VMWare’s own knowledgebase article (1004588) on Converter best practices:

Due to disk space constraints on my target ESXi box I had elected to convert and resize ALL nine of the source volumes during the conversion.  After re-running the conversion with only two volumes selected (System boot, C: and Quorum, Q:) Converter managed to perform the task successfully.  Of course, this left me with an incomplete set of converted volumes.  Further attempts to convert the cluster node and shrink only one volume resulted in the same issues as before, causing conversion to fail after about 1 minute.

Thinking along the lines that maybe it was the shrink process that was messing me up I tried reconfiguring my MSA1000 array from RAID 1+0 to RAID 5 which gave me just enough disk space to perform the conversion without shrinking disks.  Unfortunately THAT also didn’t work!  I just got the same errors detailed above.

So, I set about trying to convert as many of the 9 volumes as I could (I have ten but only want nine of them on the VM)  slowly decreasing the number of disks to convert from nine to eight, seven, six etc.  Converting nine, eight and seven failed every time.  Once down to converting six drives I started receiving the error:

22/09/2009 16:22:23 Error: Failed to clone volume 'C:'
22/09/2009 16:22:22 Starting block-level cloning for volume 'C:'.

However this was similar in nature to the known error referenced above so I attempted the workaround and, would you believe it, it worked!  Simply right clicking the failed task and re-running started the conversion.

Getting VMWare ESXi 3.5 to recognise the Emulex LP950 HBA, MSA1000 and associated logical drives

Friday, December 19th, 2008

UPDATED: 17/09/2009

I’m posting very rough notes for the moment.  I’ll tidy them up when I get a chance.

Need to upgrade firmware to get ESXi 3.5 Update 2 to recognise the LP950 as an LP952

LP950 BIOS update (FILE: RB171A0.PRG)

LP950 Firmware Update (FILE: rc393a0.awc)

Need Emulex LP6DUTIL.EXE and LP6DUTIL.DOC of which version 9.3a4 is included in the (unrelated) firmware package available here:


STAT FFFA0000 Error when flashing

Need MSA1000 Bootable software CD to configure arrays using web based ACU

At this point the arrays are configured and ESXi will recognise the external storage.  However when trying to copy data to the data stores using VMWare Converter (P2V) it may fail at 2% with an error in the logs similar to:

… ‘P2V’ 2760 error … Task failed: P2VError UNKNOWN_METHOD_FAULT(sysimage.fault.NfcConnectionFault)”
… ‘P2V’ 5908 error … Task failed: P2VError UNKNOWN_METHOD_FAULT(sysimage.fault.PlatformError)
… ‘P2V’ 4400 error … Task failed: P2VError UNKNOWN_METHOD_FAULT(sysimage.fault.ImageProcessingTaskFault)

Alternatively, if after enabling SSH you try using WinSCP you may be *apparently* able to copy everything only for it to fail at 98% with the error “Function not implemented” or using “cp” at the unsupported command prompt may also copy small files but fail on large ones with the same “Function not implemented” error.  Similarly, using the “Datastore Browser” feature in VMWare’s “Virtual Infrastructure Client” will fail within seconds of trying to copy a large file.

At this point you should double check the firmware on the MSA1000.  Originally my MSA1000 was running an ancient v1.16 and I found that upgrading this to v4.48 fixed the problem.  If you do this you may also need the latest (v8.02 at time of writing) MSA 1000/1500 software CD.  v8.02 is available here: