Annoying changes made to the Update Manager in last VI3 update U2

[Voigt]

Hi,

after upgrading our whole Infrastructure 3 (Virtual Center, License Server, Update Manager and of course the ESX3 servers) we came across these really annoying changes made to the update manager.

First of all, we didn't have troubles installing it.

But after that our baseline for the updates was corrupted.

I tried to change it but it was only saying "error: object has no reference" (or something similar).

So I had to delete it and made a new one.

Naturally i started a new task to scan for updates on the ESX Server.

After waiting for about five minutes and seeing no improvement on the task (still standing at task in progress) I looked at the ESX Server.

The CPU of the server itself was very high (one of our cluster servers even get a red warning).

The logs on the server (hostd.log) showed a high number of tasks initiated by the Update Manager.

The whole procedure took about 15 minutes and created over 50 tasks while pushing the CPU to the peak.

I couldn't believe it. Till this "upgrade" the scan took about a couple of seconds and didn't touch the cpu a bit.

Has anyone else been observing such a behavior?

Regards,

Thorsten

[anttijf]

I am seeing this high cpu behavior also...

[RParker]

No but our UDM keeps disconnecting after about 5 minutes. I have to keep going into the plugins to reenable the manager on VI client. Then I have to reboot the UDM machine. I even reinstalled it (fresh DB each time) 3 times to fix it. I uninstalled, reinstalled the UDMS, tried to install the service on a different machine, nothing is working now.. I am going back to it later.. We just did the last round of builds (108908), so we are good until the next release of updates. I have a little while to fix it, but I am not optimistic......

[Voigt]

I know. Right after the upgrade the UDM kept disconnecting. We only restarted the VI server and made a fresh installation of the VI client. Since then it only occured one or two times again. As I wrote here (http://communities.vmware.com/message/1009619) I have the feeling that the 64-bit windows clients are not as stable as the 32-bit.

[Erik_Zandboer]

I see the same behaviour on various ESX 3.5 Update2 systems. What should be remarked though, is that only core0 shoots up to a 100% (the core which is used by the console). So the impact won't be that dramatical (unless you run 4vCPU virtual machines on a 4-core box), but still, it is not "nice" ...

[Voigt]

Yes, you're right. The update task is executed at 3am. Right before that some of the vms start their database backup. So the cpus are at an higher usage level when the update process fires.

OK, it's not as bad as it might first sound. But I don't get it, why the whole procedure hat to be changed. In addition to the cpu peaks and the remarkable long runtime per host the log file of the VC server is filled up with update messages.

It creates entries for each and every initiated scan task. Not only per host; it seems it does it per patch (even more when you look at the vpxd.log).

I'm still not sure if it's worth opening a case. It seems that there are a lot more important problems at hand.

[Erik_Zandboer]

All True. People who have VMs locked to a core should pay attention if VMs are bound to core0. Not that I know a lot of users who do this (except perhaps Citrix server VMs). It is still ugly!!

[Voigt]

Right. In addition to our first two clusters we have "recycled" three of our older HP DL380 G3. They have only two cpus with one single core. So we had the situation that some of the vms needed some more cpu time while the first cpu was dealing with the update processes. So DRS had to balance the vms between three hosts which were all running with one cpu with full load.

I think the problem should be clear for everyone and it seems to be a good idea to start a case on that.

Thanks for you input.

Update:

I've contacted the support and they could reproduce this behaviour.

Hopefully it will be changed in one of the upcoming patches also as we all know there are more serious problems at hand.