Re: [ovirt-users] Which hardware are you using for oVirt

[Richard Neuboeck]

Hi Andy,

we have 3 hosts for virtualization. Each 40 Cores, 512GB RAM, RAID 1 for
the system, 4 bonded (onboard) 1Gbit NICs for client access (to the VMs)
and a 10GBit NIC for the storage network.
The storage is built of 3 hosts, 10Gbit NIC, RAID 6 (5TB HDDs and SSDs
for caching) and gluster in replica 3 mode.

Cheers
Richard

On 25.03.18 09:36, Andy Michielsen wrote:
> Hello Alex,
> 
> Thanks for sharing. Much appriciated.
> 
> I believe my setup would need 96 Gb off RAM in each host, and would need
> about at least 3 Tb of storage. Probably 4 Tb would be beter if I want
> to work with snapshots. (Will be running mostly windows 2016 servers or
> windows 10 desktops with 6Gb off RAM and 100 Gb of disks)
> 
> I agree that a 10 Gb network for storage would be very beneficial.
> 
> Now If I can figure out how to set up a glusterfs on a 3 node cluster in
> oVirt 4.2 just for the data storage. I ‘m golden to get started. :-)
> 
> Kind regards.
> 
> On 24 Mar 2018, at 20:08, Alex K  > wrote:
> 
>> I have 2 or 3 node clusters with following hardware (all with
>> self-hosted engine) :
>>
>> 2 node cluster:
>> RAM: 64 GB per host
>> CPU: 8 cores per host
>> Storage: 4x 1TB SAS in RAID10
>> NIC: 2x Gbit
>> VMs: 20
>>
>> The above, although I would like to have had a third NIC for gluster
>> storage redundancy, it is running smoothly for quite some time and
>> without performance issues.
>> The VMs it is running are not high on IO (mostly small Linux servers).
>>
>> 3 node clusters:
>> RAM: 32 GB per host
>> CPU: 16 cores per host
>> Storage: 5x 600GB in RAID5 (not ideal but I had to gain some storage
>> space without purchasing extra disks)
>> NIC: 6x Gbit
>> VMs: less then 10 large Windows VMs (Windows 2016 server and Windows 10)
>>
>> For your setup (30 VMs) I would rather go with RAID10 SAS disks and at
>> least a dual 10Gbit NIC dedicated to the gluster traffic only.
>>
>> Alex
>>
>>
>> On Sat, Mar 24, 2018 at 1:24 PM, Andy Michielsen
>> mailto:andy.michiel...@gmail.com>> wrote:
>>
>> Hello Andrei,
>>
>> Thank you very much for sharing info on your hardware setup. Very
>> informative.
>>
>> At this moment I have my ovirt engine on our vmware environment
>> which is fine for good backup and restore.
>>
>> I have 4 nodes running now all different in make and model with
>> local storage and it works but lacks performance a bit.
>>
>> But I can get my hands on some old dell’s R415 with 96 Gb of ram
>> and 2 quadcores and 6 x 1 Gb nic’s. They all come with 2 x 146 Gb
>> 15000 rpm’s harddisks. This isn’t bad but I will add more RAM for
>> starters. Also I would like to have some good redundant storage
>> for this too and the servers have limited space to add that.
>>
>> Hopefully others will also share there setups and expirience like
>> you did.
>>
>> Kind regards.
>>
>> On 24 Mar 2018, at 10:35, Andrei Verovski > > wrote:
>>
>>> Hi,
>>>
>>> HL ProLiant DL380, dual Xeon
>>> 120 GB RAID L1 for system
>>> 2 TB RAID L10 for VM disks
>>> 5 VMs, 3 Linux, 2 Windows
>>> Total CPU load most of the time is  low, high level of activity
>>> related to disk.
>>> Host engine under KVM appliance on SuSE, can be easily moved,
>>> backed up, copied, experimented with, etc.
>>>
>>> You'll have to use servers with more RAM and storage than main.
>>> More then one NIC required if some of your VMs are on different
>>> subnets, e.g. 1 in internal zone and 2nd on DMZ.
>>> For your setup 10 GB NICs + L3 Switch for ovirtmgmt.
>>>
>>> BTW, I would suggest to have several separate hardware RAIDs
>>> unless you have SSD, otherwise limit of the disk system I/O will
>>> be a bottleneck. Consider SSD L1 RAID for heavy-loaded databases.
>>>
>>> *Please note many cheap SSDs do NOT work reliably with SAS
>>> controllers even in SATA mode*.
>>>
>>> For example, I supposed to use 2 x WD Green SSD configures as
>>> RAID L1 for OS.
>>> It was possible to install system, yet under heavy load simulated
>>> with iozone disk system freeze, rendering OS unbootable.
>>> Same crash was experienced with 512GB KingFast SSD connected to
>>> broadcom/AMCC SAS RAID Card.
>>>
>>>
>>> On 03/24/2018 10:33 AM, Andy Michielsen wrote:
 Hi all,

 Not sure if this is the place to be asking this but I was wondering 
 which hardware you all are using and why in order for me to see what I 
 would be needing.

 I would like to set up a HA cluster consisting off 3 hosts to be able 
 to run 30 vm’s.
 The engine, I can run on an other server. The hosts can be fitted with 
 the storage and share the space through glusterfs. I would think I will be 
 needing at least 3 nic’s but would be able to install ovn. (Are 1gb nic’s 
 sufficient ?)

 Any input you guys would like to share wo

Re: [ovirt-users] Unable to add permissions for LDAP users

[Richard Neuboeck]

On 03/10/2017 09:46 AM, Ondra Machacek wrote:

> So what's your provider 389ds or FreeIPA?
> 
> Note that both use differrent unique ID. IPA is using 'ipaUniqueID',
> and 389ds is using 'nsuniqueid'. DId you tried both?

Thanks for pointing that out! It works perfectly if I use IPA.
I didn't know they have different identifiers (though it might have
been obvious to me since there is a separate IPA option...). I clung
to the thought that FreeIPA uses 389ds internally.

Thanks a lot!
Richard

