[ovirt-users] all-in-one updated from 3.4.4 to 3.5.0 ok with reinstall of host part

[Sandro Bonazzola]

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 at 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 at 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