all-in-one updated from 3.4.4 to 3.5.0 ok with reinstall of host part
On a fedora 19 system where I had 3.4.4 all-in-one, I was able to upgrade to 3.5. vdsm part had problems I was able to solve reinstalling host from the webadmin gui Steps were: - follow instructions for engine part --> ok - verify connectivity of engine via new webadmin - put host into maintenance - stop vdsmd service - yum update vdsm part and all other packages related to ovirt When trying to start vdsm again I got [root@tekkaman vdsm]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: start-limit) since Sat 2014-10-25 16:01:29 CEST; 2min 54s ago Process: 14448 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=1/FAILURE) Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Unit vdsmd.service entered failed state. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: vdsmd.service holdoff time over, scheduling restart. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Stopping Virtual Desktop Server Manager... Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Starting Virtual Desktop Server Manager... Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: vdsmd.service start request repeated too quickly, refusing to start. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Unit vdsmd.service entered failed state. I was not able to check wich part of --pre-start functions had failed.. I see inside the script case "$1" in --pre-start) run_tasks " \ mkdirs \ configure_coredump \ configure_vdsm_logs \ run_init_hooks \ check_is_configured \ validate_configuration \ prepare_transient_repository \ syslog_available \ nwfilter \ dummybr \ load_needed_modules \ tune_system \ test_space \ test_lo \ unified_network_persistence_upgrade \ restore_nets \ upgrade_300_nets \ " ;; In logs I had only supervdsm.log MainThread::DEBUG::2014-10-25 16:34:34,021::supervdsmServer::451::SuperVdsm.Server::(main) Terminated normally MainThread::DEBUG::2014-10-25 16:35:21,836::netconfpersistence::134::root::(_getConfigs) Non-existing config set. MainThread::DEBUG::2014-10-25 16:35:21,836::netconfpersistence::134::root::(_getConfigs) Non-existing config set. MainThread::DEBUG::2014-10-25 16:35:21,898::supervdsmServer::411::SuperVdsm.Server::(main) Making sure I'm root - SuperVdsm MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::420::SuperVdsm.Server::(main) Parsing cmd args MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::423::SuperVdsm.Server::(main) Cleaning old socket /var/run/vdsm/svdsm.sock MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::427::SuperVdsm.Server::(main) Setting up keep alive thread MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::433::SuperVdsm.Server::(main) Creating remote object manager MainThread::DEBUG::2014-10-25 16:35:21,901::fileUtils::192::Storage.fileUtils::(chown) Changing owner for /var/run/vdsm/svdsm.sock, to (36:36) MainThread::DEBUG::2014-10-25 16:35:21,901::supervdsmServer::444::SuperVdsm.Server::(main) Started serving super vdsm object sourceRoute::DEBUG::2014-10-25 16:35:21,901::sourceroutethread::75::root::(_subscribeToInotifyLoop) sourceRouteThread.subscribeToInotifyLoop started in vdsm.conf I have retained net_persistence = ifcfg even after reboot only supervdsm.log was populated... Nevertheless a host reinstall from webadmin gui seemed to fix the problem and after that it was able to start vdsm ad host part. I was also able to upgrade DC/Cluster from 3.4 to 3.5 version. Now that I'm on 3.5 next days I'll try to pass from F19 to F20... we'll see Gianluca
Il 27/10/2014 09:13, Gianluca Cecchi ha scritto:
On a fedora 19 system where I had 3.4.4 all-in-one, I was able to upgrade to 3.5. vdsm part had problems I was able to solve reinstalling host from the webadmin gui Steps were:
- follow instructions for engine part --> ok - verify connectivity of engine via new webadmin - put host into maintenance - stop vdsmd service - yum update vdsm part and all other packages related to ovirt
When trying to start vdsm again I got
[root@tekkaman vdsm]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: start-limit) since Sat 2014-10-25 16:01:29 CEST; 2min 54s ago Process: 14448 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=1/FAILURE)
Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Unit vdsmd.service entered failed state. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: vdsmd.service holdoff time over, scheduling restart. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Stopping Virtual Desktop Server Manager... Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Starting Virtual Desktop Server Manager... Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: vdsmd.service start request repeated too quickly, refusing to start. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 25 16:01:29 tekkaman.localdomain.local systemd[1]: Unit vdsmd.service entered failed state.
I was not able to check wich part of --pre-start functions had failed.. I see inside the script case "$1" in --pre-start) run_tasks " \ mkdirs \ configure_coredump \ configure_vdsm_logs \ run_init_hooks \ check_is_configured \ validate_configuration \ prepare_transient_repository \ syslog_available \ nwfilter \ dummybr \ load_needed_modules \ tune_system \ test_space \ test_lo \ unified_network_persistence_upgrade \ restore_nets \ upgrade_300_nets \ " ;;
In logs I had only supervdsm.log
MainThread::DEBUG::2014-10-25 16:34:34,021::supervdsmServer::451::SuperVdsm.Server::(main) Terminated normally MainThread::DEBUG::2014-10-25 16:35:21,836::netconfpersistence::134::root::(_getConfigs) Non-existing config set. MainThread::DEBUG::2014-10-25 16:35:21,836::netconfpersistence::134::root::(_getConfigs) Non-existing config set. MainThread::DEBUG::2014-10-25 16:35:21,898::supervdsmServer::411::SuperVdsm.Server::(main) Making sure I'm root - SuperVdsm MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::420::SuperVdsm.Server::(main) Parsing cmd args MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::423::SuperVdsm.Server::(main) Cleaning old socket /var/run/vdsm/svdsm.sock MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::427::SuperVdsm.Server::(main) Setting up keep alive thread MainThread::DEBUG::2014-10-25 16:35:21,899::supervdsmServer::433::SuperVdsm.Server::(main) Creating remote object manager MainThread::DEBUG::2014-10-25 16:35:21,901::fileUtils::192::Storage.fileUtils::(chown) Changing owner for /var/run/vdsm/svdsm.sock, to (36:36) MainThread::DEBUG::2014-10-25 16:35:21,901::supervdsmServer::444::SuperVdsm.Server::(main) Started serving super vdsm object sourceRoute::DEBUG::2014-10-25 16:35:21,901::sourceroutethread::75::root::(_subscribeToInotifyLoop) sourceRouteThread.subscribeToInotifyLoop started
in vdsm.conf I have retained net_persistence = ifcfg
even after reboot only supervdsm.log was populated...
Nevertheless a host reinstall from webadmin gui seemed to fix the problem and after that it was able to start vdsm ad host part. I was also able to upgrade DC/Cluster from 3.4 to 3.5 version. Now that I'm on 3.5 next days I'll try to pass from F19 to F20... we'll see
Great! Keep us updated :-)
Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (2)
-
Gianluca Cecchi -
Sandro Bonazzola