open-vm-tools-devel

Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[John W. <jl...@sc...>]

I have the basics for vmtools ported for OpenServer 6.  The RPC loop
is running and the hostd.log file on the ESX host reports the current
heartbeat status as green.

But, the vSphere Client Summary tab for the running VM indicates:

   "VMware Tools: Not Installed"

And it has consistently been displayed that way except for about 1/2 hour
of  testing during which the status was displayed as "Unmanaged" while
the RPC loop was running, and "Not Running" when vmtoolsd was killed.

The "Not Installed" status has returned, but that got me digging a 
little bit.

Managed Object Browser:
===========================================
The Managed Object Browser (MOB) of the GuestInfo for my running OSR6 VM
shows:

   toolsRuningStatus  string                      "guestToolsRunning"

   toolsStatus        VirtualMachineToolsStatus   "toolsOK"

   toolsVersion       string                      "2147483647"
                                      (32 bit MAXINT - 0x7fffffff)

                            - probably the TOOLS_VERSION_UNMANAGED

   toolsVersionStatus string                 "guestToolsNotInstalled"


Now, from the top three items, I would have expected the
"VMware Tools:" status to at least indicate "Unmanaged".

Clearly the last item "toolsVersionStatus" is being set incorrectly (?)
and that is apparently what results in the

   VMware Tools: Not Installed

being displayed in the vSphere Client Summary tab for a running VM.


I have confirmed that services/vmtoolsd/toolsRpstatusc.c is sending
the "tools.set.version 2147483647"

ESX 4.0 (build-398348): /var/log/vmware/hostd.log
===================================================
Looking in the ESX 4.0 host /var/log/vmware/hostd.log I see:

   - the tools status is changed to "running"
   - the tools version changing from 0 (default) to
                          TOOLS_VERSION_MANAGED
   - and then a struggle between "Unexpected toolsVersionStatus
     notAvailable - using offline status guestToolsNotInstalled"
     and "changing status to running"

      - repeating within msecs - not on to 30 sec vmtools polling
        interval

      - rapidly filling /var/log/vmware/hostd.log

      - section of log attached (hope the attachment is usable)


