Comments on: VMware Update Manager, Updates, and New Builds http://www.boche.net/blog/index.php/2009/06/07/vmware-update-manager-updates-and-new-builds/ Thu, 09 Feb 2012 01:05:19 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Bjørn Anders Jørgensen http://www.boche.net/blog/index.php/2009/06/07/vmware-update-manager-updates-and-new-builds/comment-page-1/#comment-837 Bjørn Anders Jørgensen Sun, 07 Jun 2009 13:25:52 +0000 http://www.boche.net/blog/?p=1458#comment-837 Hi Jason. True, VUM is a hog, but usually you just point it to a cluster an let it chug along. Problem is when you have geographically dispersed data centers with high latency/low bandwith. Many times I've had to use esxupdate, and it is much faster. To the point that I now prefer it over VUM regardless of environment. I've never got to the point of automating it, but I think it would be quite trivial: Make the update repository available by NFS or FTP. Create a script in VIMA/vMA that: - puts the server in mgt mode (using vimsh) - deploy patches from repository - brings the server out of mgt mode You'd need some logic, especially if you are targetting a cluster, but it is doable. Add some replication and distribution nodes at different data centers, and you have a better solution than VIM IMHO. This doesn't help with guest patching though... - Anders Hi Jason.

True, VUM is a hog, but usually you just point it to a cluster an let it chug along.
Problem is when you have geographically dispersed data centers with high latency/low bandwith.
Many times I’ve had to use esxupdate, and it is much faster.
To the point that I now prefer it over VUM regardless of environment.
I’ve never got to the point of automating it,
but I think it would be quite trivial:

Make the update repository available by NFS or FTP.
Create a script in VIMA/vMA that:
- puts the server in mgt mode (using vimsh)
- deploy patches from repository
- brings the server out of mgt mode

You’d need some logic, especially if you are targetting a cluster,
but it is doable.

Add some replication and distribution nodes at different data centers,
and you have a better solution than VIM IMHO.
This doesn’t help with guest patching though…

- Anders

]]> By: Nick! http://www.boche.net/blog/index.php/2009/06/07/vmware-update-manager-updates-and-new-builds/comment-page-1/#comment-836 Nick! Sun, 07 Jun 2009 11:53:29 +0000 http://www.boche.net/blog/?p=1458#comment-836 Oh and I think the missing intelligence is the host never contacts the UM server. The UM server controls the ESX host down through vCenter but the communication doesn't flow the other direction. It would explain why UM just tries the next step 10 minutes later, because it has no idea when the previous step finished. Oh and I think the missing intelligence is the host never contacts the UM server. The UM server controls the ESX host down through vCenter but the communication doesn’t flow the other direction. It would explain why UM just tries the next step 10 minutes later, because it has no idea when the previous step finished.

]]> By: Nick! http://www.boche.net/blog/index.php/2009/06/07/vmware-update-manager-updates-and-new-builds/comment-page-1/#comment-835 Nick! Sun, 07 Jun 2009 11:50:02 +0000 http://www.boche.net/blog/?p=1458#comment-835 Staring at the task times in vCenter and the UM log on the server itself, it appears that every time it runs through a patch that requires a reboot (but it's using the flag to not reboot) there is still a _10 minute_ delay every time, and a very consistent ten minute delay. You can add 10 minutes to the end of the previous update and to the second the next task starts. For a pile of incremental patches, a lot of them individually want a reboot. It takes AGES. 10 minutes seems like some kind of hard coded "it should be back up by then" time, and its triggering that timer even though its not rebooting. You see this when the host itself reboots, and it's back, and you're wondering when UM is going to bother finishing up. You'd think it would notice the host is back quicker, but it's like it's not even doing any sort of intelligent checking for this. 10 minutes. This could certainly be cleaned up and I hope it is in vSphere... at the least it shouldn't pause on patches needing a reboot when there's other patches applying. If you are running an ESXi environment, then this is not as much of an issue with UM as no matter how far behind you are, there's only 1-3 patches to apply or so and only the firmware needs a reboot. Our ESXis roll through much faster. Staring at the task times in vCenter and the UM log on the server itself, it appears that every time it runs through a patch that requires a reboot (but it’s using the flag to not reboot) there is still a _10 minute_ delay every time, and a very consistent ten minute delay. You can add 10 minutes to the end of the previous update and to the second the next task starts. For a pile of incremental patches, a lot of them individually want a reboot. It takes AGES. 10 minutes seems like some kind of hard coded “it should be back up by then” time, and its triggering that timer even though its not rebooting. You see this when the host itself reboots, and it’s back, and you’re wondering when UM is going to bother finishing up. You’d think it would notice the host is back quicker, but it’s like it’s not even doing any sort of intelligent checking for this. 10 minutes.

This could certainly be cleaned up and I hope it is in vSphere… at the least it shouldn’t pause on patches needing a reboot when there’s other patches applying.

If you are running an ESXi environment, then this is not as much of an issue with UM as no matter how far behind you are, there’s only 1-3 patches to apply or so and only the firmware needs a reboot. Our ESXis roll through much faster.

]]>