> 
> I can successfully run a search and also login
> from the setup script.
> 
> After running the setup I rebootet the Engine VM to make sure
> everything is restarted.
> 
> In the web UI configuration for 'System Permissions' I'm able to
> find users from LDAP but when I try to 'Add' a selected user the UI
> shows me this error: 'User admin@internal-authz failed to grant
> permission for Role SuperUser on System to User/Group .'.
> 
> In then engine.log the following lines are generated:
> 2017-03-09 14:02:49,308+01 INFO
> [org.ovirt.engine.core.bll.AddSystemPermissionCommand]
> (org.ovirt.thread.pool-6-thread-4)
> [1ebae5e0-e5f6-49ba-ac80-95266c582893] Running command:
> AddSystemPermissionCommand internal: false. Entities affected :  ID:
> aaa0----123456789aaa Type: SystemAction group
> MANIPULATE_PERMISSIONS with role type USER,  ID:
> aaa0----123456789aaa Type: SystemAction group
> ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER
> 2017-03-09 14:02:49,319+01 ERROR
> [org.ovirt.engine.core.bll.AddSystemPermissionCommand]
> (org.ovirt.thread.pool-6-thread-4)
> [1ebae5e0-e5f6-49ba-ac80-95266c582893] Transaction rolled-back for
> command 'org.ovirt.engine.core.bll.AddSystemPermissionCommand'.
> 2017-03-09 14:02:49,328+01 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (org.ovirt.thread.pool-6-thread-4)
> [1ebae5e0-e5f6-49ba-ac80-95266c582893] EVENT_ID:
> USER_ADD_SYSTEM_PERMISSION_FAILED(867), Correlation ID:
> 1ebae5e0-e5f6-49ba-ac80-95266c582893, Call Stack: null, Custom Event
> ID: -1, Message: User admin@internal-authz failed to grant
> permission for Role SuperUser on System to User/Group .
> 
> 
> So far I've re-run the ldap-setup routine. I made sure all newly
> generated files in /etc/ovirt-engine/[aaa|extensions.d] are owned by
> ovirt:ovirt (instead of root) and have 0600 as permission (instead
> of 0644). That didn't change anything.
> 
> I've also found an older bug report but for oVirt 3.5
> https://bugzilla.redhat.com/show_bug.cgi?id=1121954
> 
> That didn't reveal any new either.
> 
> Any ideas what I could try next?
> 
> Thanks!
> Cheers
> Richard
> 
> 
> 
> 
> On 10/06/2016 04:36 PM, Ondra Machacek wrote:
> > On 10/06/2016 01:47 PM, Michael Burch wrote:
> >> I'm using the latest ovirt on CentOS7 with the aaa-ldap
> extension.
> >> I can
> >> successfully authenticate as an LDAP user. I can also login as
> >> admin@internal and search for, find, and select LDAP users but I
> >> cannot
> >> add permissions for them. Each time I get the error "User
> >> admin@internal-authz failed to grant permission for Role
> UserRole on
> >> System to User/Group ."
> >
> > This error usually means bad unique attribute used.
> >
> >>
> >>
> >> I have no control over the LDAP server, which uses custom
> >> objectClasses
> >> and uses groupOfNames instead of PosixGroups. I assume I need
> to set
> >> sequence variables to accommodate our group configuration but I'm
> >> at a
> >> loss as to where to begin. the The config I have is as follows:
> >>
> >>
> >> include = 
> >>
> >> vars.server = labauth.lan.lab.org 
> >>
> >> pool.authz.auth.type = none
> >> pool.default.serverset.type = single
> >> pool.default.serverset.single.server = ${global:vars.server}
> >> pool.default.ssl.startTLS = true
> >> pool.default.ssl.insecure = true
> >>
> >> pool.default.connection-options.connectTimeoutMillis = 1
> >> pool.default.connection-options.responseTimeoutMillis = 9
> >> sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars
> >> sequence.my-basedn-init-vars.010.description = set baseDN
> >> sequence.my-basedn-init-vars.010.type = var-set
> >> sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN
> >> sequence.my-basedn-init-vars.010.var-set.value = o=LANLAB
> >>
> >> sequence-init.init.101-my-objectclass-init-vars =
> >> my-objectclass-init-vars
> >> sequence.my-objectclass-init-vars.020.description = set
> objectClass
> >> sequence.my-objectclass-init-vars.020.type = var-set
> >> se

Re: [ovirt-users] Unable to add permissions for LDAP users

[Richard Neuboeck]

Hi,

I seem to experience the same problem right now and am at a bit of a
loss as to where to dig for some more troubleshooting information. I
would highly appreciate some help.

Here is what I have and what I did:

ovirt-engine-4.1.0.4-1.el7.centos.noarch
ovirt-engine-extension-aaa-ldap-1.3.0-1.el7.noarch

I executed ovirt-engine-extension-aaa-ldap-setup. My LDAP provider
is 389ds (FreeIPA). I can successfully run a search and also login
from the setup script.

After running the setup I rebootet the Engine VM to make sure
everything is restarted.

In the web UI configuration for 'System Permissions' I'm able to
find users from LDAP but when I try to 'Add' a selected user the UI
shows me this error: 'User admin@internal-authz failed to grant
permission for Role SuperUser on System to User/Group .'.

In then engine.log the following lines are generated:
2017-03-09 14:02:49,308+01 INFO
[org.ovirt.engine.core.bll.AddSystemPermissionCommand]
(org.ovirt.thread.pool-6-thread-4)
[1ebae5e0-e5f6-49ba-ac80-95266c582893] Running command:
AddSystemPermissionCommand internal: false. Entities affected :  ID:
aaa0----123456789aaa Type: SystemAction group
MANIPULATE_PERMISSIONS with role type USER,  ID:
aaa0----123456789aaa Type: SystemAction group
ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER
2017-03-09 14:02:49,319+01 ERROR
[org.ovirt.engine.core.bll.AddSystemPermissionCommand]
(org.ovirt.thread.pool-6-thread-4)
[1ebae5e0-e5f6-49ba-ac80-95266c582893] Transaction rolled-back for
command 'org.ovirt.engine.core.bll.AddSystemPermissionCommand'.
2017-03-09 14:02:49,328+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(org.ovirt.thread.pool-6-thread-4)
[1ebae5e0-e5f6-49ba-ac80-95266c582893] EVENT_ID:
USER_ADD_SYSTEM_PERMISSION_FAILED(867), Correlation ID:
1ebae5e0-e5f6-49ba-ac80-95266c582893, Call Stack: null, Custom Event
ID: -1, Message: User admin@internal-authz failed to grant
permission for Role SuperUser on System to User/Group .


So far I've re-run the ldap-setup routine. I made sure all newly
generated files in /etc/ovirt-engine/[aaa|extensions.d] are owned by
ovirt:ovirt (instead of root) and have 0600 as permission (instead
of 0644). That didn't change anything.

I've also found an older bug report but for oVirt 3.5
https://bugzilla.redhat.com/show_bug.cgi?id=1121954
That didn't reveal any new either.

Any ideas what I could try next?

Thanks!
Cheers
Richard




On 10/06/2016 04:36 PM, Ondra Machacek wrote:
> On 10/06/2016 01:47 PM, Michael Burch wrote:
>> I'm using the latest ovirt on CentOS7 with the aaa-ldap extension.
>> I can
>> successfully authenticate as an LDAP user. I can also login as
>> admin@internal and search for, find, and select LDAP users but I
>> cannot
>> add permissions for them. Each time I get the error "User
>> admin@internal-authz failed to grant permission for Role UserRole on
>> System to User/Group ."
> 
> This error usually means bad unique attribute used.
> 
>>
>>
>> I have no control over the LDAP server, which uses custom
>> objectClasses
>> and uses groupOfNames instead of PosixGroups. I assume I need to set
>> sequence variables to accommodate our group configuration but I'm
>> at a
>> loss as to where to begin. the The config I have is as follows:
>>
>>
>> include = 
>>
>> vars.server = labauth.lan.lab.org
>>
>> pool.authz.auth.type = none
>> pool.default.serverset.type = single
>> pool.default.serverset.single.server = ${global:vars.server}
>> pool.default.ssl.startTLS = true
>> pool.default.ssl.insecure = true
>>
>> pool.default.connection-options.connectTimeoutMillis = 1
>> pool.default.connection-options.responseTimeoutMillis = 9
>> sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars
>> sequence.my-basedn-init-vars.010.description = set baseDN
>> sequence.my-basedn-init-vars.010.type = var-set
>> sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN
>> sequence.my-basedn-init-vars.010.var-set.value = o=LANLAB
>>
>> sequence-init.init.101-my-objectclass-init-vars =
>> my-objectclass-init-vars
>> sequence.my-objectclass-init-vars.020.description = set objectClass
>> sequence.my-objectclass-init-vars.020.type = var-set
>> sequence.my-objectclass-init-vars.020.var-set.variable =
>> simple_filterUserObject
>> sequence.my-objectclass-init-vars.020.var-set.value =
>> (objectClass=labPerson)(uid=*)
>>
>> search.default.search-request.derefPolicy = NEVER
>>
>> sequence-init.init.900-local-init-vars = local-init-vars
>> sequence.local-init-vars.010.description = override name space
>> sequence.local-init-vars.010.type = var-set
>> sequence.local-init-vars.010.var-set.variable =
>> simple_namespaceDefault
>> sequence.local-init-vars.010.var-set.value = *
> 
> What's this^ for? I think it's unusable.
> 
>>
>> sequence.local-init-vars.020.description = apply filter to users
>> sequence.local-init-vars.020.type = var-set
>> sequence.local-init-vars.020.var-set.variable =
>> simple_filte

Re: [ovirt-users] Hosted Engine package installation Error

[Richard Neuboeck]

Hi,

it seems that in the latest version(s) of glusterfs the pub.key file
is not present even though some yum repo configurations still try to
access it.

Last time I had this problem I updated the repo configuration
(/etc/yum.repos.d/ovirt-3.6-dependencies.repo) to use the other key
(rsa.pub).


The other question is: Is it safe to assume that the LATEST release
of glusterfs in combination with a fixed release of oVirt is always
a good idea?

Cheers
Richard