/vmfs/volumes/*/<VM>/vmware.log file contains:
===============================================

Jul 21 14:24:12.677: vcpu-1| GuestRpc: Channel 0, guest application toolbox.
Jul 21 14:24:12.677: vcpu-1| Vix: [104286 mainDispatch.c:3169]: 
VMAutomationReportPowerStateChange: Reporting power state change 
(opcode=2, err=0).
Jul 21 14:24:12.696: vcpu-1| TOOLS ToolsCapabilityGuestConfDirectory 
received /etc/vmware-tools
Jul 21 14:24:12.701: vcpu-1| TOOLS setting legacy tools version to 
'2147483647', manifest status is 4
Jul 21 14:24:12.702: vcpu-1| DISKLIB-DDB   : "toolsVersion" = 
"2147483647" (was "0")
Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value 
set to 'notAvailable'
Jul 21 14:24:12.732: vcpu-1| TOOLS unified loop capability requested by 
'toolbox'; now sending options via TCLO
Jul 21 14:24:12.734: vcpu-1| TOOLS sending 'OS_PowerOn' (3) state change 
request
Jul 21 14:24:12.735: vcpu-1| Guest: toolbox: Version: build-402641
Jul 21 14:24:12.815: vcpu-0| TOOLS state change 3 returned status 1



The question is what am I forgetting to set?

Thanks.

-- John Wolfe      UnXis, Inc.

Re: Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[Marcelo V. <mv...@vm...>]

Hi John,

On 07/21/2011 01:32 PM, John Wolfe wrote:
> Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value set to
> 'notAvailable'

I'm pretty sure this is a bug in VMware's host code, so there's nothing you can
do from the Tools side. Someone else reported a similar issue here before, and
we've already fixed the host code in the vSphere 5.0 release. (I don't think the
fix was backported to any maintenance release of previous vSphere versions.)

-- 
- Marcelo

Re: Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[John W. <jl...@sc...>]

Marcelo,
Petr,

Is the "bug" in vSphere 4.x flaky enough for the tools status
to occasionally be reported as "unmanaged" for unsupported guests?

   - yesterday my OSR6 VM was "Unmanaged" for several reboots
     and restarts of the vmtoolsd
   - today, following a power-hit to our Intel Modular Servers,
     an OSR507 VM was rebooted and is reporting a VMtools status of
     "Unmanaged" - through several shutdown and power-up cycles. 
     Previously the status was being reported as "Not Installed".

Is there anything that I can do to reduce the number of tools
running, not  running, version not available, not installed
messages that are being dropped into /var/log/vmware/hostd.log?

-- John


Marcelo Vanzin wrote:
> Hi John,
>
> On 07/21/2011 01:32 PM, John Wolfe wrote:
>   
>> Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value set to
>> 'notAvailable'
>>     
>
> I'm pretty sure this is a bug in VMware's host code, so there's nothing you can
> do from the Tools side. Someone else reported a similar issue here before, and
> we've already fixed the host code in the vSphere 5.0 release. (I don't think the
> fix was backported to any maintenance release of previous vSphere versions.)
>
>   

Re: Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[Marcelo V. <mv...@vm...>]

Hi John,

On 07/21/2011 03:01 PM, John Wolfe wrote:
> Is the "bug" in vSphere 4.x flaky enough for the tools status
> to occasionally be reported as "unmanaged" for unsupported guests?

The flakiness of the status does look weird; but looking at the fix for the bug,
it does seem like it would properly handle this case. The bug was that the
status could be set to "not installed" if the configured guest OS did not have a
VMware tools package (which would be the case for "other" or "sco" guest OS types).

I don't know if "could" there means that the status would always be set to "not
installed". But with the fix, if the Tools version is "unmanaged", that's always
properly reported, regardless of the OS type.

> Is there anything that I can do to reduce the number of tools
> running, not  running, version not available, not installed
> messages that are being dropped into /var/log/vmware/hostd.log?

The workaround that the user who first complained used was to set up the VM as
"linux" or "linux 64-bit". That would work around this particular bug, since we
do have a Tools package for Linux.

I'm not sure whether ESX 4.1 has a specific guest os type for SCO. I think we
have some internal tweaks for SCO regarding time keeping, that are only applied
if you choose the appropriate guest OS type. So changing it to Linux might have
some adverse side-effects.

-- 
- Marcelo

Re: Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[John W. <jl...@sc...>]

Marcelo Vanzin wrote:
> I don't know if "could" there means that the status would always be set to "not
> installed". 
Could vs. would seems to suggest some variability in observed behavior. 
We can assure  OSR5,  OSR6 or probably UW714 VM users on ESX 4.x
hosts  that the display of the IP(s) and system name indicate that
open-vm-tools are installed and running on their VM.  That should
satisfy everyone.
> The workaround that the user who first complained used was to set up the VM as
> "linux" or "linux 64-bit". That would work around this particular bug, since we
> do have a Tools package for Linux.
>   
I think that it would be preferable to display the correct Guest OS type. 
(See below)
> I'm not sure whether ESX 4.1 has a specific guest os type for SCO. I think we
> have some internal tweaks for SCO regarding time keeping, that are only applied
> if you choose the appropriate guest OS type. So changing it to Linux might have
> some adverse side-effects.
>   
Our current OSR 5.0.5 VA released was generated on WS for Windows 6.5.x
as:

     Other:  Other-32  (No SCO guest type available then)
     VM version:        4      
     open-vm-tools:     2010.03.20-243334

         INFO_OS_NAME = null string.

and that guest OS type is carried through the import of the VA and running
of the VM.

Our OSR6 efforts are starting with generation of the VM on
ESX 4.0 which offers guest OS types for "SCO OpenServer 5" and
"SCO UnixWare 7", but nothing for OpenServer 6.

      Other:   Other-32
      VM Version:    7
     open-vm-tools:  2011.04.25-402641    (port starting point)

         INFO_OS_NAME = "openServer6"

I just invented an OS_NAME string which triggered a warning in the
hostd.log file about an unrecognized/unsupported guest OS.   A search
through the  ESX host files revealed Guest OS types for "openServer5",
"openServer6" and "unixWare7".

When open-vm-tools was modified to provide INFO_OS_NAME
as "openServer6", the vSphere Client will switch from "Other-32" to
"SCO OpenServer 6" on a running VM.

The next release of open-vm-tools for OpenServer 5.0.7 will by corrected
to provide "openServer5".

-- John Wolfe

Re: Should open-vm-tools appear as a running (possibly unmanaged) in the VMware Tools status of vSphere Client?

[Marcelo V. <mv...@vm...>]

Hi John,

On 07/26/2011 08:43 AM, John Wolfe wrote:
> Our OSR6 efforts are starting with generation of the VM on
> ESX 4.0 which offers guest OS types for "SCO OpenServer 5" and
> "SCO UnixWare 7", but nothing for OpenServer 6.

The identifier provided by the guest os is, mostly, used for the UI only. The
other uses are for features that wouldn't support SCO anyway, so having it not
completely accurate wouldn't really be a problem aside from the cosmetic issue.

The warning you saw in hostd's logs is because it expects the guest to provide
exactly the same string it has in its internal table; looking at the ESX 4.0
sources it seems there are three flavors of SCO: openserver5, openserver6 and
unixware7. I don't know for sure but my guess is that they are case-sensitive.
They're also not marked as fully supported, although I don't know if that flag
affects anything in the UI (e.g. whether to show the OS when setting up a new VM).

But none of this fixes the original bug that was fixed on ESX 5.0, where the
Tools status would be incorrectly reported for OSes that don't have official
VMware Tools packages. So I can't really tell you what the exact behavior there
would be, because I don't know.

-- 
- Marcelo