Update Manager Experiences

[epping]

Hi all

i am doing some testing and writing our corp procedure for update manager.

thinks are not going so smoothly.

after setting up a test environment with a cluster containing 2 x 3.5 nodes (no patches) and a vc with 2.5 (no patches).

I remediated at the cluster level and the vms got migrated across to the other node ok and the host entered maintenece mode and all updates installed, however when the second node remediated and was asked to go into maintenece mode the operation timed out ( got some errors that vms could not be migrated, however before my testing i successfuly did vmotions on all vms).

after it eventulay failed it automatically tried again but this also failed.

it does not fill me with confidence !! are there any patches that i should have for this product !!

I am thinking if i have problems on a 2 node cluster what is going to happen on a 12 node cluster !!

anyone else been through the pain and got it working smoothly

thanks

[geeko71]

i have similar issues.... ('m still playing with update manager in a live enviorement with 7 Hosts and 129 VMs)

Does any VMs has the same "Virutal Hardware Version 4" and actual VM Tools installed?

Do you have DRS enabled in Manual Mode (then have a look in the DRS Recommendations Tab)?

Sometimes i have to remediate 2 or 3 times until the TaskLog is free of errors.

After patching, when the host is back from Maintenance Mode the "Remediate Entity" Progress Bar is hanging on around 75%. Then an click on another host can refresh the screen

Hope the latest Build will fix this issues...

Cheers

[kjb007]

I haven't had the same issues as you yet, but then, I haven't had enough confidence to remediate the entire cluster in one shot. I've remediated one esx host at a time, and that has gone fairly well. I suppose I have a new thing to test out.

-KjB

[geeko71]

ah, OK... i've newer tried to remediate the entire cluster...

i can check that if there any updates ready, im at the latest patchlevel now..

[epping]

i have discovered what the problem is

after updating one host successfully in the cluster, the second host tries to go into maintenance mode - this times out.

the time out is to do with it not being able to successfully migrate the VMs on to the newly patches host, in the log i can see this is because of a warning that the CPU features are different and will be changed when migrated to the new host (exact same hardware so must be due to an update on the first host).

i validated this by doing a manual VMotion and got the same warning although the migration was successful.

the problem is that DRS (that is in charge of the migration when the host goes into maintenance mode) will fail if any VM shows a warning.

my testing shows that the only way do use Upate Manager with 100% success is to manually VMotion the VMs off the host and use Update Manager to install the patches, unfortunatly this has to be done at the host level

this is a massive pain for large deployments

[kjb007]

The CPU warning is due to CPUID masks applied when vmotion'ing between different builds of esx. Meaning, vmotion from 3.0x->3.5 will produce that warning, and lately, it apperas going grom 3.5->3.5U1 will produce warning. Once your hosts are at the same level, you should not get the warning any longer. It may not be fully autoamted now, but it should be in the future. You can also suppress warnings on vmotion checks, but you can search the forums for that as well, since that can be dangerous.

-KjB

[epping]

hi kjb007

that sounds correct as i was going from 3.5 to 3.5 update1

My concern is that we will get the same issue every time the CPU masks change i.e. if there is an update from 3.5 update 1 to 3.5 update 2. To be honest i dont know why this individual issue produces a warning.

I have done a search and can not see anything on preventing the warnings - can u remember where it was ?

thanks

[kjb007]

This will remove the test for cpu compatibility, so use at your own risk. If you decide to use it, post back and let me know if it fixed your issue.

See bottom of this thread: http://communities.vmware.com/thread/36538

Basically, edit vpxd.cfg right after the <config> tag

<migrate>

<test>

<CpuCompatible>false</CpuCompatible>

</test>

</migrate>

[epping]

Hi, thanks for seaching that out for me.

I would be OK disabling warnings but this seems to disable all CPU checking !! i will wait to hear back from VMware on this one. What i really want is for them to disable CPU warnings in this kind of instance i.e. if the version of VI is different the feature set may be different but a VMotion will always work (if a upgrade makes VMotion not work this is a serious issue)

thanks

[kjb007]

Yes, and a vmotion will still work, but as you've found, maintenance mode fails on any warnings, even if the underlying vmotion would have succeeded.

Good luck, and let us know if vmware comes back with anything.

-KjB

[ejward]

I have similar issues all the time. I thought the issues were resolved in one of the previous updates. I tried to apply the recent round of patches to a cluster of hosts and it kept failing. I had to manually Vmotion the VMs off the host before it would work. t's getting to be a pain.

[rreynol]

I wonder if the EVC (Enhanced VMotion Compatibility) feature of Update 2 will alleviate this. Basically EVC enforces CPU compatibility for all the hosts in the cluster. VC will not allow you to add a host to an EVC cluster if it does not meet the compatibility criteria. We have tested this and it allows you to VMotion a VM from an HP DL385 G1 to an HP DL585 G5 with no problem. You do have to enable nx in the BIOS of G5 since it is disabled by default on the G5 but enabled by default on the earlier DL585 and DL385 servers.

[jccoca]

Disabling compatibility test it's working fine for us with VC 2.5, but we are testing it with VC 4 and it doesn't works, any idea on how to disable on VC 4?