On 04/21/2016 10:01 AM, Budur Nagaraju wrote:
> Hi
> 
> Getting the below error while installing the hosted engine
> packages,installing oVirt3.5.
> 
> 
> 
> Total size: 76 M
> Installed size: 281 M
> Downloading Packages:
> warning: rpmts_HdrFromFdno: Header V4 RSA/SHA256 Signature, key ID
> d5dc52dc: NOKEY
> Retrieving key from
> https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key
> 
> 
> GPG key retrieval failed: [Errno 14] PYCURL ERROR 22 - "The
> requested URL returned error: 404 Not Found"
> 
> 
> Thanks,
> Nagaraju
> 
> 
> 
> ___
> 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

[ovirt-users] Fwd: Re: HA agent fails to start

[Richard Neuboeck]

On 04/14/2016 11:03 PM, Simone Tiraboschi wrote:
> On Thu, Apr 14, 2016 at 10:38 PM, Simone Tiraboschi  
> wrote:
>> On Thu, Apr 14, 2016 at 6:53 PM, Richard Neuboeck  
>> wrote:
>>> On 14.04.16 18:46, Simone Tiraboschi wrote:
>>>> On Thu, Apr 14, 2016 at 4:04 PM, Richard Neuboeck  
>>>> wrote:
>>>>> On 04/14/2016 02:14 PM, Simone Tiraboschi wrote:
>>>>>> On Thu, Apr 14, 2016 at 12:51 PM, Richard Neuboeck
>>>>>>  wrote:
>>>>>>> On 04/13/2016 10:00 AM, Simone Tiraboschi wrote:
>>>>>>>> On Wed, Apr 13, 2016 at 9:38 AM, Richard Neuboeck 
>>>>>>>>  wrote:
>>>>>>>>> The answers file shows the setup time of both machines.
>>>>>>>>>
>>>>>>>>> On both machines hosted-engine.conf got rotated right before I wrote
>>>>>>>>> this mail. Is it possible that I managed to interrupt the rotation 
>>>>>>>>> with
>>>>>>>>> the reboot so the backup was accurate but the update not yet written 
>>>>>>>>> to
>>>>>>>>> hosted-engine.conf?
>>>>>>>>
>>>>>>>> AFAIK we don't have any rotation mechanism for that file; something
>>>>>>>> else you have in place on that host?
>>>>>>>
>>>>>>> Those machines are all CentOS 7.2 minimal installs. The only
>>>>>>> adaptation I do is installing vim, removing postfix and installing
>>>>>>> exim, removing firewalld and installing iptables-service. Then I add
>>>>>>> the oVirt repos (3.6 and 3.6-snapshot) and deploy the host.
>>>>>>>
>>>>>>> But checking lsof shows that 'ovirt-ha-agent --no-daemon' has access
>>>>>>> to the config file (and the one ending with ~):
>>>>>>>
>>>>>>> # lsof | grep 'hosted-engine.conf~'
>>>>>>> ovirt-ha- 193446   vdsm  351u  REG
>>>>>>> 253,01021135070683
>>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf~
>>>>>>
>>>>>> This is not that much relevant if the file was renamed after
>>>>>> ovirt-ha-agent opened it.
>>>>>> Try this:
>>>>>>
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]# tail -n1 -f
>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf &
>>>>>> [1] 28866
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]# port=
>>>>>>
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]# lsof | grep 
>>>>>> hosted-engine.conf
>>>>>> tail  28866  root3r  REG
>>>>>> 253,0  10141595898 /etc/ovirt-hosted-engine/hosted-engine.conf
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]# mv
>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf
>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf_123
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]# lsof | grep 
>>>>>> hosted-engine.conf
>>>>>> tail  28866  root3r  REG
>>>>>> 253,0  10141595898
>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf_123
>>>>>> [root@c72he20160405h1 ovirt-hosted-engine-setup]#
>>>>>>
>>>>>
>>>>> I've issued the commands you suggested but I don't know how that
>>>>> helps to find the process accessing the config files.
>>>>>
>>>>> After moving the hosted-engine.conf file the HA agent crashed
>>>>> logging the information that the config file is not available.
>>>>>
>>>>> Here is the output from every command:
>>>>>
>>>>> # tail -n1 -f /etc/ovirt-hosted-engine/hosted-engine.conf &
>>>>> [1] 167865
>>>>> [root@cube-two ~]# port=
>>>>> # lsof | grep hosted-engine.conf
>>>>> ovirt-ha- 166609   vdsm5u  REG
>>>>> 253,01021134433491
>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
>>>>> ovirt-ha- 166609   vdsm7u  REG
>>>>> 253,010211344

Re: [ovirt-users] HA agent fails to start

[Richard Neuboeck]

On 04/14/2016 02:14 PM, Simone Tiraboschi wrote:
> On Thu, Apr 14, 2016 at 12:51 PM, Richard Neuboeck
>  wrote:
>> On 04/13/2016 10:00 AM, Simone Tiraboschi wrote:
>>> On Wed, Apr 13, 2016 at 9:38 AM, Richard Neuboeck  
>>> wrote:
>>>> The answers file shows the setup time of both machines.
>>>>
>>>> On both machines hosted-engine.conf got rotated right before I wrote
>>>> this mail. Is it possible that I managed to interrupt the rotation with
>>>> the reboot so the backup was accurate but the update not yet written to
>>>> hosted-engine.conf?
>>>
>>> AFAIK we don't have any rotation mechanism for that file; something
>>> else you have in place on that host?
>>
>> Those machines are all CentOS 7.2 minimal installs. The only
>> adaptation I do is installing vim, removing postfix and installing
>> exim, removing firewalld and installing iptables-service. Then I add
>> the oVirt repos (3.6 and 3.6-snapshot) and deploy the host.
>>
>> But checking lsof shows that 'ovirt-ha-agent --no-daemon' has access
>> to the config file (and the one ending with ~):
>>
>> # lsof | grep 'hosted-engine.conf~'
>> ovirt-ha- 193446   vdsm  351u  REG
>> 253,01021135070683
>> /etc/ovirt-hosted-engine/hosted-engine.conf~
> 
> This is not that much relevant if the file was renamed after
> ovirt-ha-agent opened it.
> Try this:
> 
> [root@c72he20160405h1 ovirt-hosted-engine-setup]# tail -n1 -f
> /etc/ovirt-hosted-engine/hosted-engine.conf &
> [1] 28866
> [root@c72he20160405h1 ovirt-hosted-engine-setup]# port=
> 
> [root@c72he20160405h1 ovirt-hosted-engine-setup]# lsof | grep 
> hosted-engine.conf
> tail  28866  root3r  REG
> 253,0  10141595898 /etc/ovirt-hosted-engine/hosted-engine.conf
> [root@c72he20160405h1 ovirt-hosted-engine-setup]# mv
> /etc/ovirt-hosted-engine/hosted-engine.conf
> /etc/ovirt-hosted-engine/hosted-engine.conf_123
> [root@c72he20160405h1 ovirt-hosted-engine-setup]# lsof | grep 
> hosted-engine.conf
> tail  28866  root3r  REG
> 253,0  10141595898
> /etc/ovirt-hosted-engine/hosted-engine.conf_123
> [root@c72he20160405h1 ovirt-hosted-engine-setup]#
> 

I've issued the commands you suggested but I don't know how that
helps to find the process accessing the config files.

After moving the hosted-engine.conf file the HA agent crashed
logging the information that the config file is not available.

Here is the output from every command:

