On 05/15/2014 05:03 AM, Dan Kenigsberg wrote:
On Wed, May 14, 2014 at 08:06:00PM -0400, Bob Doolittle wrote:
Thanks John.
When hosted-engine aborts, it uninstalls everything.
So there is no webadmin available.
I've tried modifying the VDSM python code (e.g.
/usr/share/vdsm/storage/multipath.py and
/usr/lib64/python2.7/site-packages/vdsm/tool/service.py) to see/work around
what's going wrong, but oddly VDSM does not seem to be affected. I suspect
the original code (or bytecodes) are cached somewhere.
I do not think that this is the issue, but you can remove all trace of
*.pyc/*.pyo to make sure this is not the case.
In fact I see new pyc being produced, so that's myterious as well.
Restarting vdsmd
service has no effect. I'd really appreciate some insight there so I can
work around it.
What have you changed exactly? Where? If you add a plain syntax error to
the script, does it still run?
Very simple changes, to try to get a copy of the multipath.conf file
that was presumably causing the error (since the hosted-setup cleans up
when it aborts). I've attached them (full filenames ^^).
The file never appears.
I also attached a replacement I installed for multipath, which runs the
*real* multipath (moved to multipath.bak) and filters the output to
remove the known problematic warnings, and then exits with 0 status.
But the weirdest thing is that I instrumented systemctl (replaced it
with a script that logged its args and then executed the real one), and
systemctl is *never* being invoked to start multipathd. Here's what it
logged:
show-environment
show-environment
status vdsmd.service
show -p LoadState firewalld.service
show -p LoadState sshd.service
show -p LoadState firewalld.service
show -p Id firewalld.service
disable firewalld.service
stop firewalld.service
stop libvirtd.service
start libvirtd.service
status sshd.service
show -p Id vdsmd.service
enable vdsmd.service
stop vdsmd.service
start vdsmd.service
If I run "vdsm-tool service-reload multipathd" by hand then I see the
log I'd expect:
reload multipathd.service
Does oVirt 3.4.1 work more smoothly with F20? I chose F19 because it's more
stable at this point, thinking that things would be more likely to work
smoothly. It's not turning out that way... I'm willing to start over with
F20 if there's no path forward.
Vdsm works fine on 3.4.1, but I do not know about hosted-engine. Engine
itself is known not to work on F20.
What OS is hosted-engine known to work on?
-Bob
*** /usr/lib64/python2.7/site-packages/vdsm/tool/service.py.bak 2014-05-13 13:12:15.684256387 -0400
--- /usr/lib64/python2.7/site-packages/vdsm/tool/service.py 2014-05-13 13:53:05.940611767 -0400
***************
*** 347,352 ****
--- 347,354 ----
if rc == 0:
return 0
else:
+ import subprocess
+ subprocess.call(["cp", "/etc/multipath.conf", "/tmp/multipath.conf.bad"])
raise ServiceOperationError(
"%s failed" % alt.func_name, out, err)
raise ServiceNotExistError(
*** /usr/share/vdsm/storage/multipath.py.bak 2014-05-13 14:01:07.225891144 -0400
--- /usr/share/vdsm/storage/multipath.py 2014-05-13 14:01:50.279300691 -0400
***************
*** 169,174 ****
--- 169,178 ----
rc = misc.execCmd(cmd, sudo=True)[0]
if rc != 0:
raise se.MultipathSetupError()
+ cmd = [constants.EXT_CP, f.name, "/tmp/multipath.bad"]
+ rc = misc.execCmd(cmd, sudo=True)[0]
+ if rc != 0:
+ raise se.MultipathSetupError()
misc.persistFile(MPATH_CONF)
# Flush all unused multipath device maps
#!/bin/sh
/sbin/multipath.bak $@ | grep -v "invalid keyword: getuid_callout"
exit 0
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
