Bug 1662278

Summary: [ESXi][RHEL7.7]Enable cloud-init by default to change the systemd unit file vmtoolsd.service
Product: Red Hat Enterprise Linux 7 Reporter: ldu <ldu>
Component: open-vm-toolsAssignee: Cathy Avery <cavery>
Status: CLOSED ERRATA QA Contact: ldu <ldu>
Severity: medium Docs Contact:
Priority: high    
Version: 7.6CC: berrange, boyang, cavery, jen, jjarvis, jsavanyo, ldu, leiwang, pengpengs, ravindrakumar, ribarry, rjones, yacao
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: open-vm-tools-10.3.0-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1660713 Environment:
Last Closed: 2019-08-06 12:57:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1644335, 1660713    
Bug Blocks: 1623281    

Comment 2 Cathy Avery 2019-03-07 20:05:19 UTC
Lili,

Do you happen to have an esx 7.7 vm that I can test my build on?

Thanks

Comment 3 ldu 2019-03-08 01:49:41 UTC
(In reply to Cathy Avery from comment #2)
> Lili,
> 
> Do you happen to have an esx 7.7 vm that I can test my build on?
> 
> Thanks

@Cathy, as only have nightly build for RHEL7.7 ,I will prepare one nightly RHEL7.7 for you, and send the detail info to you via mail.

Comment 4 Cathy Avery 2019-03-08 15:23:53 UTC
From berrange@redhat.com

@ pengpengs@vmware.com please respond.

> @Cathy,
> 
> I still sugeest keep “DefaultDependencies=no” to vmtoolsd.service file.
> There is no need this flag in cloud-init-local.service. 
> With this flag and “before=cloud-init-local.service” flag in
> vmtoolsd.service, they makes sure vmtoolsd service start before
> cloud-init-local.service, this is necessary for cloud-init based guest os
> customization.

This doesn't really make sense. 

'Before=cloud-init-local.service' should be sufficient for vmtoolsd.service to be started before cloud-init-local.service.

The effect of the default behaviour (aka DefaultDependancies=yes) is merely to add an After=sysinit.target / Before=shutdown.target - these are very early targets. So this wouldn't invalidate the Before=cloud-init-local.service dependancy

[man systemd.service]
   Default Dependencies
       The following dependencies are added unless DefaultDependencies=no is set:

       ·   Service units will have dependencies of type Requires= and After= on sysinit.target, a
           dependency of type After= on basic.target as well as dependencies of type Conflicts= and
           Before= on shutdown.target. These ensure that normal service units pull in basic system
           initialization, and are terminated cleanly prior to system shutdown. Only services
           involved with early boot or late system shutdown should disable this option.
[/man]

So setting DefaultDependencies=no  just removes the After=sysinit.target. 

> Without it, the test may or may not work since systemd services are randomly
> starting during boot.

services aren't started randomly. They are started according to the declared dependencies. If there is no dependency between 2 units, they can be started in parallel. Since vmtoolsd.service declared Before=cloud-init-local.service, it will be started before cloud-init-local.service. It can be started in parallel with any other services. Setting DefaultDependancies=no will actually *increase* parallelism potentially since it is removing a dependancy which permits (but doesn't guarantee that) vmtoolsd.service be started even earlier.

Comment 5 Pengpeng Sun 2019-03-11 03:07:52 UTC
(In reply to Cathy Avery from comment #4)
Hi Cathy,

AFAIK, cloud-init-local.service starts very early and I just checked the unit of it. There are "DefaultDependencies=no", "Before=sysinit.target" and "Before=shutdown.target".

So if we remove "DefaultDependencies=no" from vmtoolsd.service, and with "Before=cloud-init-local.service", it might introduce cycle dependencies.

If there are no blocks for RHEL, still suggest keep "DefaultDependencies=no" to vmtoolsd.service.

Thanks,
Pengpeng

Comment 6 Daniel Berrangé 2019-03-11 09:56:14 UTC
(In reply to Pengpeng Sun from comment #5)
> (In reply to Cathy Avery from comment #4)
> Hi Cathy,
> 
> AFAIK, cloud-init-local.service starts very early and I just checked the
> unit of it. There are "DefaultDependencies=no", "Before=sysinit.target" and
> "Before=shutdown.target".
> 
> So if we remove "DefaultDependencies=no" from vmtoolsd.service, and with
> "Before=cloud-init-local.service", it might introduce cycle dependencies.

Yes, it cloud-init-local.service has DefaultDependancies=no, then vmtoolsd.service MUST have the same otherwise the dependencies are mutually incompatible.

Comment 7 Miroslav Rezanina 2019-03-13 08:01:35 UTC
Fix included in open-vm-tools-10.3.0-2.el7

Comment 9 ldu 2019-04-23 07:00:32 UTC
Verified this bug on RHEL7.7.
[root@bootp-73-199-103 ~]# uname -r
3.10.0-1034.el7.x86_64
[root@bootp-73-199-103 ~]# rpm -qa |grep open-
open-vm-tools-10.3.0-2.el7.x86_64

The Before=cloud-init-local.service had add to vmtoolsd.service file.

cat /lib/systemd/system/vmtoolsd.service
[Unit]
Description=Service for virtual machines hosted on VMware
Documentation=http://github.com/vmware/open-vm-tools
ConditionVirtualization=vmware
Requires=vgauthd.service
After=vgauthd.service
DefaultDependencies=no
Before=cloud-init-local.service

[Service]
ExecStart=/usr/bin/vmtoolsd
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
Also=vgauthd.service

Comment 11 errata-xmlrpc 2019-08-06 12:57:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2139