"Umanaged" basically means that VI Client is not going to manage vmware tools (i.e. it won't try to update the tools on the appliance).
The ISV(the author) of the appliance is in charge of the vmware tools version on the appliance. You can release updates for tools using the update service provided by VMware Studio.
You can find new tools for your OS from here: http://packages.vmware.com/tools
PS: The user of the appliance can also download the latest tools from here and update the VM/appliance.
> I am building a Virtual Appliance using VMware Studio 2.0, with Ubuntu 8.04-1 as the guest OS. This appliance will be certified "VMware Ready" .. Hopefully..
> The problem is, the VMware Tools are being reported as "Unmanaged" in the VI client summary. Does anyone know if this is acceptable? What are the downsides to it being "Unmanaged"? The VMWare Tools that were installed were the defaults for that particular guest-os, which are the open-vmware-tools.
> Any help would be greatly appreciated!
As the author of the VRVAP test matrix / guidelines, I'm happy to answer:
"Unmanaged" is a valid state for VMware Tools, and indicates that some mechanism other than the classic VMware Tools "interactive/scriptable" installer engine is responsible for keeping the tools components "up to date".
This is what I would expect to see for the majority of newer virtual appliances being submitted for evaluation/validation through the VMware Ready Virtual Appliances Program.
Typically the "unmanaged" state is triggered by one of three cases:
VMware Operating-System Specific Packages (OSPs) served from http://packages.vmware.com
Open VM Tools
VMware Studio 2 supplied OSPs
The salient bit is at the end of TC 2570 VMware Tools -- General.
The core set of Guest OS side functionality components known as "VMware Tools" MUST be present, enabled, and operating properly. Information further defining this requirement is covered in test cases 2571 through 2579. The precise VMware Tools ABI version and build number to be used are not prescribed.
If you want to dive into more detail...
Any guest daemon compiled from Open VM Tools source will automagically report itself as unmanaged, per:
Open VM Tools public source code @ November 2009 ..../ChangeLog ~Lines 641 - 643 ..../lib/include/vm_tools_version.h ~Lines 70 - 82 ..../services/vmtoolsd/toolsRpc.c ~Lines 125 - 154
The value reported is 0x7fffffff (or 2147483647 in decimal), which meets three criteria:
1) Outside the boundaries of normal VMware Tools version data (which is constrained to 5-bits . 5-bits . 5-bits or 0x7fff)
2) Maximum value of signed integer
3) Inside the boundaries of the unsigned integer (uint32) used to actually store the value
This magic Tools ABI value means that the "Tools" installed originate from the Open VM Tools branch or another branch of "Tools" which is not considered a managed "VMware Tools" release and are exempt from VMware Update Manager (VUM) checks with respect to whether or not the "Tools" are "current".
This is entirely different than VUM determining that a particular in-guest package is out of date, based on an update manifest supplied to VUM from the VA maintainer.
If VMToolsd (guest daemon) is running and responding properly from within the Guest OS with the magic Tools ABI value of 0x7fffffff (or 2147483647 in decimal), various locations within VMware products will:
Passively report VMware Tools as "Unmanaged"
(Numerous locations across entire product line)
Reporting yourself as "unmanaged" in the context of VMware Tools does not affect your ability to VMotion (host-to-host VM migration while running).
Wow! Thank you so much! The detail in your answer is very, very helpful.. I'm trying my best to make sure the submission for the appliance passes the certification. Could I contact you for any other questions in regards to the VMWare Ready certification?
I'm struggling to find a contact to answer some basic questions on the exam, and I'm doing my best to follow the matrix to the T.
is it possible to run pre-freeze-script with VMWare Tools in status Unmanaged (or is this a Problem of open-vm-tools)
According to KB 1032763, if the tools are unmanaged, we can no longer upgrade the virtual hardware of the guest and the only fix is to uninstall the OSP and re-install the Tools that come with the host.
Is there any other way around this? Although almost all of our Linux guests are hardware version 4, I expect the same problem the same limitation when the next hardware version comes out.
What's a customer supposed to do? Give up the ability to upgrade the virtual hardware to make it easier for the Linux admins to upgrade the tools?
The idea is that, in an appliance, the author/ISV of the appliance would want
more control over what is installed into it. So, if the ISV wanted a new
version of tools in the appliance, they would make an update with Studio with
the new tools version, test it, and then make that update available to their