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.
Il 10/10/2013 15:32, Yaniv Bronheim ha scritto:
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
Hi, is this change targeted to oVirt 3.3.z? or is it targeted to 3.4.0? I think it will affect hosted-engine-setup and host-deploy for all-in-one setups at least.
Thanks, Yaniv Bronhaim. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
----- Original Message -----
From: "Sandro Bonazzola" sbonazzo@redhat.com To: "Yaniv Bronheim" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "arch" arch@ovirt.org, "Doron Fediuck" dfediuck@redhat.com, "Itamar Heim" iheim@redhat.com, "Yedidyah Bar David" didi@redhat.com, "Alon Bar-Lev" alonbl@redhat.com Sent: Thursday, October 10, 2013 4:38:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
Il 10/10/2013 15:32, Yaniv Bronheim ha scritto:
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
Hi, is this change targeted to oVirt 3.3.z? or is it targeted to 3.4.0? I think it will affect hosted-engine-setup and host-deploy for all-in-one setups at least.
I hope we took care about all points related to backwards compatibility and current host deploy process. Currently its targeted to 3.4.0
Thanks, Yaniv Bronhaim. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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:
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
Thanks, Itamar
----- 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
Thanks, Itamar
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)
----- 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.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
----- 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
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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.
so what happens if the vdsm on the host is an older 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
----- 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:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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: > > 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
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.
so what happens if the vdsm on the host is an older vdsm?
I don't follow... """
up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above.
"""
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
On 10/10/2013 07:47 PM, Alon Bar-Lev wrote:
----- 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:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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: >> >> 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
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.
so what happens if the vdsm on the host is an older vdsm?
I don't follow... """
up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above.
"""
yes. but the new host-deploy will not do the fallback iiuc?
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
----- 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 8:33:39 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:47 PM, Alon Bar-Lev wrote:
----- 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:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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: >>> >>> 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
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.
so what happens if the vdsm on the host is an older vdsm?
I don't follow... """
up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above.
"""
yes. but the new host-deploy will not do the fallback iiuc?
fallback is relevant only for the component which knows legacy and new methods which is the new host-deploy (1.1).
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 >
On Thu, Oct 10, 2013 at 01:51:00PM -0400, Alon Bar-Lev wrote:
----- 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 8:33:39 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:47 PM, Alon Bar-Lev wrote:
----- 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:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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: >>>> >>>> 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
I think we've quite neglected a third case, of unattended `yum upgrade -y`.
If and when we need to update BY_VDSM_VERS, this would result in a failure to restart vdsm. How should we handle that? I do not see a way other than adding libvirt-configure and libvirt condrestart to vdsm %postin.
Dan.
Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen).
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 10:34:10 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 01:51:00PM -0400, Alon Bar-Lev wrote:
----- 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 8:33:39 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:47 PM, Alon Bar-Lev wrote:
----- 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:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
----- 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: >>>>> >>>>> 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
I think we've quite neglected a third case, of unattended `yum upgrade -y`.
If and when we need to update BY_VDSM_VERS, this would result in a failure to restart vdsm. How should we handle that? I do not see a way other than adding libvirt-configure and libvirt condrestart to vdsm %postin.
Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote:
Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen).
IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`.
I'm trying to understand our action on the unattended upgrade path.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Antoni Segura Puimedon" asegurap@redhat.com Cc: "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 11:51:30 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote:
Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen).
IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`.
I'm trying to understand our action on the unattended upgrade path.
Interesting point. Thanks for raising that up, raising such issues was part of this mail goals You are right that after an upgrade we will need to restart libvirt service manually to start working with new configuration, But, AFAIK we don't force vdsmd restart after upgrading. If the user updated the package and still wants the new configuration, manual vdsmd restart will be required anyway. So the print to restart also related service is just enough.
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
On Sat, Oct 12, 2013 at 05:26:53PM -0400, Yaniv Bronheim wrote:
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Antoni Segura Puimedon" asegurap@redhat.com Cc: "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 11:51:30 PM Subject: Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote:
Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen).
IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`.
I'm trying to understand our action on the unattended upgrade path.
Interesting point. Thanks for raising that up, raising such issues was part of this mail goals You are right that after an upgrade we will need to restart libvirt service manually to start working with new configuration, But, AFAIK we don't force vdsmd restart after upgrading.
Actually, we have to restart (you cannot expect the old process to keep on running porperly after its data/code files have changed underneath) and we do, by virtue of /sbin/service vdsmd condrestart in the %post script.
If the user updated the package and still wants the new configuration, manual vdsmd restart will be required anyway. So the print to restart also related service is just enough.
I'm afraid we're ain't so lucky...
Dan.
vdsm-devel@lists.fedorahosted.org