Post to Twitter |
Comments (31) |
Views (14014) |
VMware has released a series of KB articles outlining the requirements and best practices for installing vSphere, upgrading to vSphere, and upgrading ESX 3.0 virtual machines to ESX 4.0 hardware. (Quoting them.)
So I'm guessing this should simplify the process, right? I know there were a few bumps in the update process for XenServer 5.0 Update 3 until we fleshed out the directions to be explicit about HA. Surely they've learned from this, and simplified their update process.
So let's see how they've focused on ease-of-use...
4. If a SAN is connected to the ESX Server, detach the fiber before continuing with the upgrade.
Walking from machine to machine in your data center pulling fiber connections, and reconnecting them after the upgrade? Now that's automation. That's ease-of-use.
Comments (31)
Jun 06
Anonymous says:
I didn't know that there is a need for Citrix to blog such a FUD! That's rea...I didn't know that there is a need for Citrix to blog such a FUD! That's really crap what you are writing! I'm a Citrix fan but when I read that .....
Jun 06
Roger Klorese says:
Crap in what way? It's a direct quote from a VMware KB article. I c...Crap in what way? It's a direct quote from a VMware KB article.
I can't imagine disconnecting tens or hundreds of servers manually from a SAN in order to update their software.
Jun 06
Anonymous says:
Hi, is it really necessary to try and get attention through such an article?! ...Hi,
is it really necessary to try and get attention through such an article?!
Well, the content is right and can be found in the VMware knowledge abse but what should be bad with that? You can update the hosts without unplugging the storage but as Duncan wrote human are human and just click. There is nothing bad with vSphere so far ....
But of course this is your blog and your thinking ....
Regards,
Michael
Jun 06
Roger Klorese says:
I didn't write it to "get attention" -- just to comment on what seemed l...I didn't write it to "get attention" -- just to comment on what seemed like an odd and difficult step to be mandatory for an update. Simplification is an important watchword for this sort of process, so it seems extreme to me to require such physical intervention instead of (for example) making the installer smart enough to only perform an update install on a disk on which you can find a previous version, actively protecting the user.
Jun 06
Anonymous says:
Because that's only to prevent users from killing their storage and not a must.....Because that's only to prevent users from killing their storage and not a must... so inform yourself before spamming such stuff
Jun 06
Roger Klorese says:
Installing to the server shouldn't "kill their storage" if it works right. ...Installing to the server shouldn't "kill their storage" if it works right. And if it's not a must, then it shouldn't be in the directions as a step, should it?
Jun 06
Anonymous says:
It's not a necessity, I've did 1000's of upgrades over the years without any iss...It's not a necessity, I've did 1000's of upgrades over the years without any issues at all. As you might know VMware ESX / vSphere is also used in highly critical environments and it's definitely better to be safe than sorry.
I've seen many environments where a new instance of ESX was installed on a VMFS volume. Yes ESX warns them, but people actually don't read warnings, they ignore them and just click next.
Now you might not be familiar with virtualized production environments at large enterprise customers, but I am and none of them would take the risk of wiping a production LUN. They could unplug the FC, or unpresent the LUNs or even remove the FC drivers from the boot image. These are all viable options and are merely a precaution.
Thanks for your great article,
Duncan
Yellow-Bricks.com
Jun 06
Roger Klorese says:
Thanks for finally identifying yourself. I'm quite familiar with ESX and with p...Thanks for finally identifying yourself.
I'm quite familiar with ESX and with production environments, as I was the product manager who first launched ESX at VMware.
Most large-scale production upgrades I've worked with were not done physically at the machine, so unplugging the cables was not an option -- the directions in the KB specifically direct people to unplug -- not unpresent, not rezone, but unplug.
Jun 06
Anonymous says:
Finally? This was my first comment. I always identify myself. So your problem i...Finally? This was my first comment. I always identify myself.
So your problem is the way they phrased the KB article and not the fact that we want our customers to take caution. As a former VMware employee you know you can submit a request to have the KB article changed.
Duncan
Yellow-Bricks.com
Jun 06
Anonymous says:
i must say that i didnt see this happen after esx 3.0.1 anymore. it looks like e...i must say that i didnt see this happen after esx 3.0.1 anymore. it looks like esx 3.5 looks different at the storage and doesnt wipe out the disks.
i never have seen this going wrong and i did many many esx upgrades. i always made sure that i unpresent the luns but that because the esx rollout was scripted with altiris and i saw this going wrong sometimes.
so i always be save and unpresent the luns, otherwise i get fired
i don't see any problems with this.
Jun 06
Roger Klorese says:
It seems reasonable to treat unpresenting the LUNs as a best practice. It ...It seems reasonable to treat unpresenting the LUNs as a best practice. It seems like a warning of danger to treat physically disconnecting them as a mandatory step.
(It should be pointed out that the XenServer installer simply doesn't treat storage in as loosey-goosey a way as to have to warn about this.)
Jun 06
Anonymous says:
No, I get really warm comfy feelings about your upgrade procedures reading the f...No, I get really warm comfy feelings about your upgrade procedures reading the following links:
http://docs.xensource.com/XenServer/5.0.0/1.0/en_gb/installation.html#maintenance-updating_xs_40-vs_41
http://forums.citrix.com/thread.jspa?threadID=237427&tstart=0
Duncan
Yellow-Bricks.com
Jun 06
Anonymous says:
And in case any of you missed it:We strongly recommend that you perform a backup...And in case any of you missed it:We strongly recommend that you perform a backup (export) of your VMs before doing an upgrade.
Just wondering what you think is a more difficult process. unpluggin fiber or backing up your complete environment before you do the upgrade...
Duncan
Jun 06
Roger Klorese says:
First, it's a recommendation, not an order. Second, I don't think there's an OS...First, it's a recommendation, not an order.
Second, I don't think there's an OS or platform on earth that doesn't recommend backups before upgrading.
Jun 07
Anonymous says:
Hey Roger, can you explain what the difference is between your recommendation an...Hey Roger, can you explain what the difference is between your recommendation and out article which is labeled "Upgrading to ESX 4.0 and vCenter 4.0 best practices"?
Cause I don't see the difference, really I don't.
Duncan
Yellow-Bricks.com
Jun 06
Anonymous says:
I must admit I've never installed XenServer ... so I don't know if it has some m...I must admit I've never installed XenServer ... so I don't know if it has some magic system in place to stop you formatting a LUN that happens to be important to you.
But surely any installation carries a danger of accidental data losss. During the installation of Windows I could select a disk/partition/LUN and say "yep, go ahead and reformat" and then find I've over-written my critical SQL database.
Isn't the recommendation to unplug a SAN which has a VMFS volume with potentially dozens (hundreds, thousands) of VMs on, just a good safety net? Most admins are intelligent enough to *not* mistakenly select such volumes for a re-write, but it *could* happen - just as it could with any platform.
Seems like a headline-grabbing non-post to me.
Jun 12
Roger Klorese says:
A good installer checks for software installation only on a well-defined range o...A good installer checks for software installation only on a well-defined range of disks, and checks to the best of its ability what is already on the storage before blindly formatting it.
There's a certain point where flexibility gets in the way of usefulness. Allowing random SAN LUNs to be specified for any random purpose doesn't seem reasonable.
Besides, my point is that DISCONNECTING -- not rezoning or disabling access -- is a manual process that doesn't scale well or translate to automated and remote processes.
Jun 06
Anonymous says:
As a Citrix user for over a decade i habe to admit that FUD like this makes me c...As a Citrix user for over a decade i habe to admit that FUD like this makes me chuckle to start with then i start to get angry. We use Citrix both xenapp (Platinum) and Esx 3.5. And do you know which product gives us most problems when it comes to Hotfix roll-ups and upgrades. It's Citrix...every time. In the employee purges i think Citrix got rid of to many technical developers and just left the marketeers running the show.
Jun 06
Anonymous says:
I have been labled a Citrix-Fanboy in the past so it is not like I am taking sid...I have been labled a Citrix-Fanboy in the past so it is not like I am taking sides here however I honestly feel the criticism of "Unplugging the SAN" is unfair and reaching for something that is just not there. Yes, unplugging SAN cables on 1000's of servers in an enterprise is not practical. However, also would be approaching your upgrade to vSphere using a "Big Bang" methodology. I would hope anyone in an Enterprise Environment with over 500+ ESX Servers would approach their upgrade with all of the best practices in mind, scheduling, pilot, and have a clearly defined IQ/OQ. From the pilot and testing, hopefully on your INT/DEV systems first, if you found that 50 to 100 were done successfully then you would be able to justify the risk of not including the extra step of physically unplugging the SAN cables, especially if your upgrades are be performed remotely or via Update Manager.(Personally in an enterprise, I would just vMotion the guests off the host, place the host in MaintMode and unpresent at the fabric) As with any upgrade, there is always some type of risk. Back in the day we used to pull drives to prevent accidental wiping of the RAID set information. Honestly, I can see the point of the extra labor it may cause by having to physically unplug SAN connections, but come on; reporting on it is another thing. I am sure citrix doesn't have any extraneous steps on installing and building XenApp, XenServer, or XenHamburger
When it comes down to it, you are criticizing the KB article for not thinking of the Enterprise Customer and all the extra labor it would take to "unplug" mass ESX servers. Hmm...Damn those KB authors at VMware for not creating two docs, one for the SMB and one for the Enterprise... : - )
Shanetech..
Jun 06
Anonymous says:
First off a blog is a blog not a company quote. I use XenApp, Xenserver, and ES...First off a blog is a blog not a company quote. I use XenApp, Xenserver, and ESX 3.5 in production at the hospital I work at and I can tell you having the vendor recommend unplugging my fiber just pushed back my vsphere rollout another 6 months to get downtime approval in a 24/7 shop. Regardless of how it came across in the blog it still sucks for those of us having to move forward on these state of the art techs.
Jun 06
Anonymous says:
I'm sorry, but how is unplugging fiber creating anymore of a downtime scenario d...I'm sorry, but how is unplugging fiber creating anymore of a downtime scenario during a vSphere upgrade than not unplugging the fiber?
Jun 06
Anonymous says:
Just spent a good part of the day upgrading a CAG to 4.6... great documentation ...Just spent a good part of the day upgrading a CAG to 4.6... great documentation
Shanetech
Jun 07
Anonymous says:
Hi Roger, I think the main issue is that the title of the Blog is a bit "gloatin...Hi Roger,
I think the main issue is that the title of the Blog is a bit "gloating". No doubting the facts, and that the steps to be taken are disruptive, but this comes across as a point scoring exercise against VMWare, whish is distasteful.
But...thanks for bringing the facts to our attention.
Jun 07
Roger Klorese says:
As others pointed out, it's a blog, not a policy statement, and it's a personal ...As others pointed out, it's a blog, not a policy statement, and it's a personal observation. While we don't always succeed -- and sometimes miss by a fair distance -- one of our primary goals with XenServer has been to simplify the installation experience. So I was surprised that a step that would require physically visiting each machine was listed as a mandatory one, not as just a recommendation, and I commented on it. That's all.
Jun 14
Anonymous says:
Is is not a requirement. Is is a precaution, just the XenServer recommendation t...Is is not a requirement.
Is is a precaution, just the XenServer recommendation to backup all VMs on the host.
People said that already, but you do not understand on propose, since this will kill your argument.
Be humble, and admit this is FUD, based on a wrong argument.
Jun 07
Anonymous says:
So VMWare thinks that SAN's only use Fiber? Or do they also want me to unplug th...So VMWare thinks that SAN's only use Fiber? Or do they also want me to unplug the CAT5? Big LMAO if you ask me..
Nice for those admins that want to use ILO or RAC or something similar to remotely upgrade their systems. "Hi, gutentag, is this the night guard speaking? Yes, hi, this is the systemadmin from HQ over in Atlanta. Could you go into our server room and very gently pull the very fragile orange cable from server 33 in rack 5 in SER 2? Its the one with the blue led flashing on the front and back. Thanks. I'll call you back when I need 34, 35, 36 and 37 pulled out aswell. Thanks!".
Jun 08
Anonymous says:
While the KB states to remove the connection it's an extreme precaution. The rea...While the KB states to remove the connection it's an extreme precaution. The reality has to do with the way that Anaconda presents LUNs to the ESX installer. It's a good practise to NOT have unnecessarily LUNs presented to the ESX host prior to install and the most extreme cases, where possible, physically remove them. In real practise, it's better to just zone/mask the LUNs away (this is the more common practise in enterprise environments).
If one is using iSCSI with hardware adapters during the install, the same principle would apply -- just do proper zoning. The whole idea is to avoid blowing away an existing mispresented LUN (e.g., Exchange or SQL server -- and I've seen this happen by some admins when the storage admin accidentally or mistakenly presents the wrong LUN). Anaconda doesn't recognize these as existing formatted LUNs but rather as unpartitioned. Since Murphy's Law exists heavily in IT, IMO, it's far better to be safe than sorry.
The only LUNs to be present during installation are the ones to be used for installation. This can easily be achieved by just masking them away. And that can be done remotely from one's Hawaii vacation spot if one needs to.
I would imagine that if one was to do a Xen boot-from-SAN or boot-from-iSCSI configuration, one would want to make sure the right LUNs are present to ensure that the "OOPS" factor isn't there as a possibility.
Linus
Jun 14
Anonymous says:
What a shame, your argumentation was completely debunked over and over, even by ...What a shame, your argumentation was completely debunked over and over, even by Citrix fans ....
By the way, vSphere can be upgraded smoothly using VMware update Manager, without touching the server physically.
Of course XenServer does not have anything similar in functionality.
This blog post deserves an entry on failblog.org something like, "Blog post FAILs miserably"
Fernando
Jul 06
Anonymous says:
Oh dear. Dear oh dear oh dear. Do you see VMware or its associates going for Cit...Oh dear. Dear oh dear oh dear. Do you see VMware or its associates going for Citrix in such a way?...No.
Boy this is getting pathetic....and not to mention tedious.
Xen for playroom, vSphere for men. Period.
Yawn.
Jul 06
Anonymous says:
Let's see... http://www.mikedipetrillo.com/mikedvirtualization/2009/03/open-clo...Let's see...
http://www.mikedipetrillo.com/mikedvirtualization/2009/03/open-cloud-manifesto-what-a-majestic-name.html\\
http://www.mikedipetrillo.com/mikedvirtualization/2009/02/citrix-xensource-acquisition-falls-short-of-some-partners-hopes.html\\
http://www.mikedipetrillo.com/mikedvirtualization/2008/11/end-of-the-year-citrix-revenues-still-have-me-scratching-my-head.html\\
(And before you claim it's an independent blog... it's not.)
Sep 01
Anonymous says:
Unplugging the fiber is a must if you want to avoid formatting your production V...Unplugging the fiber is a must if you want to avoid formatting your production VMDK LUNs with a new ESX install.
It really sucks it is even possible to do this but I have completely wiped out a LUN with 10 servers on it by doing
a upgrade from VI 3 to 3.5 with fiber plugged in that was zoned. Too bad they are just mentioning it now.
I have been a fan of VMware for many years but I think they are losing their ground now and are going to end up
hurting in the long run if they don't get their act together. The cost of VMware is almost prohibited espically with VSphere 4 price slap.
Add Comment