# tail -n1 -f /etc/ovirt-hosted-engine/hosted-engine.conf &
[1] 167865
[root@cube-two ~]# port=
# lsof | grep hosted-engine.conf
ovirt-ha- 166609   vdsm5u  REG
253,01021134433491
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm7u  REG
253,01021134433453
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm8u  REG
253,01021134433489
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm9u  REG
253,01021134433493
/etc/ovirt-hosted-engine/hosted-engine.conf~
ovirt-ha- 166609   vdsm   10u  REG
253,01021134433495
/etc/ovirt-hosted-engine/hosted-engine.conf
tail  167865   root3r  REG
253,01021134433493
/etc/ovirt-hosted-engine/hosted-engine.conf~
# mv /etc/ovirt-hosted-engine/hosted-engine.conf
/etc/ovirt-hosted-engine/hosted-engine.conf_123
# lsof | grep hosted-engine.conf
ovirt-ha- 166609   vdsm5u  REG
253,01021134433491
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm7u  REG
253,01021134433453
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm8u  REG
253,01021134433489
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm9u  REG
253,01021134433493
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm   10u  REG
253,01021134433495
/etc/ovirt-hosted-engine/hosted-engine.conf (deleted)
ovirt-ha- 166609   vdsm   12u  REG
253,01021134433498
/etc/ovirt-hosted-engine/hosted-engine.conf~
ovirt-ha- 166609   vdsm   13u  REG
253,01021134433499
/etc/ovirt-hosted-engine/hosted-engine.conf_123
tail  167865   root3r  REG

Re: [ovirt-users] HA agent fails to start

[Richard Neuboeck]

On 04/13/2016 10:00 AM, Simone Tiraboschi wrote:
> On Wed, Apr 13, 2016 at 9:38 AM, Richard Neuboeck  
> wrote:
>> The answers file shows the setup time of both machines.
>>
>> On both machines hosted-engine.conf got rotated right before I wrote
>> this mail. Is it possible that I managed to interrupt the rotation with
>> the reboot so the backup was accurate but the update not yet written to
>> hosted-engine.conf?
> 
> AFAIK we don't have any rotation mechanism for that file; something
> else you have in place on that host?

Those machines are all CentOS 7.2 minimal installs. The only
adaptation I do is installing vim, removing postfix and installing
exim, removing firewalld and installing iptables-service. Then I add
the oVirt repos (3.6 and 3.6-snapshot) and deploy the host.

But checking lsof shows that 'ovirt-ha-agent --no-daemon' has access
to the config file (and the one ending with ~):

# lsof | grep 'hosted-engine.conf~'
ovirt-ha- 193446   vdsm  351u  REG
253,01021135070683
/etc/ovirt-hosted-engine/hosted-engine.conf~


>> [root@cube-two ~]# ls -l /etc/ovirt-hosted-engine
>> total 16
>> -rw-r--r--. 1 root root 3252 Apr  8 10:35 answers.conf
>> -rw-r--r--. 1 root root 1021 Apr 13 09:31 hosted-engine.conf
>> -rw-r--r--. 1 root root 1021 Apr 13 09:30 hosted-engine.conf~
>>
>> [root@cube-three ~]# ls -l /etc/ovirt-hosted-engine
>> total 16
>> -rw-r--r--. 1 root root 3233 Apr 11 08:02 answers.conf
>> -rw-r--r--. 1 root root 1002 Apr 13 09:31 hosted-engine.conf
>> -rw-r--r--. 1 root root 1002 Apr 13 09:31 hosted-engine.conf~
>>
>> On 12.04.16 16:01, Simone Tiraboschi wrote:
>>> Everything seams fine here,
>>> /etc/ovirt-hosted-engine/hosted-engine.conf seams to be correctly
>>> created with the right name.
>>> Can you please check the latest modification time of your
>>> /etc/ovirt-hosted-engine/hosted-engine.conf~ and compare it with the
>>> setup time?
>>>
>>> On Tue, Apr 12, 2016 at 2:34 PM, Richard Neuboeck  
>>> wrote:
>>>> On 04/12/2016 11:32 AM, Simone Tiraboschi wrote:
>>>>> On Mon, Apr 11, 2016 at 8:11 AM, Richard Neuboeck  
>>>>> wrote:
>>>>>> Hi oVirt Group,
>>>>>>
>>>>>> in my attempts to get all aspects of oVirt 3.6 up and running I
>>>>>> stumbled upon something I'm not sure how to fix:
>>>>>>
>>>>>> Initially I installed a hosted engine setup. After that I added
>>>>>> another HA host (with hosted-engine --deploy). The host was
>>>>>> registered in the Engine correctly and HA agent came up as expected.
>>>>>>
>>>>>> However if I reboot the second host (through the Engine UI or
>>>>>> manually) HA agent fails to start. The reason seems to be that
>>>>>> /etc/ovirt-hosted-engine/hosted-engine.conf is empty. The backup
>>>>>> file ending with ~ exists though.
>>>>>
>>>>> Can you please attach hosted-engine-setup logs from your additional hosts?
>>>>> AFAIK our code will never take a ~ ending backup of that file.
>>>>
>>>> ovirt-hosted-engine-setup logs from both additional hosts are
>>>> attached to this mail.
>>>>
>>>>>
>>>>>> Here are the log messages from the journal:
>>>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at systemd[1]: Starting oVirt
>>>>>> Hosted Engine High Availability Monitoring Agent...
>>>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>>>> INFO:ovirt_hosted_engine_ha.agent.agent.Agent:ovirt-hosted-engine-ha
>>>>>> agent 1.3.5.3-0.0.master started
>>>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>>>> INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Found
>>>>>> certificate common name: cube-two.tbi.univie.ac.at
>>>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>>>> ovirt-ha-agent
>>>>>> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Hosted
>>>>>> Engine is not configured. Shutting down.
>>>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>>>> ERROR:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Hosted
>>>>>> Engine is not configured. Shutting down.
>>>>>> Apr 11 07:29:39 cube-two.tbi

Re: [ovirt-users] HA agent fails to start

[Richard Neuboeck]

The answers file shows the setup time of both machines.

On both machines hosted-engine.conf got rotated right before I wrote
this mail. Is it possible that I managed to interrupt the rotation with
the reboot so the backup was accurate but the update not yet written to
hosted-engine.conf?

[root@cube-two ~]# ls -l /etc/ovirt-hosted-engine
total 16
-rw-r--r--. 1 root root 3252 Apr  8 10:35 answers.conf
-rw-r--r--. 1 root root 1021 Apr 13 09:31 hosted-engine.conf
-rw-r--r--. 1 root root 1021 Apr 13 09:30 hosted-engine.conf~

[root@cube-three ~]# ls -l /etc/ovirt-hosted-engine
total 16
-rw-r--r--. 1 root root 3233 Apr 11 08:02 answers.conf
-rw-r--r--. 1 root root 1002 Apr 13 09:31 hosted-engine.conf
-rw-r--r--. 1 root root 1002 Apr 13 09:31 hosted-engine.conf~

On 12.04.16 16:01, Simone Tiraboschi wrote:
> Everything seams fine here,
> /etc/ovirt-hosted-engine/hosted-engine.conf seams to be correctly
> created with the right name.
> Can you please check the latest modification time of your
> /etc/ovirt-hosted-engine/hosted-engine.conf~ and compare it with the
> setup time?
> 
> On Tue, Apr 12, 2016 at 2:34 PM, Richard Neuboeck  
> wrote:
>> On 04/12/2016 11:32 AM, Simone Tiraboschi wrote:
>>> On Mon, Apr 11, 2016 at 8:11 AM, Richard Neuboeck  
>>> wrote:
>>>> Hi oVirt Group,
>>>>
>>>> in my attempts to get all aspects of oVirt 3.6 up and running I
>>>> stumbled upon something I'm not sure how to fix:
>>>>
>>>> Initially I installed a hosted engine setup. After that I added
>>>> another HA host (with hosted-engine --deploy). The host was
>>>> registered in the Engine correctly and HA agent came up as expected.
>>>>
>>>> However if I reboot the second host (through the Engine UI or
>>>> manually) HA agent fails to start. The reason seems to be that
>>>> /etc/ovirt-hosted-engine/hosted-engine.conf is empty. The backup
>>>> file ending with ~ exists though.
>>>
>>> Can you please attach hosted-engine-setup logs from your additional hosts?
>>> AFAIK our code will never take a ~ ending backup of that file.
>>
>> ovirt-hosted-engine-setup logs from both additional hosts are
>> attached to this mail.
>>
>>>
>>>> Here are the log messages from the journal:
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at systemd[1]: Starting oVirt
>>>> Hosted Engine High Availability Monitoring Agent...
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>> INFO:ovirt_hosted_engine_ha.agent.agent.Agent:ovirt-hosted-engine-ha
>>>> agent 1.3.5.3-0.0.master started
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>> INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Found
>>>> certificate common name: cube-two.tbi.univie.ac.at
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>> ovirt-ha-agent
>>>> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Hosted
>>>> Engine is not configured. Shutting down.
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>> ERROR:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Hosted
>>>> Engine is not configured. Shutting down.
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
>>>> INFO:ovirt_hosted_engine_ha.agent.agent.Agent:Agent shutting down
>>>> Apr 11 07:29:39 cube-two.tbi.univie.ac.at systemd[1]:
>>>> ovirt-ha-agent.service: main process exited, code=exited, status=255/n/a
>>>>
>>>> If I restore the configuration from the backup file and manually
>>>> restart the HA agent it's working properly.
>>>>
>>>> For testing purposes I added a third HA host which turn out to
>>>> behave exactly the same.
>>>>
>>>> Any help would be appreciated!
>>>> Thanks
>>>> 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] Hosted engine on gluster problem

