[vdsm] Recent changes in vdsmd startup
Itamar Heim
iheim at redhat.com
Thu Oct 10 16:39:35 UTC 2013
On 10/10/2013 07:38 PM, Alon Bar-Lev wrote:
>
>
> ----- 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.
so what happens to 3.2 engine with this new vdsm, without this patch?
http://gerrit.ovirt.org/20102
>
>>
>> _______________________________________________
>> 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