Hi All, hope this is the correct place for this.
I have autodeployed two hosts. I have created the host profile from the reference host and applied it to the second host. This has all been working pretty darn good but I this morning, I have a niggling problem.
I applied the host profile to the second host, rebooted it, about 5 times now, but I keep getting the host is not compliant Host requires reboot before previously applied configuration changes will take effect. It doesn't say how it is non-compliant, I have rebooted numerous times... and I can't figure out where to look ... I have run the compliance check numerous times, and it just says the same thing. The last think I had done was to change the advanced software setting in uservars to uservars.suppressshellwarning to 1 to get rid of what I though was going to be the last warning I had in the summary tab for that host, but now I have the non-compliant warning grrrr... any ideas on what I can look for and where to get more details on this, or why it keeps thinking I need to reboot?
On another note, are a lot fo people using auto-deploy? This is in my lab, but I am planning on having all 10 of our hosts start using autodeploy early next year and I want to know if it is truly mature and reslilient enough to deploy in our datacenter brefore I get myself in serious trouble ... it does seem like it works well - but that I have to reboot the hosts, and reapply the host profile someimes even if I haven't changed it...
Very interesting... just spent 1.5 hours with VMware support in this issue without any luck.
Did you get this answered/resolved?
not really... I've been having tons of issues with autodeploy in my labs... I have a 5.0 setup and a 5.1... I have only seen this problem in 5.1, not in my 5.0, but... saying that, I think 5.1 is more stable. Yes I get the compliance warning, but everything seems to work. My 5.0 lab just decides to blow up every so often... I'll reboot and all the port groups and adapters will have migrated from dvs to svs that it seems to create on the fly. I edit the profile and put a password in it and it doens't remember it, goes back to no password and various other things that keep happening. I've had to recofigure the reference host about 5 times now from nearly scratch... I'm using dvs for all my switches pretty much - it seems that is the bit that is makes it blowup. Right after I migrate the management portgroup and adapter from the svs it does it, all looks good and within 5 minutes, the host disconnects, I can reconnect if I add the host on the other management interface, and then the original vmkport comes back. I'd say I was doing something wrong, but, I have the exact same setup - networks, dvswitches, iscsi devices... everything in my 5.1 lab and that works perfectly. The only reason I have the 5.0 lab is for prepping for my VCAP DCA once I pass that, I'm going to use it as a test for upgrading a 5.0 vcenter to 5.1 as I need to do that in real life in our datacentre.. anyway, sorry, none of this is much help to you, all I can say is that the non-compliance doesn't seem to cause any problems other than the warning.
I ran into this same issue. There was an issue with the cache state and it not overwriting the orginal storage. Mine was a bug that when you have set it for stateful and then go to stateless the rebuild will not overwrite the original install. This then prompts for a reboot to put in the correct mode. I did also have a stateless caching issue in my host profile complaince check. Format the storage the host is installed on and then reboot and let the stateless/stateful caching rebuild your cache. Also, what settings are you doing for your caching?
If you can provide a little more detail of how you have setup your autodeploy I can try it in the lab and see if I can figure it out.
Interesting... I had auto-deploy running in a lab as a POC with 5.0. No issues to report and we decided to move forward with it.
In the meantime 5.1 was released with cached mode, the prod environment was built with 5.1. The first cluster that I converted had local disk so I turned on cached mode... I have been frustrated since then... My major problem is inconsistancy/ odd behavior and so on...
I had my case escalated with VMware and now have a pretty good engineer on the case and we have daily calls.
Reading your thread I wonder if most of the problems are not related to cached mode. and regarding the reboot message. VMware has isolated the settings that are modified that are generating this error message. In our case they are the Net/TCP values recommended by NetApp for NFS.
Another observation is that the settings sticks to the correct value between reboots... So it seems that there is a flag on these settings to say a reboot is required and that is what is causing the error
Amusing but if I recall correctly, applying these settings through the netapp VC plug-in never requires a reboot.
Message was edited by: GregL75
yes, interesting... this was the first I have heard about the caching. I've read up on it a bit now in the VMware docs where it describes what it does, however I wasn't able to find how to change any settings... This is vsphere 5 and it I have not changed any cache settings, so I guess they will be at default.. I've just reread the whole autodeploy section of the installation and setup guide and it doesn't mention any settigs for caching, can you provide me with a pointer to any settings please? I would like to fully understand this.
Ahh, caching was brought up in 5.1. I would check and see if you have an installed version of esx on the HDD boot devices and uninstall that and try again and once you do up date your host profile and reboot.
In 5.1 the host caching (or stateful install options) are located under the host profile> System Image Cache Configuration.
I dont have a 5.0 lab at the moment so I can't do much testing but the image stored on the local drive has given me plenty of issues with this before.
What host profile release are you using? I am working on a similar case and I have come across a KB that might help some people but not others. Restarting the vCentre service, web service etc might also be a valid step.