[Richard Neuboeck]

On 04/11/2016 11:11 AM, Sandro Bonazzola wrote:
> On Mon, Apr 11, 2016 at 9:37 AM, Richard Neuboeck
> mailto:h...@tbi.univie.ac.at>> wrote:
> 
> Hi Darryl,
> 
> I'm still experimenting with my oVirt installation so I tried to
> recreate the problems you've described.
> 
> My setup has three HA hosts for virtualization and three machines
> for the gluster replica 3 setup.
> 
> I manually migrated the Engine from the initial install host (one)
> to host three. Then shut down host one manually and interrupted the
> fencing mechanisms so the host stayed down. This didn't bother the
> Engine VM at all.
> 
> 
> Did you move the host one to maintenance before shutting down?
> Or is this a crash recovery test?

I did not put the machine in maintenance mode. Just issued
'poweroff' on the command line. Same for host one as host three.

> 
> To make things a bit more challenging I then shut down host three
> while running the Engine VM. Of course the Engine was down for some
> time until host two detected the problem. It started the Engine VM
> and everything seems to be running quite well without the initial
> install host.
> 
> 
> Thanks for the feedback!
> 
>  
> 
> 
> My only problem is that the HA agent on host two and three refuse to
> start after a reboot due to the fact that the configuration of the
> hosted engine is missing. I wrote another mail to
> users@ovirt.org <mailto:users@ovirt.org>
> about that.
> 
> 
> This is weird. Martin,  Simone can you please investigate on this?
> 
> 
>  
> 
> 
> Cheers
> Richard
> 
> On 04/08/2016 01:38 AM, Bond, Darryl wrote:
> > There seems to be a pretty severe bug with using hosted engine
> on gluster.
> >
> > If the host that was used as the initial hosted-engine
> --deploy host goes away, the engine VM wil crash and cannot be
> restarted until the host comes back.
> 
> 
> is this an Hyperconverged setup?
> 
>  
> 
> >
> > This is regardless of which host the engine was currently running.
> >
> >
> > The issue seems to be buried in the bowels of VDSM and is not
> an issue with gluster itself.
> 
> 
> Sahina, can you please investigate on this?
> 
>  
> 
> >
> > The gluster filesystem is still accessable from the host that
> was running the engine. The issue has been submitted to bugzilla
> but the fix is some way off (4.1).
> >
> >
> > Can my hosted engine be converted to use NFS (using the
> gluster NFS server on the same filesystem) without rebuilding my
> hosted engine (ie change domainType=glusterfs to domainType=nfs)?
> 
>  
> 
> >
> > What effect would that have on the hosted-engine storage
> domain inside oVirt, ie would the same filesystem be mounted
> twice or would it just break.
> >
> >
> > Will this actually fix the problem, does it have the same
> issue when the hosted engine is on NFS?
> >
> >
> > Darryl
> >
> >
> >
> >
> > 
> >
> > The contents of this electronic message and any attachments
> are intended only for the addressee and may contain legally
> privileged, personal, sensitive or confidential information. If
> you are not the intended addressee, and have received this
> email, any transmission, distribution, downloading, printing or
> photocopying of the contents of this message or attachments is
> strictly prohibited. Any legal privilege or confidentiality
> attached to this message and attachments is not waived, lost or
> destroyed by reason of delivery to any person other than
> intended addressee. If you have received this message and are
> not the intended addressee you should notify the sender by
> return email and destroy all copies of the message and any
> attachments. Unless expressly attributed, the views expressed in
> this email do not necessarily represent the views of the company.
> > ___
> > Users mailing list
> > Users@ovirt.org <mailto:Users@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> 
> 
> --
> /dev/null
> 
> 
> ___
> Users mailing list
> Users@ovirt.org <mailto: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 <http://redhat.com>


-- 
/dev/null



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

Re: [ovirt-users] Hosted engine on gluster problem

[Richard Neuboeck]

Hi Darryl,

I'm still experimenting with my oVirt installation so I tried to
recreate the problems you've described.

My setup has three HA hosts for virtualization and three machines
for the gluster replica 3 setup.

I manually migrated the Engine from the initial install host (one)
to host three. Then shut down host one manually and interrupted the
fencing mechanisms so the host stayed down. This didn't bother the
Engine VM at all.

To make things a bit more challenging I then shut down host three
while running the Engine VM. Of course the Engine was down for some
time until host two detected the problem. It started the Engine VM
and everything seems to be running quite well without the initial
install host.

My only problem is that the HA agent on host two and three refuse to
start after a reboot due to the fact that the configuration of the
hosted engine is missing. I wrote another mail to users@ovirt.org
about that.

Cheers
Richard

On 04/08/2016 01:38 AM, Bond, Darryl wrote:
> There seems to be a pretty severe bug with using hosted engine on gluster.
> 
> If the host that was used as the initial hosted-engine --deploy host goes 
> away, the engine VM wil crash and cannot be restarted until the host comes 
> back.
> 
> This is regardless of which host the engine was currently running.
> 
> 
> The issue seems to be buried in the bowels of VDSM and is not an issue with 
> gluster itself.
> 
> The gluster filesystem is still accessable from the host that was running the 
> engine. The issue has been submitted to bugzilla but the fix is some way off 
> (4.1).
> 
> 
> Can my hosted engine be converted to use NFS (using the gluster NFS server on 
> the same filesystem) without rebuilding my hosted engine (ie change 
> domainType=glusterfs to domainType=nfs)?
> 
> What effect would that have on the hosted-engine storage domain inside oVirt, 
> ie would the same filesystem be mounted twice or would it just break.
> 
> 
> Will this actually fix the problem, does it have the same issue when the 
> hosted engine is on NFS?
> 
> 
> Darryl
> 
> 
> 
> 
> 
> 
> The contents of this electronic message and any attachments are intended only 
> for the addressee and may contain legally privileged, personal, sensitive or 
> confidential information. If you are not the intended addressee, and have 
> received this email, any transmission, distribution, downloading, printing or 
> photocopying of the contents of this message or attachments is strictly 
> prohibited. Any legal privilege or confidentiality attached to this message 
> and attachments is not waived, lost or destroyed by reason of delivery to any 
> person other than intended addressee. If you have received this message and 
> are not the intended addressee you should notify the sender by return email 
> and destroy all copies of the message and any attachments. Unless expressly 
> attributed, the views expressed in this email do not necessarily represent 
> the views of the company.
> ___
> 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

[ovirt-users] HA agent fails to start

[Richard Neuboeck]

Hi oVirt Group,

in my attempts to get all aspects of oVirt 3.6 up and running I
stumbled upon something I'm not sure how to fix:

Initially I installed a hosted engine setup. After that I added
another HA host (with hosted-engine --deploy). The host was
registered in the Engine correctly and HA agent came up as expected.

However if I reboot the second host (through the Engine UI or
manually) HA agent fails to start. The reason seems to be that
/etc/ovirt-hosted-engine/hosted-engine.conf is empty. The backup
file ending with ~ exists though.

