vsphere_static_160x300
Free Business and Tech Magazines and eBooks
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Tag Cloud
Feedjit.com
«
»

VMware Update Manager planning makes a difference

PostDateIcon November 2nd, 2008 | PostAuthorIcon Author: Rich Brambley

Did you take the time to plan for VMware Update Manager (VUM) when designing your virtual infrastructure architecture? Planning focus is usually on VirtualCenter (VC) server’s requirements, but then, in my experience, Update Manager and it’s default local SQL 2005 Express database seem to be added on the VC server simply because the installer is prompted about VUM during the VC setup routine. This scenario can create a poor performing VUM implementation.

Recently on the VMware Performance Team’s VROOM blog, John Liang’s post titled VMware Update Manager Performance and Best Practices Paper Posted announced a new whitepaper that should be a must read for any virtual infrastructure administrator preparing to use (or already using) VUM. The .pdf is a 14 page discussion on the topics that impact VUM such as performance, networking, resource consumption, and even virus scanning.

I find a few of these recommendations interesting, and the whitepaper leaves me wondering how common using VUM for virtual machine OS patching really is. I’ve created two informal polls, so please take a second to complete them and maybe we can get a quick gauge on how VUM is commonly implemented.

[poll id="2"][poll id="3"]

The whitepaper is a quick, informative read that I strongly encourage, but the following list of best practices was copied from the whitepaper’s Conclusion section.

VUM Best Practices

  • Separate the VUM database from the VirtualCenter database when there are 500+ virtual machines or 50+ hosts.
  • Separate both the VUM server and the VUM database from the VirtualCenter server and the VirtualCenter database when there are 1000+ virtual machines or 100+ hosts.
  • Make sure the VUM server host has at least 2GB of RAM to cache patch files in memory.
  • Allocate separate physical disks for the VUM patch store and the VUM database.
  • Because the Windows guest agent is installed in each virtual machine the first time a powered-on scan is run, the first powered-on scan command can take longer than subsequent scans. It may therefore be desirable to run the first scan command when this additional time will not be an issue.
  • For a large setup, powered-on virtual machine scan is preferred if VUM server resources are constrained or more concurrency is needed for scans.
  • Multiple vCPUs do not help VUM operations as the VUM guest agent is single threaded.
  • Configure each virtual machine with at least 1GB of RAM so large patch files can fit in the system cache.
  • Deploy the VUM server close to the ESX hosts if possible. This reduces network latency and packet drops.
  • On a high-latency network, powered-on virtual machine scans are preferred as they are not sensitive to network latency.
  • Check if on-access virus scanning software is running on the VUM server host. If it is, exclude the mounted disk on a high-latency network.

The first 2 conclusions about when to separate VUM and it’s database from VC leave me a little uncomfortable. That is, only worry about an independent instance of VUM after the 500 virtual machine or 50 ESX host mark? The storage requirements of VUM for saving years of ESX and Windows patches alone make me lean towards a dedicated server immediately, and then the bandwidth and latency factors as discussed in the whitepaper make me real nervous about burdening the VC server with the additional load. I’d rather be confident my VC server can do it’s intended job of managing my VI and keep VUM separate. Not to mention if the VC server already has SQL installed locally, then it makes me wonder if 4GB of RAM for VC, VUM, and SQL is even enough.

I’m curious for feedback on using VUM and how VM /ETC readers have it deployed. Please leave a comment with your experiences.

In the meantime here are some additional links on VMware’s update manager

Finally, Carlo over at VMware Info has written a great how to post for patching ESX with VUM. The VUM Administration Guide seems to be a little difficult to follow to me, and Carlo’s post is straight forward about how to configure VUM for updating ESX hosts.

Related Posts

