[vdsm] Recent changes in vdsmd startup

Alon Bar-Lev alonbl at redhat.com
Thu Oct 10 16:38:19 UTC 2013



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Bronheim" <ybronhei at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Thursday, October 10, 2013 7:37:14 PM
> Subject: Re: [vdsm] Recent changes in vdsmd startup
> 
> On 10/10/2013 05:38 PM, Yaniv Bronheim wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Yaniv Bronheim" <ybronhei at redhat.com>
> >> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "arch"
> >> <arch at ovirt.org>
> >> Sent: Thursday, October 10, 2013 5:24:40 PM
> >> Subject: Re: Recent changes in vdsmd startup
> >>
> >> On 10/10/2013 04:32 PM, Yaniv Bronheim wrote:
> >>> Hey Everybody,
> >>> FYI, Recently we merged a fix that changes the way vdsmd starts. Before
> >>> that "service vdsmd start" command performed its main logic in addition
> >>> to
> >>> related services manipulation, as configure libvirt service and restart
> >>> it
> >>> for example.
> >>> Now we are trying to avoid that and only alert the user if restart or
> >>> other
> >>> operations on related services are required.
> >>>
> >>> So now when you perform vdsmd start after clear installation you will
> >>> see:
> >>> ~$ sudo service vdsmd restart
> >>> Shutting down vdsm daemon:
> >>> vdsm watchdog stop                                         [  OK  ]
> >>> vdsm: not running                                          [FAILED]
> >>> vdsm: Running run_final_hooks
> >>> vdsm stop                                                  [  OK  ]
> >>> supervdsm start                                            [  OK  ]
> >>> vdsm: Running run_init_hooks
> >>> vdsm: Running gencerts
> >>> hostname: Unknown host
> >>> vdsm: Running check_libvirt_configure
> >>> libvirt is not configured for vdsm yet
> >>> Perform 'vdsm-tool libvirt-configure' before starting vdsmd
> >>> vdsm: failed to execute check_libvirt_configure, error code 1
> >>> vdsm start                                                 [FAILED]
> >>>
> >>> This asks you to run "vdsm-tool libvirt-configure"
> >>> After running it you should see:
> >>>
> >>> ~$ sudo vdsm-tool libvirt-configure
> >>> Stopping libvirtd daemon: [  OK  ]
> >>> libvirt is not configured for vdsm yet
> >>> Reconfiguration of libvirt is done.
> >>>
> >>> To start working with the new configuration, execute:
> >>> 'vdsm-tool libvirt-configure-services-restart'
> >>> This will manage restarting of the following services:
> >>> libvirtd, supervdsmd
> >>>
> >>> After performing: 'vdsm-tool libvirt-configure-services-restart' you are
> >>> ready to start vdsmd again as usual.
> >>>
> >>> All those vdsm-tool commands require root privileges, otherwise it'll
> >>> alert
> >>> and stop the operation.
> >>> Over systemd the errors\output can be watched in /var/log/messages
> >>>
> >>> Thanks,
> >>> Yaniv Bronhaim.
> >>> _______________________________________________
> >>> Arch mailing list
> >>> Arch at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/arch
> >>>
> >>
> >> how will this affect the following use cases:
> >>
> >> 1. i added a new host to the system via the engine.
> >> at the end of the installation i expect the host to work without admin
> >> having to do any operation on the host.
> >>
> >> 2. i update a host to latest vdsm version via the engine.
> >> at the end of the update i expect the host to be updated without admin
> >> having to do any operation on the host
> >>
> >
> > Of course it shouldn't effect any of the deploy process. If using the
> > host-deploy, the host-deploy process should take care of stopping,
> > starting and other managing that can be required before starting vdsmd,
> > and it is taking care of.
> > The prints I copied above are relevant only if user tries to install and
> > start vdsmd manually
> 
> great. so how does backward compatibility work? i have a 3.2 engine, and
> i deploy latest vdsm due to some bug fixes.
> (i.e., i didn't get new host-deploy)

This was already supported in last iteration.

The init.d and systemd script support reconfigure verb that is executed ever since vdsm-bootstrap, these are kept for backward compatibility.

> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 



More information about the Arch mailing list