Here are the log messages from the journal:
Apr 11 07:29:39 cube-two.tbi.univie.ac.at systemd[1]: Starting oVirt
Hosted Engine High Availability Monitoring Agent...
Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
INFO:ovirt_hosted_engine_ha.agent.agent.Agent:ovirt-hosted-engine-ha
agent 1.3.5.3-0.0.master started
Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Found
certificate common name: cube-two.tbi.univie.ac.at
Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
ovirt-ha-agent
ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Hosted
Engine is not configured. Shutting down.
Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
ERROR:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Hosted
Engine is not configured. Shutting down.
Apr 11 07:29:39 cube-two.tbi.univie.ac.at ovirt-ha-agent[3747]:
INFO:ovirt_hosted_engine_ha.agent.agent.Agent:Agent shutting down
Apr 11 07:29:39 cube-two.tbi.univie.ac.at systemd[1]:
ovirt-ha-agent.service: main process exited, code=exited, status=255/n/a

If I restore the configuration from the backup file and manually
restart the HA agent it's working properly.

For testing purposes I added a third HA host which turn out to
behave exactly the same.

Any help would be appreciated!
Thanks
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] Can not access storage domain hosted_storage

[Richard Neuboeck]

Thanks Darryl!

For others having the same problem and needing more information on
how to temporarily fix this:

On the Engine VM you find the information to access the DB in
/etc/ovirt-engine/engine.conf.d/10-setup-database.conf

Then access the engine database and update the vfs_type field in the
storage_server_connections table of the engine storage volume entry:

psql -U engine -W -h localhost
select * from storage_server_connections;
update storage_server_connections set vfs_type = 'glusterfs' where
id = 'THE_ID_YOU_FOUND_IN_THE_OUTPUT_ABOVE_FOR_THE_ENGINE_VOLUME';

After that adding new hosts works as expected.

Cheers
Richard


On 04/08/2016 12:43 AM, Bond, Darryl wrote:
> The workaround for this bug is here 
> https://bugzilla.redhat.com/show_bug.cgi?id=1317699
> 
> 
> 
> From: users-boun...@ovirt.org  on behalf of Simone 
> Tiraboschi 
> Sent: Friday, 8 April 2016 1:30 AM
> To: Richard Neuboeck; Roy Golan
> Cc: users
> Subject: Re: [ovirt-users] Can not access storage domain hosted_storage
> 
> On Thu, Apr 7, 2016 at 4:17 PM, Richard Neuboeck  
> wrote:
>> Hi oVirt Users/Developers,
>>
>> I'm having trouble adding another host to a working hosted engine
>> setup. Through the WebUI I try to add another host. The package
>> installation and configuration processes seemingly run without
>> problems. When the second host tries to mount the engine storage
>> volume it halts with the WebUI showing the following message:
>>
>> 'Failed to connect Host cube-two to the Storage Domain hosted_engine'
>>
>> The mount fails which results in the host status as 'non operational'.
>>
>> Checking the vdsm.log on the newly added host shows that the mount
>> attempt of the engine volume doesn't use -t glusterfs. On the other
>> hand the VM storage volume (also a glusterfs volume) is mounted the
>> right way.
>>
>> It seems the Engine configuration that is given to the second host
>> lacks the vfs_type property. So without glusterfs as fs given the
>> system assumes an NFS mount and obviously fails.
> 
> It seams that the auto-import procedure in the engine didn't recognize
> that the hosted-engine storage domain was on gluster and took it for
> NFS.
> 
> Adding Roy here to take a look.
> 
> 
>> Here are the relevant log lines showing the JSON reply to the
>> configuration request, the working mount of the VM storage (called
>> plexus) and the failing mount of the engine storage.
>>
>> ...
>> jsonrpc.Executor/4::INFO::2016-04-07
>> 15:45:53,043::logUtils::48::dispatcher::(wrapper) Run and protect:
>> connectStorageServer(domType=7,
>> spUUID=u'0001-0001-0001-0001-03ce', conList=[{u'id':
>> u'981cd3aa-052b-498a-914e-5e8f314357a8', u'connection':
>> u'borg-sphere-one:/plexus', u'iqn': u'', u'user': u'', u'tpgt':
>> u'1', u'vfs_type': u'glusterfs', u'password': '', u'port':
>> u''}, {u'id': u'cceaa988-9607-4bef-8854-0e7a585720aa',
>> u'connection': u'borg-sphere-one:/engine', u'iqn': u'', u'user':
>> u'', u'tpgt': u'1', u'password': '', u'port': u''}],
>> options=None)
>> ...
>> jsonrpc.Executor/4::DEBUG::2016-04-07
>> 15:45:53,062::mount::229::Storage.Misc.excCmd::(_runcmd)
>> /usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n
>> /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount
>> -t glusterfs -o
>> backup-volfile-servers=borg-sphere-two:borg-sphere-three
>> borg-sphere-one:/plexus
>> /rhev/data-center/mnt/glusterSD/borg-sphere-one:_plexus (cwd None)
>> ...
>> jsonrpc.Executor/4::DEBUG::2016-04-07
>> 15:45:53,380::mount::229::Storage.Misc.excCmd::(_runcmd)
>> /usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n
>> /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount
>> -o backup-volfile-servers=borg-sphere-two:borg-sphere-three
>> borg-sphere-one:/engine
>> /rhev/data-center/mnt/glusterSD/borg-sphere-one:_engine (cwd None)
>> ...
>>
>> The problem seems to have been introduced since March 22nd. On this
>> install I have added two additional hosts without problem. Three
>> days ago I tried to reinstall the whole system for testing and
>> documentation purposes but now am not able to add other hosts.
>>
>> All the installs follow the same docum

[ovirt-users] Can not access storage domain hosted_storage

[Richard Neuboeck]

Hi oVirt Users/Developers,

I'm having trouble adding another host to a working hosted engine
setup. Through the WebUI I try to add another host. The package
installation and configuration processes seemingly run without
problems. When the second host tries to mount the engine storage
volume it halts with the WebUI showing the following message:

'Failed to connect Host cube-two to the Storage Domain hosted_engine'

The mount fails which results in the host status as 'non operational'.

Checking the vdsm.log on the newly added host shows that the mount
attempt of the engine volume doesn't use -t glusterfs. On the other
hand the VM storage volume (also a glusterfs volume) is mounted the
right way.

It seems the Engine configuration that is given to the second host
lacks the vfs_type property. So without glusterfs as fs given the
system assumes an NFS mount and obviously fails.

Here are the relevant log lines showing the JSON reply to the
configuration request, the working mount of the VM storage (called
plexus) and the failing mount of the engine storage.

...
jsonrpc.Executor/4::INFO::2016-04-07
15:45:53,043::logUtils::48::dispatcher::(wrapper) Run and protect:
connectStorageServer(domType=7,
spUUID=u'0001-0001-0001-0001-03ce', conList=[{u'id':
u'981cd3aa-052b-498a-914e-5e8f314357a8', u'connection':
u'borg-sphere-one:/plexus', u'iqn': u'', u'user': u'', u'tpgt':
u'1', u'vfs_type': u'glusterfs', u'password': '', u'port':
u''}, {u'id': u'cceaa988-9607-4bef-8854-0e7a585720aa',
u'connection': u'borg-sphere-one:/engine', u'iqn': u'', u'user':
u'', u'tpgt': u'1', u'password': '', u'port': u''}],
options=None)
...
jsonrpc.Executor/4::DEBUG::2016-04-07
15:45:53,062::mount::229::Storage.Misc.excCmd::(_runcmd)
/usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n
/usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount
-t glusterfs -o
backup-volfile-servers=borg-sphere-two:borg-sphere-three
borg-sphere-one:/plexus
/rhev/data-center/mnt/glusterSD/borg-sphere-one:_plexus (cwd None)
...
jsonrpc.Executor/4::DEBUG::2016-04-07
15:45:53,380::mount::229::Storage.Misc.excCmd::(_runcmd)
/usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n
/usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount
-o backup-volfile-servers=borg-sphere-two:borg-sphere-three
borg-sphere-one:/engine
/rhev/data-center/mnt/glusterSD/borg-sphere-one:_engine (cwd None)
...