PostCategoryIcon Posted in esx, patch, vi3, vmware | PostTagIcon Tags: , , , , , , , , , , ,
«
»
  • I started using VMware Update Manager almost immediately after its release. I had scripted patch deployments with an IIS web repository mastered but maintaining it was a pain in the rear. I use VUM for ESX host patching only. IMO, another Windows patch management solution wasn't needed when 101 already existed. MS WSUS does a great job at Windows patching so I'm sticking with that. VUM isn't mature enough to handle Windows patching and it needs to better support Linux patching. I've run into a few ESX patches that VUM burped over and didn't deploy properly. It was related to the specific ESX host hardware we have. We've got a modest environment with 11 hosts so I've deployed VUM on the VCMS. We do back end both VCMS and VUM with separate Oracle 10g databases. VUM needs a lot of room for its patch repository so allocate disk space liberally to VUM. I've found in all of my VUM deployments whether using Oracle or SQL2005 in independent environments for the back end, the VUM plugin icon irregularly disappears from the VIC because something is going on with the connection to the database so the plugin unloads. Re-enable the plugin and everything is back. I don't know why it keeps disconnecting. Seems to happen once very few days for no apparent reason.
  • Jason,

    Most of my customers stuck with WSUS for the VM OS patching too. I say most because for a few we just talked about VUM and did not implement - they did not plan for it and wanted to wait until they could allocate a server.

    I was not aware of the plug-in problems. That sounds like a hassle, but I guess you only need it once a month so maybe it's more tolerable?
  • The plugin issue is merely an annoyance. It can be re-enabled in 5 seconds with a few mouse clicks and VUM comes back to life in the VIC. Like I said, it only seems to happen once every few days. I wish I could put my finger on a pattern because as always, there's a technical reason for everything that happens. I'm just not interested enough yet (nor do I have enough time right now) to dig deep to find out why. I'm sure the answers are in c:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Logs\
  • For those that tried to do the poll and received the "Please choose a valid poll answer" message - I think I got it fixed now. If you still get this message please email me (use the About Me page for my contact info), send me a Tweet at @rbrambley, or if neither of the first 2 are possible than leave a comment here.

    Thanks.
  • /shameless plugs for my site incoming

    Hey Rich - I have set up Update Manager for a number of customers and I have updated my site with tips and tricks related to Update Manager. Of particular note is how to tell Update Manager to not Download Windows and Linux Patches if you won't be using them. Every single one I have set up so far has been ESX patching only. Enjoy!

    http://www.bladevault.info/2008/09/29/vmware-up...

    http://www.bladevault.info/2008/09/30/how-to-st...

    http://www.bladevault.info/2008/09/30/how-to-co...

    http://www.bladevault.info/2008/09/30/vmware-up...
  • Nicole Faust
    Hello Aaron,

    I've tried your links (www.bladevault.info...) and they only show "sponsored links".

    I would really like to read your tips and tricks regardind Update Manager !

    Thank you,
    Nicole Faust
  • Nicole,

    Looks like Aaron's bladevault.info site has been parked by GoDaddy and the previous content is no longer available. Aaaron has recently started contributing to http://blog.scottlowe.org. He has a couple of posts from the last 2 weeks there. maybe you can leave a comment for him on one of those posts inquiring about his older posts?

    Thanks,

    Rich
  • Joe Thomas
    I also started using VUM as soon as it was released -- I used to use a third party free product, which wasn't bad. VUM is great. I love it. I only patch my ESX hosts. I have continue to use Shavlik NetChk Pro for my VMs. I like the control and additional patching that it can do.

    Like Jason -- I also have the plug-in issue. You mentioned once a month -- Jason said "every few days". Mine is AT LEAST every few days -- usually every day. I generally just leave it disconnected until there are new updates and I am going to be using VUM. I do wish VMware would resolve this issue though.

    One problem I have found with VUM is that if it can't go into maintenance mode, the whole remediate hangs and eventually bombs. i.e. If a host can't be Vmotioned for some reason, the maintenance mode process hangs and times out, and the remediate process bombs. It would be pretty nice if that were detected when the remediate is submitted.

    When VUM first came out it was fast -- now it can take several minutes just to scan a single host. This also makes the remediate process longer since it scans during that. I have seen other people complain about this on the VMware forums. I am not sure what update to VIC caused this -- but somewhere along the line scans when from very fast to pretty slow. I even did a fresh install of VIC on a faster server and still see this behavior.

    VUM is a good addition and I am confident Vmware will continue to make it better.
blog comments powered by Disqus
Hyper9 Cowabunga
Support VM /ETC
Support VMETC.com

Support VMETC.com

Special Offers

Save 10% on select VMware products!

@rbrambley tweets
Advertisements
Facebook
VMETC
VMETC
Promote Your Page Too
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo

License
Creative Commons License
www.vmetc.com by Richard Brambley is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

Contact Us | Terms of Use | Trademarks | Privacy Statement
Copyright © 2009 VM /ETC. All Rights Reserved.

Powered by WordPress and WordPress Theme created with Artisteer.