[sles-beta] SLES11-SP4 beta2 x86_64 - VMware Tools Again ...

Mike Latimer mlatimer at suse.com
Tue Mar 10 21:39:02 MDT 2015


Hi Matthias,

On Wednesday, March 11, 2015 02:59:40 AM Matthias G. Eckermann wrote:
> Well. In my view, this behaviour is consistent and
> correct, and here is why:
> 
> 1. An Upgrade from SLES 11 SP3 to SLES 11 SP4 should
>    deliver an identical result as a fresh installation
>    of SLES 11 SP4.
>
> 2. Automatically installing the open-vm-tools is
>    recommended in a fresh installation, as only this
>    way we get the best user experience.
> 
> 3. If we include the open-vm-tools and install it,
>    if a VMware environment is found during an initial
>    installation, this should also be done during an update.

While the above comments make sense, we were specifically concerned about 
residual files which might conflict with open-vm-tools components. Based on 
these concerns, the original intent for SLES11SP4 was to make installing open-
vm-tools a choice - rather than an automatic installation. (See FATE#318106, 
comment #10). (We also specifically decided that removing VMware tools prior to 
the open-vm-tools package was not a safe option.)

The automatic installation of open-vm-tools is due to a 'Supplements' 
statement in the open-vm-tools package which matches a VMware pci device ID. I 
made this change for SLES12, and removing it for SLES11SP4 should "fix" it (if 
we decide to go that route).

> I am afraid that solution contradicts the consistency
> requirement described in the beginning of this E-Mail.
> 
> My proposed solution is to document the new availability
> of the open-vm-tools in the release notes and add also add
> an autoyast snippet there, how to prevent the
> installation, if the old vmware tools are installed.

This may be a possibility, but it would only impact autoyast installations. Is 
this worth the effort - at the risk of breaking non-autoyast based upgrades?

Thanks for the comments,
Mike


More information about the sles-beta mailing list