The problem seems to have been introduced since March 22nd. On this
install I have added two additional hosts without problem. Three
days ago I tried to reinstall the whole system for testing and
documentation purposes but now am not able to add other hosts.

All the installs follow the same documented procedure. I've verified
several times that the problem exists with the components in the
current 3.6 release repo as well as in the 3.6 snapshot repo.

If I check the storage configuration of hosted_engine domain in the
WebUI it shows glusterfs as VFS type.

The initial mount during the hosted engine setup on the first host
shows the correct parameters (vfs_type) in vdsm.log:

Thread-42::INFO::2016-04-07
14:56:29,464::logUtils::48::dispatcher::(wrapper) Run and protect:
connectStorageServer(domType=7,
spUUID='----', conList=[{'id':
'b13ae31f-d66a-43a7-8aba-eaf4e62a6fb0', 'tpgt': '1', 'vfs_type':
'glusterfs', 'connection': 'borg-sphere-one:/engine', 'user':
'kvm'}], options=None)
Thread-42::DEBUG::2016-04-07
14:56:29,591::fileUtils::143::Storage.fileUtils::(createdir)
Creating directory:
/rhev/data-center/mnt/glusterSD/borg-sphere-one:_engine mode: None
Thread-42::DEBUG::2016-04-07
14:56:29,592::storageServer::364::Storage.StorageServer.MountConnection::(_get_backup_servers_option)
Using bricks: ['borg-sphere-one', 'borg-sphere-two',
'borg-sphere-three']
Thread-42::DEBUG::2016-04-07
14:56:29,592::mount::229::Storage.Misc.excCmd::(_runcmd)
/usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n
/usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount
-t glusterfs -o
backup-volfile-servers=borg-sphere-two:borg-sphere-three
borg-sphere-one:/engine
/rhev/data-center/mnt/glusterSD/borg-sphere-one:_engine (cwd None)


I've already created a bug report but since I didn't know where to
put it filed it as VDSM bug which it doesn't seem to be.
https://bugzilla.redhat.com/show_bug.cgi?id=1324075


I would really like to help resolve this problem. If there is
anything I can test, please let me know. I appreciate any help in
this matter.

Currently I'm running an oVirt 3.6 snapshot installation on CentOS
7.2. The two storage volumes are both replica 3 on separate gluster
storage nodes.

Thanks in advance!
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 and gluster volumes

[Richard Neuboeck]

Thanks for the answers!

On 11/16/2015 05:48 PM, Simone Tiraboschi wrote:
> It should be automatically imported but we have a know open bug on that:
> https://bugzilla.redhat.com/1269768

Is there anything I can help with?
Resetting and reinstalling isn't a problem. So I would gladly test
packages or anything else if necessary.

> 
> If I have a separate VM volume I guess I need to create a 'New
> Domain'. If I do that the over lay window in the UI that allows me
> to enter the glusterfs connection details clears. I see an animated
> circle in the middle but nothing happens. There is no entry in the
> engine log or the in any host log. If I wait long enough the UI
> terminates the session and I'm at the login again.
> 
> 
> This one seams a new issue.
> Can you please attach VDSM from your host?

This was my fault I guess. I did create two separate storage volumes
but thought I could manage them under the same 'storage domain
name'. So I gave the same domain name to the newly added vm storage
as I did during the deployment of the engine. It seems that adding a
new domain that has the same name as an existing doesn't fail with
an obvious error. But this is probably related to the failed auto
import of the engine storage domain.

Giving the engine storage domain a different name than the vm
storage domain makes adding an additional gluster storage volume
possible without problems.

Cheers
Richard

-- 
/dev/null



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

[ovirt-users] oVirt 3.6 and gluster volumes

[Richard Neuboeck]

Hi,

I'm having some trouble installing oVirt 3.6 hosted engine with gluster.

First of here are the questions that arose:
Do I need separate gluster volumes for the hosted engine and the
other VMs?
If yes I'm guessing the same optimizations apply to the /engine
volume as to the other volume as described in
http://www.ovirt.org/Features/Self_Hosted_Engine_Gluster_Support

Post installation the storage tab is completely empty though I did
create an NFS ISO domain during the hosted-engine --deploy process.
Is that normal behavior?

Should the engine gluster volume be manually imported ('Import
Domain') or is this volume never visible?

If I have a separate VM volume I guess I need to create a 'New
Domain'. If I do that the over lay window in the UI that allows me
to enter the glusterfs connection details clears. I see an animated
circle in the middle but nothing happens. There is no entry in the
engine log or the in any host log. If I wait long enough the UI
terminates the session and I'm at the login again.

Last question (for now, I promise): The engine VM is not visible in
the UI. Obviously it's running or otherwise there would be no UI.
From a variety of sources I get the impression that this shouldn't
be but I'm not sure why the engine VM is not showing itself.

Sorry for so many maybe obvious questions but since I'm new to oVirt
im still stumbling around in the dark for things that do not work
according to plan. In case of what should be shown in the UI I'm
still not sure what the plan is.

To give some background information about my setup:
All machines are running up to date versions of CentOS 7.1 64bit.
I've three dedicated machines for the gluster storage. The replica 3
gluster volumes are created on top of thinly provisioned volumes.

There are three dedicated hosts for virtualization. On the first I'm
trying a hosted-engine --deploy. The other two machines are unused
since I didn't get everything working as expected.

The engine, installed during the deploy process, is installed from a
local ISO Centos image. Installation is done manually.

I've created two gists:
One listing the commands for the gluster volume:
https://gist.github.com/tbihawk/4c92dc246a64990942d3#file-ovirt-gluster-setup

One listing what I've done to install oVirt:
https://gist.github.com/tbihawk/adb0a0e7d2a081d63629#file-ovirt-installation-procedure

Any help is highly appreciated since I'm kind of stuck.
Thanks!
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] Storage and ISO Domain and Engine VM

[Richard Neuboeck]

There is one obvious error in the web UI that I've overlooked so
far. 'Events' lists the following:

'The Hosted Engine Storage Domain doesn't no exist. It should be
imported into the setup.'

Except finding the github link to the source code googling didn't
reveal any hints on what to do to remedy this problem.

Cheers
Richard


On 09/16/2015 03:33 PM, Richard Neuboeck wrote:
> Hi oVirt Team,
> 
> I'm trying to set up oVirt 3.6 on three virtualization hosts
> connected to two other machines solely providing a replica 2 gluster
> storage. I know and understand that this setup is basically unwise
> and not supported but to prevent the gluster storage from going off
> line I followed the suggestion in
> https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Administration_Guide/sect-Managing_Split-brain.html
> 8.10.1.1 and added a dummy node with no bricks. Removing the
> requirement for replica 3 in nfs.py and allowing replica count 2 in
> vdsm.conf makes the installation possible without error.
> 
> But at the first login on the web UI the only thing showing that's
> configured during the installation process is the virtualization host.
> 
> The Engine VM is not listed in the Virtual Machines tab though the
> hosts shows one running VM. After watching several youtube videos
> from self hosed engine installations I'm guessing the Engine VM
> should be visible. Is there anything I can do?
> 
> The Storage tab is completely empty. The ISO Domain that is
> configured during the install is not shown. As well as the gluster
> storage that is storing the Engine VM.
> 
> I've heard in this video from Martin Sivak
> https://www.youtube.com/watch?v=EbRdUPVlxyQ that the storage domain
> where the Engine is stored is hidden. Why is that?
> 
> So if the Engine storage is separated from the other VMs storage
> there should be two gluster volumes for VM storage if the self
> hosted setup is used?
> 
> Why is the ISO Domain not shown?
> 
> Since I'm (still) an oVirt newbie I'm guessing something has gone
> wrong during the installation or I'm missing some piece of the
> puzzle. So here are more details:
> - The gluster hosts are running an up date CentOS 7.1, Gluster 3.7.
> The volume where the Engine is stored has the recommended
> optimizations as described in
> http://www.ovirt.org/Features/GlusterFS_Storage_Domain
> - The self hosted engine deployment install is running on a minimal
> CentOS 7.1 (up to date).
> http://www.ovirt.org/Hosted_Engine_Howto#Fresh_Install
> - The repo from which oVirt is coming:
> http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
> - I modified
> /usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/storage/nfs.py
> and substituted the replica 3 requirements appropriately for replica 2
> - and added allowed_replica_counts = 1,2,3 in /etc/vdsm/vdsm.conf
> - hosted-engine --deploy runs without errors. Except for
> 'balloonInfo' errors vdsm.log doesn't show any (obvious) errors either.
> - The engine setup in the VM (CentOS 7.1 again) runs without
> problems as well.
> - After the install has finished the Engine is _not_ run
> automatically. After waiting some minutes I've started it running
> hosted-engine --vm-start.
> 
> So far I've wiped everything clean and tried to install oVirt 3.6
> twice and twice it was the same result so I'm not sure how to proceed.
> 
> Any suggestions on what may have gone wrong or what I've missed to do?
> 
> Cheers
> Richard
> 
> 
> 
> ___
> 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

