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?
the migraiton is on a VM by VM basis, VMFS luns size does not matter. You can go from one large VMFS2 LUN to many smaller VMFS3 LUNs or the other way. When you migrationt the 2.5 vm is asks you where you would like to place the files; your options are on any VMFS3 voluem the 3.0 host can see (and of course has room on).
Hey just to make sure I can understand this setup correctly. The ESX server can see the all the vmfs2 LUNS as well as the new vmfs3 LUNS and can vmotion the live VM from the vmfs2 LUN to the new vmfs3 LUN. Is that correct? So you just right click on the VM and select Migrate and ESX will ask you where to put it?
Is this all correct? So no downtime and you can go back and upgrade the tools and hardware later. Is that also correct?
Yup! but it also upgrades the hardware. Which means not going back to 2.x. (small negitave)
The 3.0.1 host needs to see the vmfs2 and vmfs3 volumes. the 2.x does not need to see the VMFS3 lun. When you do a VMotion it will force you to move the vmdk files to a vmfs volume.
zero downtime, of a running VM - testing wk3 and RH. Just need to upgrade the vmtools after its done.
Excellent news. Thanks for the update and clarification.
Steve
I admit we we're a bit quick to upgrade.
Fact is that we have serious problems on VI3 with Suse hosts and the network, and since it doesn;t work we decided to do the upgrade.
VC 2.0 to 2.01 => No problems, same for license server.
ESX upgrade:
Dell 2850, source ESX 3.0, 2xQLA2340, Netapp San
using the tarball for the upgrade from 3.0 to 3.0.1
The esxupdate the first time went very fast, error message: Yum encountered error, 55 packages upgraded, solve the problem and try again. We weren't sure about the problems (no real erro messages), and relaunched it, went a lot slower, no error, then got stuck in the init.hostd shutdown, We killed the proces after an hour, launched it again, when through 100 % , and went faster then the second attempt. Everythign seems fine. We'll upgrade an identical machine today.
Btw, the upgrade log is in /var/messages/vmware in case you're having errors.
Correction, the log is /var/log/vmware/esxupdate.log
The second upgrade on an identical node went better.
it went through in one go, only error (again) was this:
Package corrupt. Unable to locate /var/pegasus/mofs/VMWARE_ESX_Registration.mof
Had this also on the first node. Other problems did not occur.
Despite this the upgrade ended with:
INFO: Shutting down hostd...
INFO: Running esxcfg-boot to regenerate initrds...
INFO: Restarting hostd...
INFO: --- TOTALS: 221 packages installed, 0 pending or failed, 0 excluded ---
INFO: Install succeeded - please come again.
Intresting is that the esxupdate can be restarted without to many problems also in case a package didn't work. Why it didn;t work on the first node we don;t know (yet) but i doubt we will spend a lot of time searching for it.
I just upgraded Virtual Centre from 2.0 to 2.01.
It upgraded fine, apart from the fact it prompted me to re-initialise my SQL database. I chose the "existing database" option.
I think I did not read the message properly and clicked Yes. So, although the upgrade went smooth, my database was empty so I lost all Virtual Centre config and performance stats.
So be careful!
You read that one properly. the next message is the culprit, it asks whether you want to keep the existing VC config, default is No, that's what erased your data, sorry.
I've upgraded my VC from 2.0, my license server and one host from 3.0 .
The only problem I'm having is that one host's VC agent upgrade appears not to have worked and now won't connect in VC. It's the same host I've upgraded to 3.01 but, even after the 3.01 upgrade on it, it's having trouble connecting in VC.
Still investigating...
Chris
Disconnect and reconnect, with user and password, you should see in the event log that it will try to do the agent upgrade, this takes a minute or two.
i had two failed ones, worked the second time
one caveat: if you had to deploy the alwaysProxy hack to /etc/vmware/config with a 3.0 install to ensure reliable vm console access across NAT/vpn networks, you will need to \_reedit_ /etc/vmware/config after the 3.0.1 install as it apparently replaces the old file.
This made me lose several hours/if not an entire afternoon debugging...
Yes, the issue was that it was stuck on "Upgrading Agent". I've now managed to reconnect it but the reconnect process took about 40 minutes! Go figure...!
Chris
Hmm, i didn´t have disconnect and connect at all. I waited a couple of minutes and then it reconnected by itself. Everything works fine.
Could it be that I have the disconnect/reconnect for the 3.01 vc-agent to be applied. If there is a new one at all ? Somebody who knows ?
More info. I watched the server after reboot in the ALT-F12 mode and could there see that it reconnects to the VC-server. I can then exit maint-mode and the HA is enabled. Great so far.
The scary thing is that it states "waiting for LIP to complete" in the ALT-F12 mode. I know that "LIP" it is SAN-related but not what it tries to do. Any ideas ?
you don;t need to disconnect for the agent to deploy, but if you connect during the upgrade it notices the lost connection.
in any case the event log should show the agent upgrade.
Just FYI.
We tried to upgrade 1 of 5 ESX servers from 3.0 to 3.0.1 yesterday via the tarball install on pg 164 of the VI3 installation and upgrade manual.
We called tech support to confirm our steps prior to starting, tech opened a ticket in case we had issues.
Turned off HA on the VC server.
Confirmed correct download.
Copied file to /var/updates
confirmed checksum (md5sum:f140679847c24a0cc8916a0bf4d4fc81)
Uncompressed via tar zxf 3.0.1-32039-full.tgz
cd to /var/updates/32039
ran esxupdate -n update
It began to patch. Threw out a error at the end saying patch failed, 30+ items failed to update.
Reran the entire process. It said that it suceeded, yet at the very end of the update it said process failed. ?????? Great.
Tried to run it a 3rd time, its said could not run, no path, since versions are the same.
Called tech support to follow up on original ticket, left message, still havent had a call back. (Anyone know how fast turn around call should be on a platinum support ??)
Last night decided to insert the cd we created from the 3.0.1 ISO.
Booted to graphical, ran the update "2.x or greater to 3.0.1"
Ran through, worked like a charm. This morning used CD on one other machine so far and not an issue. Planning doing other 3 this way today as well.
I see no point in using a tarball if the ISO image works this quickly and nicely.
Wanted to share our experience as we are brand new to VMWare.
That's the method I used for my single upgrade so far so would be inclined to agree!
Chris
Today I upgraded two production ESX Servers with the CD as well as VirtualCenter and the Licensing server in about an hour. No issues... VMotion from ESX 2.5.3 to ESX 3.0.1 is a HUGE time saver.
I upgraded Virtual Center 2.0 to 2.0.1 just today and it went smooth (as I'd expect for just a "dot" release!)
The only thing that was confusing was that the first screen said it was going to do an upgrade. The rest of the screens looked very similiar to a brand new VC install, including setting up the database DSN, etc. I pointed to the DSN which points to the SQL server and it prompted a message that said something to the effect of "database already contains data" and it asked if I would like to overwrite. I chose NO and everything was fine from there on. I think its confusing to even have that option.. why would someone want to overwrite their VC database on an upgrade?
As for ESX 3.0 to 3.0.1, I'm planning that tomorrow. I'll let you know how that goes..
I just wish I had've known that 3.0.1 would allow upgrades via VMotion a month ago.
When I put 3.0.0 in, I put the two hosts in their own storage group on the SAN so I wouldn't have issues with the ESX 2.5.3 servers seeing the VMFS3 volumes or vice versa with ESX 3.0.0 and VMFS2 volumes.
Unfortunately, that now seemed like the wrong way to go and I can't change it due to the downtime required
Oh well, at least there's not many VM's to upgrade...