----- Original Message -----
From: "Itamar Heim" iheim@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "Yaniv Bronheim" ybronhei@redhat.com, "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:39:35 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:38 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" iheim@redhat.com To: "Yaniv Bronheim" ybronhei@redhat.com Cc: "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@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@redhat.com To: "Yaniv Bronheim" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "arch" arch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
how will this affect the following use cases:
- 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.
- 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
this patch is just adjustment to whatever yaniv plans now.
up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above.
now host-deploy will be adjusted to call a single verb to configure whatever need to be configured by vdsm.
waiting for interface of vdsm-tool to stabilize before attempting to fix.
3.2, 3.1, 3.0 uses the old method of reconfigure, it does not use vdsm tool.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel