Bug 782536

I suspect that this will be out of scope for 1.0, but we should discuss.

Ian, can you assess?

On page 11 of teh following doc I found the following statements:

http://www.vmware.com/pdf/vmware-tools-installation-configuration.pdf

The version of VMware Tools included in vSphere 5.0 is supported on vSphere 4.x and 5.0 virtual
machines. That is, you can also use this new version of VMware Tools in virtual machines on ESX/ESXi
4.x hosts.
n Virtual machines in a vSphere 5.0 environment support the versions of VMware Tools included in vSphere
 4.0-5.0. That is, you are not strictly required to upgrade VMware Tools if VMware Tools was installed
from an ESX/ESXi 4.x host.


I am going to update my target context to the latest v5 and verify.   Will update with results.

Created attachment 556126 [details]
scrren shot

Bad news

Updated my target content to point ot V5 tools and launched on a v4.1 host.

It does not report that the tools are installed.

I logged into the guest and the tools are installed:

[root@dhcp-124 ~]# yum list installed| grep vm
lvm2.x86_64      2.02.87-6.el6
lvm2-libs.x86_64 2.02.87-6.el6
vmware-tools-core.x86_64
vmware-tools-foundation.x86_64
vmware-tools-guestlib.x86_64
vmware-tools-libraries-nox.x86_64
[root@dhcp-124 ~]#

Steve,

Just to be clear.

Can you confirm that the v4.1 of the tools works on a v4.1 host?

Yes, they are. I've used them for several deployment this build and for
a lot on previous builds.

What we are working on is verifying the v5 tools work with v5.   Things
have changed for sure.

OK Steve, that seems like the right place to start. Once we know v5 tools work on v5 nodes, then we can try to sort out v5 tools on v4.1 nodes. Thanks for your help here.

I believe we can add further granularity to the target namespace (e.g. vsphere35, vsphere40, vsphere50, etc.) without too much pain.  I would, however, like to avoid this for 1.0 if we can.

Implementation-wise, my thought are either:

1) Create full builder classes for each of these newly created sub-targets.  Initially, these classes will be children of the original vsphere class that do not override anything.

2) Adopt a naming convention that allows us to specify, in a single string, a base target and a version.  For example "<base>-<version>".  Use only the <base> component to select the builder class to be used, then pass along the version component to allow the builder class to adopt version-specific behavior.  (And, of course, use the full "<base>-<version>" name for determining which sections of target.xml to use and on which providers the target_image can be launched.

Issues to be aware of:

* Do we maintain the notion of a generic "vsphere" target or do we force the use of a version across the board?  If we don't force, what convention do we use to deal with the generic target?

* At the moment, we determine if a provider is of type "vsphere" if it comes from the vsphere.json configuration file.  If we introduce sub-versioning we'll likely need to add the sub-version as a field in the config file.

scollier identified which packages from the V5 Vmware tools need to be installed so that the VM returns the IP in a V5 vsphere environment.

I used the same repo and packages for a VM running in a V4.1 env and it DID return the IP.

Concerns:

While we are looking for the IP there are many more features of the guest tools that we are unsure of the state.

In scollier's environment the vsphere console displays the followig for his guests "VMware Tools: ? Running 3rd-party/Independent".  I could not find any definitive on the meaning of this.

Those tools running in the V4.1 environment display "VMware Tools: Unmanaged".  Here is a VMware KB that is related - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1032763 - Reading more articles, it seems to indicate that the VMware will not handling the upgrading of tools, the user will neem to manage. There is a possibiity of starting the vmtoolsd will address.



http://www.vmware.com/pdf/osp_install_guide.pdf

Finally got around to install the V4.1 guestware tools on a guest running on a V5 host.

The IP was returned!

The vsphere console reported: 3rd-party/Independent

(In reply to comment #8)
> I believe we can add further granularity to the target namespace (e.g.
> vsphere35, vsphere40, vsphere50, etc.) without too much pain.  I would,
> however, like to avoid this for 1.0 if we can.
> 
> Implementation-wise, my thought are either:
> 
> 1) Create full builder classes for each of these newly created sub-targets. 
> Initially, these classes will be children of the original vsphere class that do
> not override anything.
> 
> 2) Adopt a naming convention that allows us to specify, in a single string, a
> base target and a version.  For example "<base>-<version>".  Use only the
> <base> component to select the builder class to be used, then pass along the
> version component to allow the builder class to adopt version-specific
> behavior.  (And, of course, use the full "<base>-<version>" name for
> determining which sections of target.xml to use and on which providers the
> target_image can be launched.

I'm sorry for my ignorance, but since the bug is ON_QA state, is there already a fix for 1.0 or do we avoid this for 1.0 and fix will be available for 1.1, if so then I would move this bug to ON_DEV. 
Thank you.

This appears to have been auto-approved because flags weren't flipped prior to moving to 1.1.0?.  This is will be considered for a future release.

This was very specific to the CloudForms use case.  The target_packages.xml feature is essentially unused in the existing upstream.  Users wishing to get a significantly different package set for different targets have generally been building distinct base images.  This isn't quite as elegant but ends up being more flexible.

Closing as WONTFIX.