Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-02 Thread Richard Neuboeck
It turns out that there has been a problem in Intels EFI on
R1304GZ4GC server systems. As long as EFI optimizations were on
dmidecode did not work. Disabling EFI optimization is one option but
updating to the latest firmware did do the trick too in this case.

Cheers
Richard

On 09/01/2015 11:25 AM, Richard Neuboeck wrote:
> The dmidecode problem really only affects those three machines I'm
> trying to set up as ovirt hosts. Since I couldn't find anything
> wrong in the CentOS setup I tried Fedora 22 and got the same result.
> /dev/mem: Operation not permitted
> 
> I'm sorry to have bothered you guys with this problem that is
> obviously not ovirt related. I'll try to find a solution and keep
> you posted.
> 
> All the best
> Richard
> 
> On 09/01/2015 11:14 AM, Simone Tiraboschi wrote:
>> Adding Oved
>>
>> On Tue, Sep 1, 2015 at 10:47 AM, Richard Neuboeck
>> mailto:h...@tbi.univie.ac.at>> wrote:
>>
>> On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
>> > Indeed you had:
>> > Thread-64::DEBUG::2015-08-31
>> > 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
>> > /usr/sbin/dmidecode -s system-uuid (cwd None)
>> > Thread-64::DEBUG::2015-08-31
>> > 12:33:15,153::utils::679::root::(execCmd) FAILED:  = 
>> '/dev/mem:
>> > Operation not permitted\n';  = 1
>> > Thread-64::WARNING::2015-08-31
>> > 12:33:15,154::utils::812::root::(getHostUUID) Could not find host 
>> UUID.
>> > Thread-64::DEBUG::2015-08-31
>> >
>> > Can you please try executing?
>> > /usr/sbin/dmidecode -s system-uuid
>>
>> dmidecode always fails and according to the things I've read
>> this is
>> caused by the kernel restricting access to /dev/mem. But this
>> shouldn't affect the root user. It does anyway. I've tried with
>> selinux on and off. Is there a way around this problem? So far I
>> didn't find anything really helpful by googling around. This
>> problem
>> seems only to affect these kind of machines. CentOS 7.1
>> installations with the same kernel on another machine lets
>> me run
>> dmidecode without problems. I guess I'm missing something.
>>
>> [root@cube-one tmp]# dmidecode
>> # dmidecode 2.12
>> # SMBIOS entry point at 0xbafbaca0
>> /dev/mem: Operation not permitted
>>
>> [root@cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
>> /dev/mem: Operation not permitted
>>
>>  
>> dmidecode -s system-uuid is failing cause it cannot read /dev/mem so
>> VDSM fails getting the host UUID and so vdscli raise an exception
>> about a None value on 'uuid' when hosted-engine
>> calls getVdsCapabilities.
>> Any hint on that or any workaround?
>>
>> [root@cube-one tmp]# grep DEVMEM
>> /boot/config-3.10.0-229.11.1.el7.x86_64
>> CONFIG_STRICT_DEVMEM=y
>>
>> Cheers
>> Richard
>>
>> --
>> /dev/null
>>
>>
>>
> 
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


-- 
/dev/null



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Richard Neuboeck
The dmidecode problem really only affects those three machines I'm
trying to set up as ovirt hosts. Since I couldn't find anything
wrong in the CentOS setup I tried Fedora 22 and got the same result.
/dev/mem: Operation not permitted

I'm sorry to have bothered you guys with this problem that is
obviously not ovirt related. I'll try to find a solution and keep
you posted.

All the best
Richard

On 09/01/2015 11:14 AM, Simone Tiraboschi wrote:
> Adding Oved
> 
> On Tue, Sep 1, 2015 at 10:47 AM, Richard Neuboeck
> mailto:h...@tbi.univie.ac.at>> wrote:
> 
> On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
> > Indeed you had:
> > Thread-64::DEBUG::2015-08-31
> > 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
> > /usr/sbin/dmidecode -s system-uuid (cwd None)
> > Thread-64::DEBUG::2015-08-31
> > 12:33:15,153::utils::679::root::(execCmd) FAILED:  = '/dev/mem:
> > Operation not permitted\n';  = 1
> > Thread-64::WARNING::2015-08-31
> > 12:33:15,154::utils::812::root::(getHostUUID) Could not find host 
> UUID.
> > Thread-64::DEBUG::2015-08-31
> >
> > Can you please try executing?
> > /usr/sbin/dmidecode -s system-uuid
> 
> dmidecode always fails and according to the things I've read
> this is
> caused by the kernel restricting access to /dev/mem. But this
> shouldn't affect the root user. It does anyway. I've tried with
> selinux on and off. Is there a way around this problem? So far I
> didn't find anything really helpful by googling around. This
> problem
> seems only to affect these kind of machines. CentOS 7.1
> installations with the same kernel on another machine lets
> me run
> dmidecode without problems. I guess I'm missing something.
> 
> [root@cube-one tmp]# dmidecode
> # dmidecode 2.12
> # SMBIOS entry point at 0xbafbaca0
> /dev/mem: Operation not permitted
> 
> [root@cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
> /dev/mem: Operation not permitted
> 
>  
> dmidecode -s system-uuid is failing cause it cannot read /dev/mem so
> VDSM fails getting the host UUID and so vdscli raise an exception
> about a None value on 'uuid' when hosted-engine
> calls getVdsCapabilities.
> Any hint on that or any workaround?
> 
> [root@cube-one tmp]# grep DEVMEM
> /boot/config-3.10.0-229.11.1.el7.x86_64
> CONFIG_STRICT_DEVMEM=y
> 
> Cheers
> Richard
> 
> --
> /dev/null
> 
> 
> 


-- 
/dev/null



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Simone Tiraboschi
Adding Oved

On Tue, Sep 1, 2015 at 10:47 AM, Richard Neuboeck 
> wrote:
>
>> On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
>> > Indeed you had:
>> > Thread-64::DEBUG::2015-08-31
>> > 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
>> > /usr/sbin/dmidecode -s system-uuid (cwd None)
>> > Thread-64::DEBUG::2015-08-31
>> > 12:33:15,153::utils::679::root::(execCmd) FAILED:  = '/dev/mem:
>> > Operation not permitted\n';  = 1
>> > Thread-64::WARNING::2015-08-31
>> > 12:33:15,154::utils::812::root::(getHostUUID) Could not find host UUID.
>> > Thread-64::DEBUG::2015-08-31
>> >
>> > Can you please try executing?
>> > /usr/sbin/dmidecode -s system-uuid
>>
>> dmidecode always fails and according to the things I've read this is
>> caused by the kernel restricting access to /dev/mem. But this
>> shouldn't affect the root user. It does anyway. I've tried with
>> selinux on and off. Is there a way around this problem? So far I
>> didn't find anything really helpful by googling around. This problem
>> seems only to affect these kind of machines. CentOS 7.1
>> installations with the same kernel on another machine lets me run
>> dmidecode without problems. I guess I'm missing something.
>>
>> [root@cube-one tmp]# dmidecode
>> # dmidecode 2.12
>> # SMBIOS entry point at 0xbafbaca0
>> /dev/mem: Operation not permitted
>>
>> [root@cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
>> /dev/mem: Operation not permitted
>
>
dmidecode -s system-uuid is failing cause it cannot read /dev/mem so VDSM
fails getting the host UUID and so vdscli raise an exception about a None
value on 'uuid' when hosted-engine calls getVdsCapabilities.
Any hint on that or any workaround?

[root@cube-one tmp]# grep DEVMEM
>> /boot/config-3.10.0-229.11.1.el7.x86_64
>> CONFIG_STRICT_DEVMEM=y
>>
>> Cheers
>> Richard
>>
>> --
>> /dev/null
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Simone Tiraboschi
Adding Oved

On Tue, Sep 1, 2015 at 10:47 AM, Richard Neuboeck 
wrote:

> On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
> > Indeed you had:
> > Thread-64::DEBUG::2015-08-31
> > 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
> > /usr/sbin/dmidecode -s system-uuid (cwd None)
> > Thread-64::DEBUG::2015-08-31
> > 12:33:15,153::utils::679::root::(execCmd) FAILED:  = '/dev/mem:
> > Operation not permitted\n';  = 1
> > Thread-64::WARNING::2015-08-31
> > 12:33:15,154::utils::812::root::(getHostUUID) Could not find host UUID.
> > Thread-64::DEBUG::2015-08-31
> >
> > Can you please try executing?
> > /usr/sbin/dmidecode -s system-uuid
>
> dmidecode always fails and according to the things I've read this is
> caused by the kernel restricting access to /dev/mem. But this
> shouldn't affect the root user. It does anyway. I've tried with
> selinux on and off. Is there a way around this problem? So far I
> didn't find anything really helpful by googling around. This problem
> seems only to affect these kind of machines. CentOS 7.1
> installations with the same kernel on another machine lets me run
> dmidecode without problems. I guess I'm missing something.
>
> [root@cube-one tmp]# dmidecode
> # dmidecode 2.12
> # SMBIOS entry point at 0xbafbaca0
> /dev/mem: Operation not permitted
>
> [root@cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
> /dev/mem: Operation not permitted
>

dmidecode -s system-uuid is failing cause it cannot read /dev/mem so VDSM
fails getting the host UUID and so vdscli raise an exception about a None
value on 'uuid' when hosted-engine calls getVdsCapabilities.
Any hint on that or any workaround?


> [root@cube-one tmp]# grep DEVMEM
> /boot/config-3.10.0-229.11.1.el7.x86_64
> CONFIG_STRICT_DEVMEM=y
>
> Cheers
> Richard
>
> --
> /dev/null
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Richard Neuboeck
On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
> Indeed you had:
> Thread-64::DEBUG::2015-08-31
> 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
> /usr/sbin/dmidecode -s system-uuid (cwd None)
> Thread-64::DEBUG::2015-08-31
> 12:33:15,153::utils::679::root::(execCmd) FAILED:  = '/dev/mem:
> Operation not permitted\n';  = 1
> Thread-64::WARNING::2015-08-31
> 12:33:15,154::utils::812::root::(getHostUUID) Could not find host UUID.
> Thread-64::DEBUG::2015-08-31
> 
> Can you please try executing?
> /usr/sbin/dmidecode -s system-uuid

dmidecode always fails and according to the things I've read this is
caused by the kernel restricting access to /dev/mem. But this
shouldn't affect the root user. It does anyway. I've tried with
selinux on and off. Is there a way around this problem? So far I
didn't find anything really helpful by googling around. This problem
seems only to affect these kind of machines. CentOS 7.1
installations with the same kernel on another machine lets me run
dmidecode without problems. I guess I'm missing something.

[root@cube-one tmp]# dmidecode
# dmidecode 2.12
# SMBIOS entry point at 0xbafbaca0
/dev/mem: Operation not permitted

[root@cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
/dev/mem: Operation not permitted

[root@cube-one tmp]# grep DEVMEM
/boot/config-3.10.0-229.11.1.el7.x86_64
CONFIG_STRICT_DEVMEM=y

Cheers
Richard

-- 
/dev/null



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Simone Tiraboschi
On Tue, Sep 1, 2015 at 8:17 AM, Richard Neuboeck 
wrote:

> On 08/31/2015 05:24 PM, Simone Tiraboschi wrote:
> > The output of hosted-engine --deploy is as follows:
> >
> >
> > Could you please attach also its log?
>
> Sorry I didn't attach that immediately. The error shows clearly in
> the log. As do some others. Though I'm not sure what's missing that
> causes that python error.
>

vdscli raised when hosted-engine-setup called getVdsCapabilities()

2015-08-31 12:33:15 DEBUG otopi.context context._executeMethod:155
method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 145,
in _executeMethod
method['method']()
  File 
"/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/ovirt-hosted-engine-setup/system/packages.py",
line 89, in _late_setup
caps = cli.getVdsCapabilities()
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1297, in single_request
return self.parse_response(response)
  File "/usr/lib/python2.7/site-packages/vdsm/vdscli.py", line 43, in
wrapped_parse_response
return old_parse_response(*args, **kwargs)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1473, in parse_response
return u.close()
  File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
raise Fault(**self._stack[0])
Fault: :cannot marshal None
unless allow_none is enabled">
2015-08-31 12:33:15 ERROR otopi.context context._executeMethod:164
Failed to execute stage 'Environment setup': :cannot marshal None unless allow_none is
enabled">

The issue is probably here where VDSM try to respond with a None value for
the host UUID
'vmTypes': ['kvm'], 'selinux': {'mode': '1'}, 'liveSnapshot':
'true', 'kdumpStatus': 0, 'networks': {}, 'bridges': {}, 'uuid':
None, 'onlineCpus':
'0,1,2,3,4,5,6,7,8,9,20,21,22,23,24,25,26,27,28,29,10,11,12,13,14,15,16,17,18,19,30,31,32,33,34,35,36,37,38,39',

Indeed you had:
Thread-64::DEBUG::2015-08-31
12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
/usr/sbin/dmidecode -s system-uuid (cwd None)
Thread-64::DEBUG::2015-08-31
12:33:15,153::utils::679::root::(execCmd) FAILED:  = '/dev/mem:
Operation not permitted\n';  = 1
Thread-64::WARNING::2015-08-31
12:33:15,154::utils::812::root::(getHostUUID) Could not find host UUID.
Thread-64::DEBUG::2015-08-31

Can you please try executing?
/usr/sbin/dmidecode -s system-uuid




> Cheers
> Richard
>
> --
> /dev/null
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-09-01 Thread Sandro Bonazzola
Hi, can you please also share full sos report or at least the output of
dmidecode commad?

On Tue, Sep 1, 2015 at 8:17 AM, Richard Neuboeck 
wrote:

> On 08/31/2015 05:24 PM, Simone Tiraboschi wrote:
> > The output of hosted-engine --deploy is as follows:
> >
> >
> > Could you please attach also its log?
>
> Sorry I didn't attach that immediately. The error shows clearly in
> the log. As do some others. Though I'm not sure what's missing that
> causes that python error.
>
> Cheers
> Richard
>
> --
> /dev/null
>
> ___
> 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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-08-31 Thread Simone Tiraboschi
On Mon, Aug 31, 2015 at 1:02 PM, Richard Neuboeck 
wrote:

> Hi,
>
> I'm trying to test a self hosted engine oVirt 3.6 setup on a CentOS
> 7.1 minimal installation. But it fails quite early after running
> hosted-engine --deploy with
> [ ERROR ] Failed to execute stage 'Environment setup':  ":cannot marshal None unless allow_none
> is enabled">
>
> So far I've followed the repository installation instructions as
> mentioned on http://www.ovirt.org/OVirt_3.6_Release_Management, and
> added the current gluster repo to the default minimal CentOS 7.1 setup.
>
> The output of hosted-engine --deploy is as follows:
>

Could you please attach also its log?


> # hosted-engine --deploy
> [ INFO  ] Stage: Initializing
> [ INFO  ] Generating a temporary VNC password.
> [ INFO  ] Stage: Environment setup
>   Continuing will configure this host for serving as
> hypervisor and create a VM where you have to install oVirt Engine
> afterwards.
>   Are you sure you want to continue? (Yes, No)[Yes]:
>   Configuration files: []
>   Log file:
>
> /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20150831123258-w2syys.log
>   Version: otopi-1.4.0_master
> (otopi-1.4.0-0.0.master.20150727232243.git04fa8c9.el7)
>   It has been detected that this program is executed through
> an SSH connection without using screen.
>   Continuing with the installation may lead to broken
> installation if the network connection fails.
>   It is highly recommended to abort the installation and run
> it inside a screen session using command "screen".
>   Do you want to continue anyway? (Yes, No)[No]: yes
> [ INFO  ] Hardware supports virtualization
> [ INFO  ] Stage: Environment packages setup
> [ INFO  ] Stage: Programs detection
> [ INFO  ] Stage: Environment setup
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ INFO  ] Waiting for VDSM hardware info
> [ ERROR ] Failed to execute stage 'Environment setup':  ":cannot marshal None unless allow_none
> is enabled">
> [ INFO  ] Stage: Clean up
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-hosted-engine-setup/answers/answers-20150831123315.conf'
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
>
>
> The VDSM log shows that it fails to run dmidecode to gather hardware
> information. I've had the same issue with oVirt 3.5 but the access
> restriction to /dev/mem is kernel imposed so I'm not sure what to
> make of it since this kernel option is enabled on all the systems
> I've tested by default.
>
> There seem to be some gluster packages missing but I'm guessing
> that's not the problem at hand.
>
> I'm not sure what to search for in the logs so I'm kind of stuck as
> to what to try next. Any help is greatly appreciated.
>
> All the best
> Richard
>
>
> The rest of the VDSM log during the hosted-engine setup is as follows:
>
> BindingXMLRPC::INFO::2015-08-31
> 12:32:33,395::xmlrpc::73::vds.XMLRPCServer::(handle_request)
> Starting request handler for 127.0.0.1:47391
> Thread-51::INFO::2015-08-31
> 12:32:33,396::xmlrpc::84::vds.XMLRPCServer::(_process_requests)
> Request handler for 127.0.0.1:47391 started
> Thread-51::INFO::2015-08-31
> 12:32:33,399::xmlrpc::92::vds.XMLRPCServer::(_process_requests)
> Request handler for 127.0.0.1:47391 stopped
> Reactor thread::INFO::2015-08-31
>
> 12:32:48,416::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
> Accepting connection from 127.0.0.1:47392
> Reactor thread::DEBUG::2015-08-31
> 12:32:48,428::protocoldetector::82::ProtocolDetector.Detector::(__init__)
> Using required_size=11
> Reactor thread::INFO::2015-08-31
>
> 12:32:48,429::protocoldetector::118::ProtocolDetector.Detector::(handle_read)
> Detected protocol xml from 127.0.0.1:47392
> Reactor thread::DEBUG::2015-08-31
> 12:32:48,429::bindingxmlrpc::1296::XmlDetector::(handle_socket) xml
> over http detected from ('127.0.0.1', 47392)
> BindingXMLRPC::INFO::2015-08-31
> 12:32:48,429::xmlrpc::73::vds.XMLRPCServer::(handle_request)
> Starting request handler for 127.0.0.1:47392
> Thread-52::INFO::2015-08-31
> 12:32:48,430::xmlrpc::84::vds.XMLRPCServer::(_process_requests)
> Request handler for 127.0.0.1:47392 started
> Thread-52::INFO::2015-08-31
> 12:32:48,434::xmlrpc::92::vds.XMLRPCServer::(_process_requests)
> Request handler for 127.0.0.1:47392 stopped
> Reactor thread::INFO::2015-08-31
>
> 12:33:03,452::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
> Accepting connection from 127.0.0.1:47393
> Reactor thread::DEBUG::2015-08-31
> 12:33:03,464::protocoldetector::82::ProtocolDetector.Detector::(__init__)
> Using required_size=

[ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

2015-08-31 Thread Richard Neuboeck
Hi,

I'm trying to test a self hosted engine oVirt 3.6 setup on a CentOS
7.1 minimal installation. But it fails quite early after running
hosted-engine --deploy with
[ ERROR ] Failed to execute stage 'Environment setup': :cannot marshal None unless allow_none
is enabled">

So far I've followed the repository installation instructions as
mentioned on http://www.ovirt.org/OVirt_3.6_Release_Management, and
added the current gluster repo to the default minimal CentOS 7.1 setup.

The output of hosted-engine --deploy is as follows:

# hosted-engine --deploy
[ INFO  ] Stage: Initializing
[ INFO  ] Generating a temporary VNC password.
[ INFO  ] Stage: Environment setup
  Continuing will configure this host for serving as
hypervisor and create a VM where you have to install oVirt Engine
afterwards.
  Are you sure you want to continue? (Yes, No)[Yes]:
  Configuration files: []
  Log file:
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20150831123258-w2syys.log
  Version: otopi-1.4.0_master
(otopi-1.4.0-0.0.master.20150727232243.git04fa8c9.el7)
  It has been detected that this program is executed through
an SSH connection without using screen.
  Continuing with the installation may lead to broken
installation if the network connection fails.
  It is highly recommended to abort the installation and run
it inside a screen session using command "screen".
  Do you want to continue anyway? (Yes, No)[No]: yes
[ INFO  ] Hardware supports virtualization
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment setup
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Waiting for VDSM hardware info
[ ERROR ] Failed to execute stage 'Environment setup': :cannot marshal None unless allow_none
is enabled">
[ INFO  ] Stage: Clean up
[ INFO  ] Generating answer file
'/var/lib/ovirt-hosted-engine-setup/answers/answers-20150831123315.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination


The VDSM log shows that it fails to run dmidecode to gather hardware
information. I've had the same issue with oVirt 3.5 but the access
restriction to /dev/mem is kernel imposed so I'm not sure what to
make of it since this kernel option is enabled on all the systems
I've tested by default.

There seem to be some gluster packages missing but I'm guessing
that's not the problem at hand.

I'm not sure what to search for in the logs so I'm kind of stuck as
to what to try next. Any help is greatly appreciated.

All the best
Richard


The rest of the VDSM log during the hosted-engine setup is as follows:

BindingXMLRPC::INFO::2015-08-31
12:32:33,395::xmlrpc::73::vds.XMLRPCServer::(handle_request)
Starting request handler for 127.0.0.1:47391
Thread-51::INFO::2015-08-31
12:32:33,396::xmlrpc::84::vds.XMLRPCServer::(_process_requests)
Request handler for 127.0.0.1:47391 started
Thread-51::INFO::2015-08-31
12:32:33,399::xmlrpc::92::vds.XMLRPCServer::(_process_requests)
Request handler for 127.0.0.1:47391 stopped
Reactor thread::INFO::2015-08-31
12:32:48,416::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
Accepting connection from 127.0.0.1:47392
Reactor thread::DEBUG::2015-08-31
12:32:48,428::protocoldetector::82::ProtocolDetector.Detector::(__init__)
Using required_size=11
Reactor thread::INFO::2015-08-31
12:32:48,429::protocoldetector::118::ProtocolDetector.Detector::(handle_read)
Detected protocol xml from 127.0.0.1:47392
Reactor thread::DEBUG::2015-08-31
12:32:48,429::bindingxmlrpc::1296::XmlDetector::(handle_socket) xml
over http detected from ('127.0.0.1', 47392)
BindingXMLRPC::INFO::2015-08-31
12:32:48,429::xmlrpc::73::vds.XMLRPCServer::(handle_request)
Starting request handler for 127.0.0.1:47392
Thread-52::INFO::2015-08-31
12:32:48,430::xmlrpc::84::vds.XMLRPCServer::(_process_requests)
Request handler for 127.0.0.1:47392 started
Thread-52::INFO::2015-08-31
12:32:48,434::xmlrpc::92::vds.XMLRPCServer::(_process_requests)
Request handler for 127.0.0.1:47392 stopped
Reactor thread::INFO::2015-08-31
12:33:03,452::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
Accepting connection from 127.0.0.1:47393
Reactor thread::DEBUG::2015-08-31
12:33:03,464::protocoldetector::82::ProtocolDetector.Detector::(__init__)
Using required_size=11
Reactor thread::INFO::2015-08-31
12:33:03,465::protocoldetector::118::ProtocolDetector.Detector::(handle_read)
Detected protocol xml from 127.0.0.1:47393
Reactor thread::DEBUG::2015-08-31
12:33:03,465::bindingxmlrpc::1296::XmlDetector::(handle_socket) xml
over http detected from ('127.0.0.1', 47393)
BindingXMLRPC::INF