The (un)official 3.0.1/2.0.1 Upgrade Report Thread

[jlee2]

I thought I'd start a thread for people to report how their upgrade to ESX 3.0.1 and VC 2.0.1 went. I'm mostly looking for persons upgrading from 3.0.0/2.0.0 but ESX 2.x upgraders feel free to post also. Be sure to include details like your SAN or RAID controller, are you using vCPU or Vmotion, any additional steps you had to take, etc, etc. I'm looking to move my 3.0.0 box to 3.0.1 on Thurs. evening so I'll be sure to post back my results. Any other early adopters?

[fdouma]

Did a VC 2.0 to 2.0.1 today, ran the .exe in the bin directory as directed, took the hints from above and didn't obliterate my SQL DB. All worked as it should.

Did a ESX 3.0 to 3.0.1 (actually two) with the tar ball. Worked as advertised. Got a nastigram about migration of a RedHat VM from 3.0 to 3.0.1 about how it had to set a CPU setting on my VM. I said OK, and all was well.

However, I'm not happy with the VM tools part of this upgrade for Linux VM's. No docs whatsoever except what you find here or Google up. I'm not finding a graceful way (ie. no downtime for the VM) to get the Tools upgraded. (I think I still have to run the vmware-config-tools.pl jazz, which can hang your network driver, thus a reboot for the VM. Yuck.)

Ideas/thoughts on this tools issue? If I could get this done smoothly, I think I'd plunge right in and do my whole site.

[kimono]

Well I'm glad it's all seeming to be a worthwhile upgrade. From someone who was beta testing the 3.01 product - I am now in a position to say that the biggest issue has been resolved. During beta testing I was faced with VM's losing their networking after the VMOTION with Relocation process, and not being able to regain their IP address until the VM was rebooted. This happened right after the vmotion completed. Despite this the dmotion side of things continuied and worked perfectly. It's an impressive process.

If anybody gets the chance, it's worthwhile and interesting to look behind the scenes during the Relocation and at the vmfs2 and vmfs3 file systems. You'll see the DMOTION files and get a good understanding of what's happening. Good to know if things go wrong.

To Mork:

>> I just wish I had've known that 3.0.1 would allow upgrades via VMotion a month

>> ago.

I feel your pain buddy. I spilled the beens on the relocate feature in 3.01 in these forums about a month ago for that very reason, being cogniscant of peoples upgrade plans ... but I nearly got in big trouble for doing so.

[garybrown]

Our upgrade failed ...!

A typical line

\[06Oct05-1019] INFO: yum: | file /usr/src/linux-2.4.21-37.0.2.EL/drivers/scsi/lpfcdd-v732/lpfc_sli.c from install of

kernel-source-2.4.21-37.0.2.EL.32039 conflicts with file from package kernel-source-2.4.21-37.0.2.EL.27701

then finished up with

\[06Oct05-1019] DEBUG: states: Entering \[ 10:19:17 10/05/06] \[UpgradeFailed ]

\[06Oct05-1019] DEBUG: install: Install cleanup...

\[06Oct05-1019] DEBUG: system: LogCommand(rm -f /etc/vmware/esx.conf.WRITELOCK)

\[06Oct05-1019] DEBUG: system: LogCommand(rm -f /var/lib/rpm/__db*)

\[06Oct05-1019] INFO: summary: --- TOTALS: 167 packages installed, 54 pending or failed, 0 excluded ---

\[06Oct05-1019] INFO: states: Yum upgrade failed, correct the problem and retry the update.

\[06Oct05-1019] DEBUG: lock: Lock file /var/run/esxupdate.pid deleted

\[06Oct05-1019] DEBUG: root: Final state: UpgradeFailed

If I actually new what the problem was (perhaps a bigger clue for us mortals) I may have been able to fix it.

So I did an

esxupdate --force update

worked a treat..!

now when I boot it complains about the 'route' but otherwise everything appears to be okay

\[root@g3t0007h vmware]# esxcfg-route -l

VM Kernel Routes:

Network Netmask Gateway

16.232.0.0 255.255.254.0 Local Subnet

default 0.0.0.0 Local Subnet

Also, this appears to need the VI client upgraded - will this new VI client connect to V3.0.0 servers - I don't want to upgrade it if not...?

thanks

[jrr001]

DO NOT USE CD METHOD FOR UPGRADE FROM 3.0 TO 3.0.1!!!!!

I upgraded 3 of my servers yesterday, 2 IBM 445, and 1 IBM 345 using the boot from CD method. All were SAN connected but booted off the internal ServeRaid controllers.

After the upgrade the boot loaded is corrupted...you get the word GRUB in upper left corner of screen..or worse messages. I was careful during the upgrade to select the ServeRaid as boot device and not the SAN.

Opened ticket with Support and they are aware of this corruption problem with the CD upgrade method and trying to figure out the issue. In the meantime the suggest using the tarball for the upgrade (page 163 of the install/upgrade guide) or ESXUPDATE tool with the tarball.

My only recourse is to rebuild from scratch these servers.

[jrr001]

On my previous post I was upgrading from ESX 3.0 to ESX 3.0.1

[einstein-a-go-g]

Upgrade from 3.0.0 to 3.0.1 worked flawlessly.

VC 2.0 to VC 2.01 failed with need to install Rollup 1 for 2000 SP4, which is odd because this server is fully patched and uptodate.

Didn't complain when I installed VC 2.0, any ideas anyone?

[ErMaC1]

This has been a previously reported issue - disconnect your SAN before attempting the upgrade from CD.

If you want to salvage your current servers, just unplug the san, re-run the upgrade from Cd, and you'll be fine.

[einstein-a-go-g]

