On 10/10/2013 05:38 PM, Yaniv Bronheim wrote:


----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Yaniv Bronheim" <ybron...@redhat.com>
Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "arch" 
<a...@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
a...@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)

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

Reply via email to