Re: [Users] host deploy and after reboot not responsive
On Tue, Jan 15, 2013 at 11:13:39AM +0100, Gianluca Cecchi wrote:
On Tue, Jan 15, 2013 at 9:20 AM, Alon Bar-Lev wrote:
> Can you just confirm that vdsm is up on host and attach
> /var/log/vdsm/vdsm.log?
right now I'm out of office, but I collected the vdsm.log and it is here:
https://docs.google.com/file/d/0BwoPbcrMv8mvQW9lTnhtN3VJRTA/edit
what t execute to see if the vdsm is up?
systemctl status vdsm.service ?
or anything similar?
Yes, and you can check its reponsiveness with vdsClient; tailing
/var/log/vdsm.log can give clues, too.
I see that something has asked vdsm to stop:
MainThread::INFO::2013-01-15 06:07:19,097::logUtils::41::dispatcher::(wrapper) Run and
protect: prepareForShutdown(options=None)
Do you have systemd's logs (/var/log/messages may have traces of vdsm's
stop/start).
What happens id you start vdsm now, does it crash again or happily running?
As you will see in the log, the server has access to some clustered volumes
that it skips... for example you see
storageRefresh::DEBUG::2013-01-15
06:07:15,735::misc::84::Storage.Misc.excCmd::(<lambda>) FAILED: <err> =
'
Skipping clustered volume group VG_VIRT04\n Skipping volume group
VG_VIRT04\n Skipping clustered volume group VG_VIRT02\n Skipping volume
group VG_VIRT02\n Skipping clustered volume group VG_VIRT03\n Skipping
volume group VG_VIRT03\n Skipping clustered volume group VG_VIRT03\n
Skipping volume group VG_VIRT03\n Skipping clustered volume group
VG_VIRT01\n Skipping volume group VG_VIRT01\n Skipping clustered volume
group VG_VIRT01\n Skipping volume group VG_VIRT01\n'; <rc> = 5
Does this prevent it from correctly starting and so I have to prevent
access to these luns or can I blacklist them in some way in LVM or instead
the reason is another one at all?
I believe it's something else. Vdsm can operate with non-accessible VG showing
up in vgs.