Do you mean Disconnect the SAN from ESX 3.0.1 server?

We use an iSCSI connection, so how would one disconnect it?

Remove the HBA interface?

Regards

[jlauro]

Unplug the iscsi cable (if not shared), or block the lun on the iscsi SAN.

Can be done without going to that trouble, just be extra careful at all the prompts, etc... defaults may reformat your vmfs...

[wunderon]

My Linux (RH AS4) vms updated the tools ok.

Selected 'install VMware tools' option while logged onto console as root. The script automounts the tools, runs config, then dismounts.

After that all you need to do is start networking. So you end up with a few or several seconds of network outage.

[BUGCHK]

"waiting for LIP to complete"

LIP is short for "Loop Initialization Primitive" which is used to (re)initialize a Fibre Channel Arbitrated Loop (FC_AL). The confusing thing with Qlogic is that they also use it when the adapter runs fabric protocol.

[daniel_uk]

Ive done a side by side migration and then dmotion'ed the hosts across with 3.01, now need to upgrade vmtools so will report if this has issues.

I dont trust upgrade paths to Operating systems/Software of any family to be honest. When presenting luns to my 3 hosts i had to change the LVM.disallowsnapshotluns to 0 for 3 hosts to appear?!? I will find out why this is with vmware when they come in next week.

I would like to see updates to migration of VMs as it dosnt appear.

[lams]

Hi,

We upgraded from 3.0.0/2.0.0 to 3.0.1/2.0.1 on 2 esx servers (the guests are hosted on a eva3000 san). The upgrade went fine but I'm having several problems today performing simple tasks like:

\- updating the VMTools: it worked on half the guests for the time being but on some I have to stop the upgrade after 20 minutes because it does not seem to finish

\- when migrating from one esx to the other, the migration works but it gives me a "Time-out" error at the end of the migration (tried on several servers and it's systematic).

\- I used to connect to the VM Centre using the VI client to see my esx servers but I discovered that it has a serious "refresh" problem: i tried to shutdown 2 guests (1WinXP and 1SLES), it seemed that the task performed well but then the guest still appeared as active (green triangle). I tried to shut it down again, but got the error saying it's already off so I can neither stop nor start it BUT if I connect directly to the esx server, I can see the right status and do whant I want.

\- after the upgrade, by connecting directly to the VM centre using the VI client, part of my guests were not in their resources pools anymore. I tried to move them back but it didn't work with half of them (it said "task completed" but stayed in the same place). By connecting directly to the esx servers, everything was fine, the guests being in the right resource pools

I've to say that it's currently my worst VM upgrade (the various esx 2.x upgrade and 2.x to 3.0 ran smoothly).

Regards,

Gaël

[jason_farrow]

The esxupgrade from the tarball also has errors that cause the server to crash on re-boot thus requiring a new install.

I got a fail to complete message from the esxupdate command, followed by an I/O error on shutdown and then corruption of the root filesystem.

Looks like the whole 3.0.0 to 3.0.1 upgrade process has not been tested by VMware yet.

[Michelle_Laveri]

Looks like the whole 3.0.0 to 3.0.1 upgrade process

has not been tested by VMware yet.

Jason,

we you trying to go from 2.x to 3.0.1 or 3.0.0 to 3.0.1?

I seem to remember reading somewhere that the later was not supported...

Regards

Mike

[hicksj]

we you trying to go from 2.x to 3.0.1 or 3.0.0 to

3.0.1?

I seem to remember reading somewhere that the later

was not supported...

Huh? 3 -> 3.0.1 not supported?

Anyways, I finally tried the upgrade this morning from 3.0 to 3.0.1 via upgrade tarball.

First I paused all VM's (because I only have one ESX server, Dell 2850, in the lab to test with). Ran esxupdate, no go. Said to fix problems, but no details on problems were presented. System is not SAN attached.

Same goes for shuting down all VM's. So I rebooted the ESX box, put it into Console Only mode. Ran the update. This time it says everything installed properly until it bombed out at the end after trying to stop hostd (which of course wasn't running because I was in console mode).

Now the server will not complete the boot process. About to try loading the CD up instead.

[hicksj]

FYI - Running the upgrade from CD against my "broken" tarball upgrade fixed the problem.

[c_g-hills]

The first server I tried upgrade from 3.0.0 to 3.0.1 using the headless upgrade procedure. The upgrade completed ok but the server would not boot. I have since found out that you need to remove the server from the vmfs zoning first. I retried using the cd and it worked ok. The other servers I simply used the regular cd method and that worked fine.

[shahues]

I also went and upgraded from 3.0.0 to 3.0.1 this morning via the upgrade CD downloaded from the website.

I guess I should have checked this thread first, but when I upgraded I also hosed the boot loader (which I am sure is fixable if you have any MBR tools around).

I tried re-upgrading the machine after unplugging the SAN cable from it, but that just ended in giving me a "GRUB GRUB Failed to read" error upon booting.

I am also re-building the server now, as I do not have my MBR tools with me.

[letoatrads]

Just wanted to add my upgrade sequence and experience.

Original setup - 4 ESX 3.0 Hosts - 2 SunFire X4100's 2 IBM 336's

VC 2.0 and License server on VM

SAN- Equallogic PS300e - ISCSI only ( attach via software initiator only no HBA's).

Upgrade license server first, then VC center paying attention to preserve my DB.

Then put my hosts in maintenance mode 1 at a time and performed upgrade by CD. I verified with VMWare that since I was connected to the SAN via ISCSI software initiator I shouldn't have the MBR issue and they were correct. Each host upgraded after migrating VM's off. Once complete, upgraded all VMWare tools and everything looks good now 12+ hours after upgrade.

Good luck everyone.