VMware Cloud Community
ShawnPD
Enthusiast
Enthusiast

Attached Baseline status change after 201011401BG

OK so we attempted to remediate several hosts using update manager.  Initially one team member did an update based on the three patches that VUM showed as applicable.

After remediation the attached baseline "Upgrade from esxi 4.0 to 4.1 changed from compliant to Incompatible.

If I select the baseline, then select the "upgrades" in the bottom part of the pane there is a yellow bang on the upgrades.  If I select the upgrade the error pops up with this info.  ...The upgrade has a missing package for host...of type embeddedEsx.

Has anyone else seen this?  Is it really an issue?  The host seems like it is running correctly.  But would perfer to find out now rather than later.

BTW we are running ESXi 4.1.0, 320137...patching from 260247.  This is an issue with those hosts that were upgraded from 4.0 to 4.1 as well as clean installs of 4.1 260247.

upgrade_incompatible.jpg

0 Kudos
3 Replies
jlf175
Contributor
Contributor

We have actually seen this on our hosts too. What's pecuilar is that this patch is for going from 4.0 to 4.1 even though our hosts have already been updated to 4.1.  (4.1.0, 320092 to be exact).

This notice appeared after we did a second round of patching at the beginning of this month while our move from 4.0 to 4.1 occurred several months prior.

0 Kudos
ESchon
Contributor
Contributor

We've seen the same behavior.  We had upgraded the hosts to ESXi 4.1 from 4.0 u1 and in January had gone back to patch with the three patches that had come out since November.  After patching, only one of the servers in a cluster had this error but we haven't seen any performance issues yet.

0 Kudos
ESchon
Contributor
Contributor

To round out our issues with this: after a few reboots for various reasons, all of our hosts are now showing this issue.  Discussions with the support team seem logical in that this is now an outdated baseline and should be detached.  No performance issues were found and no negative entries have been found in the logs (either by us locally or by the VMWare support team).

0 Kudos