Getting away with 1 reboot?

[jftwp]

Has anyone done this after upgrading their ESX 3.x environment to ESX 4/vSphere? Since all VMs require 2 'upgrades' to get them fully up to snuf (lastest vm tools and virtual h/w v3 to v7), I'd rather not reboot twice. One of the breakout session leaders said you can do the following, but I'm a bit paranoid. Just wondering if anyone's done this to cut it down to one reboot instead of 2:

1. Upgrade vmtools in the guest. Do NOT reboot.

2. Shut down the guest.

3. Upgrade the vm h/w from v3 to v7.

4. Power up the guest and all is well(?).

Yes, I'm going to test this in my lab, but who's done this out there in prod and had zero problems doing so? Thanks.

[Josh26]

I recently did exactly the steps you discuss.

One reboot, following the upgrade of hardware version, Windows will popup a "new devices detected, please reboot for changes to take effect". You don't HAVE to reboot, but as far as I understand, you're not using the accelerated drivers until you do.

Unfortunately, two reboots seems to be required. Yes, it is a pain.

[golddiggie]

Here's a thought... Use Update Manager to drive the entire process for you... Then just watch the entire process to make sure no VM's have any 'issues' and you're done...

VMware VCP4

Consider awarding points for "helpful" and/or "correct" answers.

[jftwp]

Does the newest Update Manager handle shutting down VMs and converting them from v3 to v7 virtual h/w? Even if it did, I don't think we have 'enough' VMs for me to warrant going fully automated for something as 'fragile' as upgrading VM Tools and upgrading/converting the vHardware. What I think I'll end up doing is pussing out, announcing a downtime of perhaps 60 minutes for all VMs that affect users (file servers, print servers, certain app servers, etc) as part of our regular maintenance/patching that users are already used to anyway, and doing it all manually. If we had hundreds and hundreds of VMs, I might seek out more UM-style automation, but if I do them myself I'll KNOW that they were done right, will QA/validate each one afterwards, etc.

So I guess I'll just do what the recommended approach would normally be, which is to:

1) Snapshot the VM. Upgrade VM tools.

2) Reboot, check the VM for any issues. Delete snapshot if fine.

3) Shut down the VM. Take another snapshot.

4) Upgrade the VM hardware.

5) Restart the VM and check for any issues. Delete the snapshot if fine.

[golddiggie]

Before you "puss out" clone one of the VM's (make the NIC not come up on boot so it won't impact the original in any way) and try it. You can set how long to hold onto a snapshot (it takes one before going through with the updates). Under all the Remidate wizards you have the "Rollback Options" window where you can tell it to keep the snapshot for n hours, or "don't delete snapshots"... Once you've setup the baselines, it makes things a lot easier to detect VM's (and hosts) that are out of compliance and target them for updates. You can even schedule the remediate for later.

I see it as a useful tool to have in your array. You can also use it to update the guest/VM's OS and other software that is installed. You'll need to select what you want it to look for, and such, but you'll at least know. It also reaches out (daily in my case) for new updates and makes them available to you via the tool.

Test it out... If you don't like it, fine, but you just might... :smileyshocked:

Oh, and the current (4 u1) release does the VM hardware level updates as well as the tools as part of it's available processes.

VMware VCP4

Consider awarding points for "helpful" and/or "correct" answers.

[jftwp]

I hear ya... and I have plenty of time to determine which way I want to go, after all. It's not like upgrading the tools and virt h/w is a must immediately after upgrades of my hosts are complete (which I DO plan on using UM for). I'm kinda old school and recall UM not even existing back in the VC 1.x ESX 2.x days and all that, but anyway, yes, I'll play a bit before "pussing out" and check my comfort level with it, etc.

For company-wide patching, and including our physical Windows and Linux servers (yes, believe it or not, we DO in fact have several still; ha) we use BigFix, so I'm not really interested in UM's OS-level patching features as much as I am for the ESX-level patching/upgrading.

[golddiggie · Accepted solution]

I prefer to be more "hands on" when it comes to updating Linux servers (either VM's or physical). Since I use CentOS 5.x I also install the yum tools to use. Don't care for the bundled updater, sicne the yum tools do a (in my opinion) better job of it.

For Windows servers, I tend to use a WSUS server (most of the time a VM) that only installs approved updates. It takes a little more work to manually manage what is being updated, but it also means that only the update I approve are installed. I wouldn't trust the Windows automatic update for a second. Too often items installed that way are later discovered to conflict with other software, usually business critical items.

I've been testing out UM for Windows server patching/updating lately... With the exception of one VM (a SQL 2005 server) it is able to install all the updates I tell it to. You still have the granular control, if you want it, available to you...

It really does come down to which tools you're comfortable with. I just prefer to have more than one way to do something that I'm comfortable/proficient with.

VMware VCP4

Consider awarding points for "helpful" and/or "correct" answers.