There may be a better way to do this, but this is what worked for me.
After upgrading from VC2.01 to 2.02, I had some of the flaky issues with high availability as described in other posts.
Someone suggested I run the following:
service mgmt-vmware restart
After doing so, I noticed that I could not upgrade the vmtools on any of my vm's that were attached to that host. The upgrade box was greyed out.
After rebooting the esx server, the box was no longer greyed out.
Hello,
When you are upgrading ESX you are upgrading the SC Kernel and the vmkernel, to use the new versions it is imperative that you reboot the servers.
Best regards,
Edward
FYI AFAIK the VMKernel and the SC Kernel are one in the same and the Service Console only thinks it has its own kernel
euhm, sbeaver, there's definitely two kernels, a VMware-written VMkernel and a Linux kernel for the SC. If the VMkernel was included in, or contained, the Linux kernel, the VMkernel would need to be GPL. While I'd like to see the VMkernel source, I'm sure an opensource VMkernel is not going to happen.
I believe you have it reversed at least how it was explained to me. The VMkernel is the only Kernel and the SC is contained inside the VMkernel which is why nothing is on the GPL.
I could be wrong but this was how it was explained to me
So true!!
the service console runs under the \[CPU-scheduling, IO-scheduling, network] rules of the VMkernel, just like the VMs do. But to say that the SC kernel is contained in the VMkernel, is something I don't understand.
The service console linux kernel is in /boot/vmlinuz-... , while the vmkernel is included in /boot/initrd-... . How would one be contained in the other ?
OK I can understand that. Someone trieds to explain it to me a different way but I like your explanation a little better especially following the thought that the SC is really just a Bionic VM
a VM with some superpowers, that's exactly what it is