Hi Gianluca, I forgot to mention that you need to ensure that systemd knows that the new file exists. You should likely run `systemctl daemon-reload` after creating/modifying your custom systemd files. You can see that the After directive is combined from both files. Check it out by running `systemctl show vdsmd.service | grep After`
It makes sense to make further changes to ensure that NFS stops last, but I haven't looked into that yet. :-) Cheers, Gervais > On Oct 3, 2016, at 7:22 AM, Gianluca Cecchi <gianluca.cec...@gmail.com> wrote: > > > Il 28/Set/2016 21:09, "Gervais de Montbrun" <gerv...@demontbrun.com > <mailto:gerv...@demontbrun.com>> ha scritto: > > > > Hi Gianluca, > > > > Instead of editing the system's built in systemd configuration, you can do > > the following... > > > > Create a file called /etc/systemd/system/ovirt-ha-broker.service > > > >> # My custom ovirt-ha-broker.service config that ensures NFS starts before > >> ovirt-ha-broker.service > >> # thanks Gervais for this tip! :-) > >> > >> .include /usr/lib/systemd/system/ovirt-ha-broker.service > >> > >> [Unit] > >> After=nfs-server.service > > > > > > Then disable and enable ovirt-ha-broker.service (systemctl disable > > ovirt-ha-broker.service ; systemctl enable ovirt-ha-broker.service) and you > > should see that it is using your customized systemd unit definition. You > > can see that systemd is using your file by running systemctl status > > ovirt-ha-broker.service. You'll see something like "Loaded: loaded > > (/etc/systemd/system/ovirt-ha-broker.service;" in the output. > > > > Your file will survive updates and therefore always wait for nfs to start > > prior to starting. You can do the same for your other customizations. > > > > Cheers, > > Gervais > > > > > > > >> On Sep 28, 2016, at 1:31 PM, Gianluca Cecchi <gianluca.cec...@gmail.com > >> <mailto:gianluca.cec...@gmail.com>> wrote: > >> > >> On Sun, Sep 4, 2016 at 10:54 AM, Yedidyah Bar David <d...@redhat.com > >> <mailto:d...@redhat.com>> wrote: > >>> > >>> On Sat, Sep 3, 2016 at 1:18 PM, Gianluca Cecchi > >>> <gianluca.cec...@gmail.com <mailto:gianluca.cec...@gmail.com>> wrote: > >>> > Hello, > >>> > how do the two modes apply in case of single host? > >>> > During an upgrade phase, after having upgraded the self hosted engine > >>> > and > >>> > leaving global maintenance and having checked all is ok, what is the > >>> > correct > >>> > mode then to put host if I want finally to update it too? > >>> > >>> The docs say to put hosts to maintenance from the engine before upgrading > >>> them. > >>> > >>> This is (also) so that VMs on them are migrated away to other hosts. > >>> > >>> With a single host, you have no other hosts to migrate VMs to. > >>> > >>> So you should do something like this: > >>> > >>> 1. Set global maintenance (because you are going to take down the > >>> engine and its vm) > >>> 2. Shutdown all other VMs > >>> 3. Shutdown engine vm from itself > >>> At this point, you should be able to simply stop HA services. But it > >>> might be cleaner to first set local maintenance. Not sure but perhaps > >>> this might be required for vdsm. So: > >>> 4. Set local maintenance > >>> 5. Stop HA services. If setting local maintenance didn't work, perhaps > >>> better stop also vdsm services. This stop should obviously happen > >>> automatically by yum/rpm, but perhaps better do this manually to see > >>> that it worked. > >>> 6. yum (or dnf) update stuff. > >>> 7. Start HA services > >>> 8. Check status. I think you'll see that both local and global maint > >>> are still set. > >>> 9. Set maintenance to none > >>> 10. Check status again - I think that after some time HA will decide > >>> to start engine vm and should succeed. > >>> 11. Start all other VMs. > >>> > >>> Didn't try this myself. > >>> > >>> Best, > >>> -- > >>> Didi > >> > >> > >> Hello Didi, > >> I would like to leverage the update I have to do on 2 small different lab > >> environments to crosscheck the steps suggested. > >> They are both single host environments with self hosted engine. > >> One is 4.0.2 and the other is 4.0.3. Both on CentoS 7.2 > >> I plan to migrate to the just released 4.0.4 > >> > >> One note: in both environments the storage is NFS and is provided by the > >> host itself, so a corner case (for all hosted_storage domain, main data > >> domain and iso storage domain). > >> I customized the init scripts, basically for start phase of the server and > >> to keep in count of the NFS service, but probably something has to be done > >> for stop too? > >> > >> 1) In /usr/lib/systemd/system/ovirt-ha-broker.service > >> > >> added in section [Unit] > >> > >> After=nfs-server.service > >> > >> The file is overwritten at update so one has to keep in mind this > >> > >> 2) also in vdsmd.service changed > >> from: > >> After=multipathd.service libvirtd.service iscsid.service rpcbind.service \ > >> supervdsmd.service sanlock.service vdsm-network.service > >> > >> to: > >> After=multipathd.service libvirtd.service iscsid.service rpcbind.service \ > >> supervdsmd.service sanlock.service vdsm-network.service \ > >> nfs-server.service > >> > >> Do you think any order setup I have to put in place related to NFS service > >> and oVirt services stop? > >> > >> _______________________________________________ > >> Users mailing list > >> Users@ovirt.org <mailto:Users@ovirt.org> > >> http://lists.ovirt.org/mailman/listinfo/users > >> <http://lists.ovirt.org/mailman/listinfo/users> > > > > > > Nice! I'm going to try and see. > Any particular dependency I should add for shutdown order due to the fact > that my host is also the NFS server providing data stores? > Do I need to set up nfs stop only after a particular ovirt related service? > Thanks, > Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
