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> > 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 > http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users