[ovirt-users] Storage and ISO Domain and Engine VM

[Richard Neuboeck]

Hi oVirt Team,

I'm trying to set up oVirt 3.6 on three virtualization hosts
connected to two other machines solely providing a replica 2 gluster
storage. I know and understand that this setup is basically unwise
and not supported but to prevent the gluster storage from going off
line I followed the suggestion in
https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Administration_Guide/sect-Managing_Split-brain.html
8.10.1.1 and added a dummy node with no bricks. Removing the
requirement for replica 3 in nfs.py and allowing replica count 2 in
vdsm.conf makes the installation possible without error.

But at the first login on the web UI the only thing showing that's
configured during the installation process is the virtualization host.

The Engine VM is not listed in the Virtual Machines tab though the
hosts shows one running VM. After watching several youtube videos
from self hosed engine installations I'm guessing the Engine VM
should be visible. Is there anything I can do?

The Storage tab is completely empty. The ISO Domain that is
configured during the install is not shown. As well as the gluster
storage that is storing the Engine VM.

I've heard in this video from Martin Sivak
https://www.youtube.com/watch?v=EbRdUPVlxyQ that the storage domain
where the Engine is stored is hidden. Why is that?

So if the Engine storage is separated from the other VMs storage
there should be two gluster volumes for VM storage if the self
hosted setup is used?

Why is the ISO Domain not shown?

Since I'm (still) an oVirt newbie I'm guessing something has gone
wrong during the installation or I'm missing some piece of the
puzzle. So here are more details:
- The gluster hosts are running an up date CentOS 7.1, Gluster 3.7.
The volume where the Engine is stored has the recommended
optimizations as described in
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
- The self hosted engine deployment install is running on a minimal
CentOS 7.1 (up to date).
http://www.ovirt.org/Hosted_Engine_Howto#Fresh_Install
- The repo from which oVirt is coming:
http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
- I modified
/usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/storage/nfs.py
and substituted the replica 3 requirements appropriately for replica 2
- and added allowed_replica_counts = 1,2,3 in /etc/vdsm/vdsm.conf
- hosted-engine --deploy runs without errors. Except for
'balloonInfo' errors vdsm.log doesn't show any (obvious) errors either.
- The engine setup in the VM (CentOS 7.1 again) runs without
problems as well.
- After the install has finished the Engine is _not_ run
automatically. After waiting some minutes I've started it running
hosted-engine --vm-start.

So far I've wiped everything clean and tried to install oVirt 3.6
twice and twice it was the same result so I'm not sure how to proceed.

Any suggestions on what may have gone wrong or what I've missed to do?

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] why replica 3

[Richard Neuboeck]

On 09/09/2015 10:54 AM, Simone Tiraboschi wrote:
> 
> 
> On Wed, Sep 9, 2015 at 10:14 AM, Richard Neuboeck
> mailto:h...@tbi.univie.ac.at>> wrote:
> 
> On 04.09.15 10:02, Simone Tiraboschi wrote:
> > Is there a reason why it has to be exactly replica 3?
> >
> >
> > To have a valid quorum having the system being able to decide witch is
> > the right and safe copy avoiding an issue called split brain.
> > Under certain circumstances/issues (network issue, hosts down or
> > whatever could happen) the data on different replica could diverge: if
> > you have two and just two different hosts that claim each other
> that its
> > copy is the right one there is no way to automatically take the right
> > decision. Having three hosts and setting the quorum according to that
> > solves/mitigates the issue.
> 
> 
> Thanks for the explanation. I do understand the problem but since
> I'm somewhat limited in my hardware options is there a way to
> override this requirement? Meaning if I change the checks for
> replica 3 in the installation scripts does something else fail on
> the way?
> 
> 
> I'm advising that it's not a safe configuration so it's not
> recommended for a production environment.
> Having said that, as far as I know it's enforced only in the setup
> script so tweaking it should be enough.
> Otherwise, if you have enough disk space, you can also have a
> different trick: you could create a replica 3 volume with 2 bricks
> from a single host.

I've thought about that but since that would obviously only help to
fool the installation script there is nothing else in this setup
that would improve the situation. Worse the read/write overhead on
the second machine would be a performance downgrade.

> It's not a safe procedure at all cause you still have only 2 hosts,
> so it's basically just replica 2, and in case of split brain the
> host with two copies will win by configuration which is not always
> the right decision.

Right. I'm thinking of trying to add a dummy node as mentioned in
the RHEL documentation. This would (in theory) prevent the read only
state in the split brain scenario and make it possible to access the
storage. But still the installation requirement of replica 3 would
not be satisfied.

> 
> In my case coherence checks would come from outside the storage and
> vm host setup and fencing would be applied appropriately.
> 
> 
> Can I ask how?

Multiple machines separated from the storage and virtualization
machines that will check communication (in general and of several
services) and try to intervene if there is something going awry
first by accessing the machines directly (if possible) and then by
deactivating those machines by remote management.

Cheers
Richard

> 
> I would very much appreciate it if the particulars of the storage
> setup could be either selected from a list of possibilities or be
> ignored and just a warning be issued that this setup is not
> recommended.
> 
> Thanks!
> 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] why replica 3

[Richard Neuboeck]

On 04.09.15 10:02, Simone Tiraboschi wrote:
> Is there a reason why it has to be exactly replica 3?
>
>
> To have a valid quorum having the system being able to decide witch is
> the right and safe copy avoiding an issue called split brain.
> Under certain circumstances/issues (network issue, hosts down or
> whatever could happen) the data on different replica could diverge: if
> you have two and just two different hosts that claim each other
that its
> copy is the right one there is no way to automatically take the right
> decision. Having three hosts and setting the quorum according to that
> solves/mitigates the issue.


Thanks for the explanation. I do understand the problem but since
I'm somewhat limited in my hardware options is there a way to
override this requirement? Meaning if I change the checks for
replica 3 in the installation scripts does something else fail on
the way?

In my case coherence checks would come from outside the storage and
vm host setup and fencing would be applied appropriately.

I would very much appreciate it if the particulars of the storage
setup could be either selected from a list of possibilities or be
ignored and just a warning be issued that this setup is not recommended.

Thanks!
Richard


-- 
/dev/null



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

[ovirt-users] why replica 3

[Richard Neuboeck]

Hi oVirt group,

I'm currently trying to set up an oVirt 3.6 self hosed engine on a
replica 2 gluster volume. As you can imagine it fails since it expects a
replica 3 volume.

Since this part is hard coded during the installation this could be
easily remedied but on the other hand I'm not familiar with the oVirt
setup so I'm not sure if I would be disturbing something far a head that
again is puzzled by the lack of a replica 3 volume.

Is there a reason why it has to be exactly replica 3?
Shouldn't the redundancy of the storage back end be the responsibility
of the admin and therefore the option to choose (at least replicated and
distributed replicated) open?

I'm asking because the storage back and I'm using is kind of a 'big'
thing and it's hardware is put together to facilitate the use of replica
2. Sure I could create multiple bricks on those two machines but other
than a negative performance impact I would gain nothing. Since the price
tag of one of those servers is quite high the likelihood of getting
another one is exactly 0. So I'm sure it makes sens to you that I would
rather choose my own replication level than having one predetermined.

All the best
Richard



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'

[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'

[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'

[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

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

[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