On Thu, Mar 3, 2016 at 9:06 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Mar 03, 2016 at 12:54:25AM +0000, David LeVene wrote:
Can you check our patches? They should resolve the problem we saw in the log: https://gerrit.ovirt.org/#/c/54237 (based on oVirt-3.6.3)
-- I've manually applied the patch to the node that I was testing on and the networking comes on-line correctly - now I'm encountering a gluster issue with cannot find master domain.
You are most welcome to share your logs (preferably on a different thread, to avoid confusion)
Without the fixes, as a workaround, I would suggest (if possible) to
disable IPv6 on your host boot line and check if all works out for you.
-- Ok, but as I can manually apply the patch its good now. Do you know what version are we hoping to have this put into as I won't perform an ovirt/vdsm update until its part of the upstream RPM's
The fix has been proposed to ovirt-3.6.4. I'll make sure it's accepted.
Do you need IPv6 connectivity? If so, you'll need to use a vdsm hook or
another interface that is not controlled by oVirt.
-- Ideally I'd prefer not to have it, but the way our network has been configured some hosts are IPv6 only, so at a min the guests need it.. the hypervisors not so much.
May I tap to what your IPv6 experience? (only if you feel confortable sharing this publically). What does these IPv6-only servers do? What does the guest do with them?
-- I've now hit an issue with it not starting up the master storage gluster domain - as it’s a separate issue I'll review the mailing lists & create a new item if its related.. I've attached the supervdsm.log incase you can save me some time and point me in the right direction!
All I see is this
MainProcess|jsonrpc.Executor/4::ERROR::2016-03-03 11:15:04,699::supervdsmServer::118::SuperVdsm.ServerCallback::(wrapper) Error in wrapper Traceback (most recent call last): File "/usr/share/vdsm/supervdsmServer", line 116, in wrapper res = func(*args, **kwargs) File "/usr/share/vdsm/supervdsmServer", line 531, in wrapper return func(*args, **kwargs) File "/usr/share/vdsm/gluster/cli.py", line 496, in volumeInfo xmltree = _execGlusterXml(command) File "/usr/share/vdsm/gluster/cli.py", line 108, in _execGlusterXml raise ge.GlusterCmdExecFailedException(rc, out, err) GlusterCmdExecFailedException: Command execution failed return code: 2
We have this logs before the exception: MainProcess|jsonrpc.Executor/3::DEBUG::2016-03-03 11:02:42,945::utils::669::root::(execCmd) /usr/bin/taskset --cpu-list 0-39 /usr/sbin/gluster --mode=script volume info --re mote-host=ovirtmount.test.lab data --xml (cwd None) The command looks correct MainProcess|jsonrpc.Executor/3::DEBUG::2016-03-03 11:02:43,024::utils::687::root::(execCmd) FAILED: <err> = '\n'; <rc> = 2 gluster command line failed in an unhelpful way. (Adding Sahina) David, can you try to run this command manually on this host? maybe there is some --verbose flag revealing more info? You may also try a simpler command: gluster volume info --remote-host=ovirtmount.test.lab data Another issue you should check - gluster version on the hosts and on the gluster nodes *must* match - otherwise you should expect failures accessing gluster server. We have this patch for handling such errors gracefully - can you test it? https://gerrit.ovirt.org/53785 (Adding Ala) Nir