[ovirt-users] Re: FCoE wont initialize on reboot oVirt 4.2.

[Luca 'remix_tj' Lorenzetto]

On Wed, Nov 28, 2018 at 6:54 AM Jacob Green  wrote:
>
> Any help or insight into fiber channel with ovirt 4.2 would be greatly
> appreciated.
>

Hello Jacob,

we're running a cluster of 6 HP BL460 G9 with virtual connect without issues.

[root@kvmsv003 ~]# dmidecode | grep -A3 '^System Information'
System Information
Manufacturer: HP
Product Name: ProLiant BL460c Gen9
Version: Not Specified

We've, anyway, a different kind of CNA:

[root@kvmsv003 ~]# cat /sys/class/fc_host/host1/device/scsi_host/host1/modeldesc
HP FlexFabric 20Gb 2-port 650FLB Adapter

But i see is running the same module you're reporting

[root@kvmsv003 ~]# lsmod | grep bnx
bnx2fc103061  0
cnic   67392  1 bnx2fc
libfcoe58854  2 fcoe,bnx2fc
libfc 116357  3 fcoe,libfcoe,bnx2fc
scsi_transport_fc  64007  4 fcoe,lpfc,libfc,bnx2fc
[root@fapikvmpdsv003 ~]#

Since the fcoe connection is managed directly by virtual connect, i'm
not having fcoe informations shown with fcoeadm:

[root@kvmsv003 ~]# fcoeadm -i
[root@kvmsv003 ~]#

Are you sure you set up the right configuration on virtual connect side?

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SI7C5KFJT7BWDAB375DIS4NT6RYIYRQA/

[ovirt-users] FCoE wont initialize on reboot oVirt 4.2.

[Jacob Green]

I have HP BL460c Gen9 blades with  BCM57840 NetXtreme II 
10/20-Gigabit Ethernet via a HP Virtual connection. In my ovirt 4.1 
environment I have fibre channel working great.


However in the new environment that I want to bring the data domain over 
too ultimately, I am having issues with ovirt interfering with the hosts 
ability to see the Fiber Channel storage. If i build a clean CentOS 7 
installation and get my FCoE module installed and Fiber channel set up 
on my appropriate interfaces, it works and sees the fiber channel 
interface every time I type fcoeadm -i, I can reboot a million times, 
does not go away. However once I turn it into a oVirt 4.2 node and add 
it to my environment and reboot the blade it is hit or miss if fcoeadm 
-i is going to return interface information.


If I then type "systemctl restart network" my fiber channel comes 
online, but I should not need to do this. I can see in my dmesg logs 
that the fiber channel is initializing on boot.


[   39.465578] cnic: QLogic cnicDriver v2.5.22 (July 20, 2015)
[   39.465594] bnx2x :06:00.2 eno51: Added CNIC device
[   39.475618] bnx2x :06:00.3 eno52: Added CNIC device
[   39.495575] bnx2fc: QLogic FCoE Driver bnx2fc v2.11.8 (October 15, 2015)
[   39.505971] bnx2fc: bnx2fc: FCoE initialized for eno52.
[   39.506299] bnx2fc: [06]: FCOE_INIT passed
[   39.516308] bnx2fc: bnx2fc: FCoE initialized for eno51.
[   39.516654] bnx2fc: [06]: FCOE_INIT passed

Reminder I have not added a FC storage domain yet, because I need to 
turn off and detach the domain from the old 4.1 environment first. 
However that should not keep the fiber channel interfaces from coming up...


And I need to know its working before I do that.

Below is what an fcoeadm -i should return when it seems to be working.



fcoeadm -i
Description:  BCM57840 NetXtreme II 10/20-Gigabit Ethernet
Revision: 11
Manufacturer: Broadcom Limited
Serial Number:5CB901C7EE00

Driver:   bnx2x 1.712.30-0
Number of Ports:  1

Symbolic Name: bnx2fc (QLogic BCM57840) v2.11.8 over eno51
OS Device Name:host10
Node Name: 0x50060bc27a05
Port Name: 0x50060bc27a04
Fabric Name:0x1000c4f57c218ff4
Speed: unknown
Supported Speed:   1 Gbit, 10 Gbit
MaxFrameSize:  2048 bytes
FC-ID (Port ID):   0x0a025c
State: Online
Description:  BCM57840 NetXtreme II 10/20-Gigabit Ethernet
Revision: 11
Manufacturer: Broadcom Limited
Serial Number:5CB901C7EE00

Driver:   bnx2x 1.712.30-0
Number of Ports:  1

Symbolic Name: bnx2fc (QLogic BCM57840) v2.11.8 over eno52
OS Device Name:host11
Node Name: 0x50060bc27a07
Port Name: 0x50060bc27a06
Fabric Name:0x1000c4f57c21979d
Speed: unknown
Supported Speed:   1 Gbit, 10 Gbit
MaxFrameSize:  2048 bytes
FC-ID (Port ID):   0x14037b
State: Online




However if I reboot the node from the ovirt console and wait a few 
minutes after it has rebooted then type fcoeadm -i I get the following.


fcoeadm -i
fcoeadm: No action was taken
Try 'fcoeadm --help' for more information.

it is not until I perform a systemctl restart network, that I get the 
correct output from above.





Any help or insight into fiber channel with ovirt 4.2 would be greatly 
appreciated.





--
Jacob Green

Systems Admin

American Alloy Steel

713-300-5690
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TG6O2UJD5AZWVDHL2ILUJJDLMU6PSLFS/

[ovirt-users] Re: Cloud-init reset network configuration to default dhcp after reboot and regular run

[Mike Lykov]

27.11.2018 16:15, Eitan Raviv пишет:

According to cloud-init 0.7.9 documentation cloud-init is configured
to run by default on each boot [1] and to render the user-selected
network configuration on first boot [2]. Also, in absence of a data
source to configure the network, it will fall back to configuring DHCP
on eth0 [2].

As you noted, if you run a VM once, and then in the next regular run
the cloud-init flag is not selected in the VM configuration in engine,
there is no data-source and cloud-init falls back to dhcp as
documented.


Thanks for the explanation. What intended use of this subsystem/feature 
are supposed to?


My setup is not in cloud, it's local and use static IP adresses for VM.
I do not want to configure each VM network in console by hand.
I create VM from template (template have installed cloud-init package), 
configure cloud-init hostname/eth0 network in engine, and as "custom 
script" (at the same moment) I set a "touch 
/etc/cloud/cloud-init.disabled" ?
Then I "Run once" a VM, stop it, and run as usual without data source 
and fallback.
Or I name network interface not "eth0" and therefore without need for 
custom script?




The 'marker' file you refer to are also documented as follows:

* disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled
* preventing cloud-init from configuring the network [2] with: echo
‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg
whichever scenario is used to run a VM, this can be accomplished by
adding the above commands to the custom_script that cloud-init runs at
the last stage of its operation [3].

There is possibly a third 'hack' that would not require any marker file:
* assign your static IP to a NIC not named 'eth0'
I have not tested it myself but it looks like a corollary of [2]

HTH

[1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator
[2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local
[3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final

On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov  wrote:


20.11.2018 15:30, Mike Lykov пишет:


"cloud-init used to use a "marker" file that it created on initial
execution. If that "marker" file existed it would not rerun on reboot. "
- are it not working  in ovirt/this cloud-init version ?


new restart:

--
2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that
we need already exist from a previous run that would allow us to stop early.
2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no
previous run detected that would allow us to stop early.
-

which files it try to find ?

--
Mike

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5DWNRQZ3VPRWPFYMOLT/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS2TA2B6FILCNIYPHAW5/


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CDKFFGGNQ33RVKXOW7APVD7CMX77L7AM/

[ovirt-users] Re: ovirt 4.2.7.1 fails to deploy hosted engine on GlusterFS

[hunter86_bg]

It seems that I have picked the wrong deploy method. Switching to 
"HyperConverged" -> "Use existing" fixes the error.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZQN7SISXBUPE4ZLBRR27UHYC3DF6LGZQ/

[ovirt-users] ovirt 4.2.7.1 fails to deploy hosted engine on GlusterFS

[hunter86_bg]

Hello Community,

I'm trying to deploy a hosted engine on GlusterFS which fails with the 
following error:
[ INFO ] TASK [Add glusterfs storage domain]
[ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[Failed 
to fetch Gluster Volume List]". HTTP response code is 400.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "deprecations": 
[{"msg": "The 'ovirt_storage_domains' module is being renamed 
'ovirt_storage_domain'", "version": 2.8}], "msg": "Fault reason is \"Operation 
Failed\". Fault detail is \"[Failed to fetch Gluster Volume List]\". HTTP 
response code is 400."}

I have deployed GlusterFS via the HyperConverged  Option in Cockpit and the 
volumes are up and running.

[root@ovirt1 ~]# gluster volume status engine
Status of volume: engine
Gluster process TCP Port  RDMA Port  Online  Pid
--
Brick ovirt1:/gluster_bricks/engine/engine  49152 0  Y   26268
Brick ovirt2:/gluster_bricks/engine/engine  49152 0  Y   24116
Brick glarbiter:/gluster_bricks/engine/engi
ne  49152 0  Y   23526
Self-heal Daemon on localhost   N/A   N/AY   31229
Self-heal Daemon on ovirt2  N/A   N/AY   27097
Self-heal Daemon on glarbiter   N/A   N/AY   25888

Task Status of Volume engine
--
There are no active volume tasks

I'm using the following guide : 
https://ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/
And on step 4 - Storage - I have defined it as follows:
Storage Type: Gluster
Storage Connection:  ovirt1.localdomain:/gluster_bricks/engine/
Mount Options: backup-volfile-servers=ovirt2.localdomain:glarbiter.localdomain

Can someone hint me where is the problem ?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZQZFTK6PXS3HKURHUASWVKMSCCQMMQRE/

[ovirt-users] Change Default Behaviour

[Alex McWhirter]

In the admin interface, if i create a server template and make a VM out 
of it i get a Clone/Independent VM. If i use a dekstop template a get a 
Thin/Dependent


In the VM portal i only get Thin/Dependent.

How can i change this so that it's always Clone/Dependent for certain 
templates?

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SBJCLN4QPSNUFWB2XKS3TJ44VL4KC75J/

[ovirt-users] Re: AffinityGroup API

[Staniforth, Paul]

The user also has AffinityGroupManager role for the cluster this role has 
permission Manipulate Affinity Groups.

It is the same account that works when using the python SDK

2018-11-27 11:36:50,791Z INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5237) 
[b225cdb] Running command: CreateUserSessionCommand internal: false.
2018-11-27 11:36:50,988Z INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5229) [21e2d0fe] EVENT_ID: USER_VDC_LOGIN(30), User secgen@internal-authz 
connecting from 'x.x.x.x' using session 
'mT2aF7+FziRwE3ZZ29y7y2QHidDX4aAquc5fwo5swyLVMxufAyF26JbmDNeN9ylob1+zSSH9JWu4bBDt2wdHGw=='
 logged in.
2018-11-27 11:36:51,081Z INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-5233) [] 
User @internal successfully logged in with scopes: ovirt-app-api 
ovirt-ext=token-in
fo:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:passw..d-access
2018-11-27 11:36:51,154Z INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5233) 
[1d0e61f8] Running command: CreateUserSessionCommand internal: false.
2018-11-27 11:36:51,604Z INFO  
[org.ovirt.engine.core.bll.scheduling.commands.AddAffinityGroupCommand] 
(default task-5233) [dd01962d-bead-499a-a31f-1ead974483ac] No permission found 
for user 'd5b7e8f0-603e-47c5-a420-1f5f6834aa02' or one of the groups he is 
member of, when running action 'AddAffinityGroup', Required permissions are: 
Action type: 'ADMIN' Action group: 'MANIPULATE_AFFINITY_GROUPS' Object type: 
'Cluster'  Object ID: 'beac8771-1dbc-4046-99b1-c17d072fb27f'.
2018-11-27 11:36:51,604Z WARN  
[org.ovirt.engine.core.bll.scheduling.commands.AddAffinityGroupCommand] 
(default task-5233) [dd01962d-bead-499a-a31f-1ead974483ac] Validation of action 
'AddAffinityGroup' failed for user @internal-authz. Reasons: 
VAR__TYPE__AFFINITY_GROUP,VAR__ACTION__ADD,USER_NOT_AUTHORIZED_TO_PERFORM_ACTION
2018-11-27 11:36:51,606Z ERROR 
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default 
task-5233) [] Operation Failed: [User is not authorized to perform this action.]

Regards,
Paul S.



From: Schreuders, Cliffe
Sent: 27 November 2018 11:55
To: Ondra Machacek; Staniforth, Paul
Cc: Andrej Krejcir; users; Shaw, Thomas
Subject: Re: [ovirt-users] AffinityGroup API

Hi Ondra,

Thanks. Here is a sample script that illustrates the problem. The same error 
occurs when adding a VM to an existing affinity group.

Sample code:
require 'ovirtsdk4'

conn_attr = {}
conn_attr[:url] = 'https:///ovirt-engine/api'
conn_attr[:username] = ''
conn_attr[:passwxxd] = ''
conn_attr[:debug] = true
conn_attr[:headers] = {'Filter' => true }

ovirt_connection = OvirtSDK4::Connection.new(conn_attr)
vms_service = ovirt_connection.system_service.vms_service
clusters_service = ovirt_connection.system_service.clusters_service
cluster = clusters_service.list(search: 'name=Default')[0]
cluster_service = clusters_service.cluster_service(cluster.id)
cluster_affinitygroups_service = cluster_service.affinity_groups_service

begin
  affinity_group_name = "affinity_group_test123"
  puts "Creating affinity group: #{affinity_group_name}"

  cluster_affinitygroups_service.add(OvirtSDK4::AffinityGroup.new(
 name: affinity_group_name,
 description: 'a description',
 vms_rule: OvirtSDK4::AffinityRule.new(
  enabled: true,
  positive: true,
  enforcing: true
 )
  ))
rescue Exception => e
  warn "Failed to create affinity group"
  warn e.message
end

Output:
cliffe@office:~/Code/ovirt_scripts$ ruby add_affinity_group.rb
Creating affinity group: affinity_group_test123
Failed to create affinity group
Fault reason is "Operation Failed". Fault detail is "[User is not authorized to 
perform this action.]". HTTP response code is 400.

The user has ReadOnlyAdmin permissions.

I would be happy to be told if I'm doing something wrong here, I didn't find 
any ruby examples that worked with affinity groups.

Paul could you please provide the engine.log entries? Thanks.

Cheers,

Cliffe.

On 27/11/2018 10:04, Ondra Machacek wrote:
Can you please share the script? And also what's the permission of the
user you are executing the script.

When see error 'User is not authorized to perform the action', we print
in engine.log, what's exactly wrong meaning we print what permissions
the user is missing in order to execute that action. So it may help you
find out what's wrong as well.

On 11/26/18 5:35 PM, Schreuders, Cliffe wrote:
Yes, the related issue we came across was that when using the Ruby gem,
assigning a VM to an Affinity Group raises an exception that states the
User is not authorized to perform the action; however, using the same
account works fine from the Admin portal and carrying out the exact same
steps via the Python SDK works as expected. The end result is that we
ended up ca

[ovirt-users] Re: vGPU not available in "type mdev"

[Marc Le Grand]

I saw that table but I thought it was just for vSphere Xen.. because there were 
so few GPU.
It's also strange that the P100 is noticed; as by boss made the share of a P400 
work with kvm, 
P400 which is not listed...
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJJKBYPZV2DGWJY3QTJGRI6CWTV7YTVN/

[ovirt-users] Re: AffinityGroup API

[Ondra Machacek]

So both of the user's roles are administrative,
so please try to remove following line in your script:

 > conn_attr[:headers] = {'Filter' => true }

This should be used only with roles which are not administrative,
like UserVmManager, etc.

On 11/27/18 1:21 PM, Staniforth, Paul wrote:

The user also has AffinityGroupManager role for the cluster this role has 
permission Manipulate Affinity Groups.

It is the same account that works when using the python SDK

2018-11-27 11:36:50,791Z INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5237) 
[b225cdb] Running command: CreateUserSessionCommand internal: false.
2018-11-27 11:36:50,988Z INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5229) [21e2d0fe] EVENT_ID: USER_VDC_LOGIN(30), User secgen@internal-authz 
connecting from 'x.x.x.x' using session 
'mT2aF7+FziRwE3ZZ29y7y2QHidDX4aAquc5fwo5swyLVMxufAyF26JbmDNeN9ylob1+zSSH9JWu4bBDt2wdHGw=='
 logged in.
2018-11-27 11:36:51,081Z INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-5233) [] 
User @internal successfully logged in with scopes: ovirt-app-api 
ovirt-ext=token-in
fo:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:passw..d-access
2018-11-27 11:36:51,154Z INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5233) 
[1d0e61f8] Running command: CreateUserSessionCommand internal: false.
2018-11-27 11:36:51,604Z INFO  
[org.ovirt.engine.core.bll.scheduling.commands.AddAffinityGroupCommand] 
(default task-5233) [dd01962d-bead-499a-a31f-1ead974483ac] No permission found 
for user 'd5b7e8f0-603e-47c5-a420-1f5f6834aa02' or one of the groups he is 
member of, when running action 'AddAffinityGroup', Required permissions are: 
Action type: 'ADMIN' Action group: 'MANIPULATE_AFFINITY_GROUPS' Object type: 
'Cluster'  Object ID: 'beac8771-1dbc-4046-99b1-c17d072fb27f'.
2018-11-27 11:36:51,604Z WARN  
[org.ovirt.engine.core.bll.scheduling.commands.AddAffinityGroupCommand] 
(default task-5233) [dd01962d-bead-499a-a31f-1ead974483ac] Validation of action 
'AddAffinityGroup' failed for user @internal-authz. Reasons: 
VAR__TYPE__AFFINITY_GROUP,VAR__ACTION__ADD,USER_NOT_AUTHORIZED_TO_PERFORM_ACTION
2018-11-27 11:36:51,606Z ERROR 
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default 
task-5233) [] Operation Failed: [User is not authorized to perform this action.]

Regards,
 Paul S.



From: Schreuders, Cliffe
Sent: 27 November 2018 11:55
To: Ondra Machacek; Staniforth, Paul
Cc: Andrej Krejcir; users; Shaw, Thomas
Subject: Re: [ovirt-users] AffinityGroup API

Hi Ondra,

Thanks. Here is a sample script that illustrates the problem. The same error 
occurs when adding a VM to an existing affinity group.

Sample code:
require 'ovirtsdk4'

conn_attr = {}
conn_attr[:url] = 'https:///ovirt-engine/api'
conn_attr[:username] = ''
conn_attr[:passwxxd] = ''
conn_attr[:debug] = true
conn_attr[:headers] = {'Filter' => true }

ovirt_connection = OvirtSDK4::Connection.new(conn_attr)
vms_service = ovirt_connection.system_service.vms_service
clusters_service = ovirt_connection.system_service.clusters_service
cluster = clusters_service.list(search: 'name=Default')[0]
cluster_service = clusters_service.cluster_service(cluster.id)
cluster_affinitygroups_service = cluster_service.affinity_groups_service

begin
   affinity_group_name = "affinity_group_test123"
   puts "Creating affinity group: #{affinity_group_name}"

   cluster_affinitygroups_service.add(OvirtSDK4::AffinityGroup.new(
  name: affinity_group_name,
  description: 'a description',
  vms_rule: OvirtSDK4::AffinityRule.new(
   enabled: true,
   positive: true,
   enforcing: true
  )
   ))
rescue Exception => e
   warn "Failed to create affinity group"
   warn e.message
end

Output:
cliffe@office:~/Code/ovirt_scripts$ ruby add_affinity_group.rb
Creating affinity group: affinity_group_test123
Failed to create affinity group
Fault reason is "Operation Failed". Fault detail is "[User is not authorized to 
perform this action.]". HTTP response code is 400.

The user has ReadOnlyAdmin permissions.

I would be happy to be told if I'm doing something wrong here, I didn't find 
any ruby examples that worked with affinity groups.

Paul could you please provide the engine.log entries? Thanks.

Cheers,

Cliffe.

On 27/11/2018 10:04, Ondra Machacek wrote:
Can you please share the script? And also what's the permission of the
user you are executing the script.

When see error 'User is not authorized to perform the action', we print
in engine.log, what's exactly wrong meaning we print what permissions
the user is missing in order to execute that action. So it may help you
find out what's wrong as well.

On 11/26/18 5:35 PM, Schreuders, Cliffe wrote:
Yes, the related issue we came across was that when using the Rub

[ovirt-users] Re: VM ramdomly unresponsive

[fsoyer]

Hi,
questioning me about all the chain oVirt -> Gluster -> hardware, I continued to 
check all the components, finally testing the hardware.
I found some latencies on storage when it was busy, and some searches on web 
convinced me that the RAID cards could be the problem : Dell servers are 
shipped with H310 cards which do not support cache... last week we ordered H710 
cards, providing cache, installed Saturday. Since it, storage performances are 
better, and I noticed no more timeout or errors. But it happened ramdomly, so I 
wait some days more to say that this is solved !

Thank you for the wasted time,
--

Regards,

Frank
Le Mardi, Novembre 27, 2018 08:30 CET, Sahina Bose  a écrit:
 On Tue, Nov 13, 2018 at 4:46 PM fsoyer  wrote:
>
> Hi all,
> I continue to try to understand my problem between (I suppose) oVirt anf 
> Gluster.
> After my recents posts titled 'VMs unexpectidly restarted' that did not 
> provide solution nor search idea, I submit to you another (related ?) problem.
> Parallely with the problem of VMs down (that did not reproduce since Oct 16), 
> I have ramdomly some events in the GUI saying "VM x is not responding." 
> For example, VM "patjoub1" on 2018-11-11 14:34. Never the same hour, not all 
> the days, often this VM patjoub1 but not always : I had it on two others. All 
> VMs disks are on a volume DATA02 (with leases on the same volume).
>
> Searching in engine.log, I found :
>
> 2018-11-11 14:34:32,953+01 INFO 
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-28) [] VM 
> '6116fb07-096b-4c7e-97fe-01ecc9a6bd9b'(patjoub1) moved from 'Up' --> 
> 'NotResponding'
> 2018-11-11 14:34:33,116+01 WARN 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-1) [] Invalid or unknown 
> guest architecture type '' received from guest agent
> 2018-11-11 14:34:33,176+01 WARN 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-28) [] EVENT_ID: 
> VM_NOT_RESPONDING(126), VM patjoub1 is not responding.
> ...
> ...
> 2018-11-11 14:34:48,278+01 INFO 
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-48) [] VM 
> '6116fb07-096b-4c7e-97fe-01ecc9a6bd9b'(patjoub1) moved from 'NotResponding' 
> --> 'Up'
>
> So it becomes up 15s after, and the VM (and the monitoring) see no downtime.
> At this time, I see in vdsm.log of the nodes :
>
> 2018-11-11 14:33:49,450+0100 ERROR (check/loop) [storage.Monitor] Error 
> checking path 
> /rhev/data-center/mnt/glusterSD/victor.local.systea.fr:_DATA02/ffc53fd8-c5d1-4070-ae51-2e91835cd937/dom_md/metadata
>  (monitor:498)
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 496, in 
> _pathChecked
> delay = result.delay()
> File "/usr/lib/python2.7/site-packages/vdsm/storage/check.py", line 391, in 
> delay
> raise exception.MiscFileReadException(self.path, self.rc, self.err)
> MiscFileReadException: Internal file read failure: 
> (u'/rhev/data-center/mnt/glusterSD/victor.local.systea.fr:_DATA02/ffc53fd8-c5d1-4070-ae51-2e91835cd937/dom_md/metadata',
>  1, 'Read timeout')
> 2018-11-11 14:33:49,450+0100 INFO (check/loop) [storage.Monitor] Domain 
> ffc53fd8-c5d1-4070-ae51-2e91835cd937 became INVALID (monitor:469)
>
> 2018-11-11 14:33:59,451+0100 WARN (check/loop) [storage.check] Checker 
> u'/rhev/data-center/mnt/glusterSD/victor.local.systea.fr:_DATA02/ffc53fd8-c5d1-4070-ae51-2e91835cd937/dom_md/metadata'
>  is blocked for 20.00 seconds (check:282)
>
> 2018-11-11 14:34:09,480+0100 INFO (event/37) [storage.StoragePool] Linking 
> /rhev/data-center/mnt/glusterSD/victor.local.systea.fr:_DATA02/ffc53fd8-c5d1-4070-ae51-2e91835cd937
>  to 
> /rhev/data-center/6efda7f8-b62f-11e8-9d16-00163e263d21/ffc53fd8-c5d1-4070-ae51-2e91835cd937
>  (sp:1230)
>
> OK : so, DATA02 marked as blocked for 20s ? I definitly have a problem with 
> gluster ? I'll inevitably find the reason in the gluster logs ? Uh : not at 
> all.
> Please see gluster logs here :
> https://seafile.systea.fr/d/65df86cca9d34061a1e4/
>
> Unfortunatly I discovered this morning that I have not the sanlock.log for 
> this date. I don't understand why, the log rotate seems OK with "rotate 3", 
> but I have no backups files :(.
> But, luck in bad luck, the same event occurs this morning ! Same VM patjoub1, 
> 2018-11-13 08:01:37. So I have added the sanlock.log for today, maybe it can 
> help.
>
> IMPORTANT NOTE : don't forget that Gluster log with on hour shift. For this 
> event at 14:34, search at 13h34 in gluster logs.
> I recall my configuration :
> Gluster 3.12.13
> oVirt 4.2.3
> 3 nodes where the third is arbiter (volumes in replica 2)
>
> The nodes are never overloaded (CPU average 5%, no peak detected at the time 
> of the event, mem 128G used at 15% (only 10 VMs on this cluster)). Network 
> underused, 

[ovirt-users] Re: extract nested attribute from a href link with ansible ovirt_vm_facts

[Lucie Leistnerova]

Hello Nathanaël,

On 11/27/18 10:08 AM, Nathanaël Blanchet wrote:

Hello

I'd like to extract all vms which have the lease optionnal attribute 
and  display the name of the storage domain of that lease.


I managed to get that dict:

    "lease": {
    "storage_domain": {
    "href": 
"/ovirt-engine/api/storagedomains/0dc2941a-bdc2-4ce4-8ad7-43fa9c944f88",

    "id": "0dc2941a-bdc2-4ce4-8ad7-43fa9c944f88"
    }

but how can I get the name of the storage instead of its id?

Unfortunately there is no way how to get the name directly in 
ovirt_vm_facts. Parameter fetch_nested works only for  API 
elements. But it is planned to add also this functionality. To be sure, 
I created RFE for it


https://bugzilla.redhat.com/show_bug.cgi?id=1653743


thank you for your help

You can get the storage information with ovirt_storage_domain module 
(ovirt_storage_domain_facts can't search via id)


    - name: Test
  ovirt_storage_domain:
    auth: "{{ ovirt_auth }}"
    id: "b1d7018b-14b1-4766-b390-5a95974ec38b"
  register: mystorage


Hopefully it helps.

Best regards,

Lucie

--
Lucie Leistnerova
Quality Engineer, QE Cloud, RHVM
Red Hat EMEA

IRC: lleistne @ #rhev-qe
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XCWW7QM2OL4DOY7JM2V3RS75A5O4ETAM/

[ovirt-users] Re: selfhost

[Simone Tiraboschi]

On Tue, Nov 27, 2018 at 12:37 PM  wrote:

> Hi ,
> can we build ovirt-selfhost inside ovirt-selfhost ?
>
>
Yes, you have to:
- enable nested-vritualization on L0 host
- create a custom vNic profile on the external oVirt in order to disable
the nomacspoof filter. You have to assign that profile to the interface of
the VM you are going to use as hosts in your nested env.


>
>
> can anybody answer this question ,please
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/V43WNJGSDEPMOB57Z454P6HWNGZCU3M6/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/72JPDMA5T3T5VUUZYJSLDQSUDBGBJDR3/

[ovirt-users] Re: vGPU not available in "type mdev"

[femi adegoke]

For vGPU to work you'll need to use one of these GPUs: 
https://docs.nvidia.com/grid/6.0/product-support-matrix/

On Nov 27 2018, at 4:47 am, Marc Le Grand  wrote:
>
> Hello
> I followed the tutorial regarding vGPU but it's not working, i i guess it's a 
> Nvidia licence issue, but i need to be sure.
> My node is installed using the node ISO image.
> I just removed the nouveau driver ans installed the nVidia one.
> My product is : "GK106GL [Quadro K4000]"
> My driver is : NVIDIA-Linux-x86_64-390.87
> In the host peripherals I see my card (pci__05_00_0) listed, but the 
> column "type mdev" is empty, as the doc says I should see vGPU i guess 
> something is missing.
> I took a look, there seems to be nVidia vGPU copatible driver, but no trace 
> of it. The only vGPU stuff i found it's "NVIDIA VIRTUAL GPU" and i understand 
> I have to pay to use vGPU on my nVidia card.
> is this correct or no ?
> If i'm supposed to pay is there a free workaround ?
> thanks for your help
> marc
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFJMRSEFKPIBLMCFF6EYEWRN7NB7Q6L6/
>

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VRIKD75FZOORV3OUJ7IMDNYNOBGOSQ7Y/

[ovirt-users] Re: vGPU not available in "type mdev"

[Marc Le Grand]

oh...
I did not thought they could limit vGPU to some cards !
thanks you very much for your help
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VRHMYR2Q57R6WJBOCV5XBMZBISOGRHTU/

[ovirt-users] Re: vGPU not available in "type mdev"

[Alex McWhirter]

On 2018-11-27 07:47, Marc Le Grand wrote:

Hello
I followed the tutorial regarding vGPU but it's not working, i i guess
it's a Nvidia licence issue, but i need to be sure.
My node is installed using the node ISO image.
I just removed the nouveau driver ans installed the nVidia one.
My product is : "GK106GL [Quadro K4000]"
My driver is : NVIDIA-Linux-x86_64-390.87
In the host peripherals I see my card (pci__05_00_0) listed, but
the column "type mdev" is empty, as the doc says I should see vGPU i
guess something is missing.
I took a look, there seems to be nVidia vGPU copatible driver, but no
trace of it. The only vGPU stuff i found it's "NVIDIA VIRTUAL GPU" and
i understand I have to pay to use vGPU on my nVidia card.
is this correct or no ?
If i'm supposed to pay is there a free workaround ?
thanks for your help
marc


It's my understanding that nvidia vgpu requires specialized cards, like 
the nvidia grid cards or quadro wds cards. There are some early models 
of these cards like the Grid K1 or K2 that did not need licensing, but 
the newer ones do. I don't think it's possible to get vgpu working on a 
standard quadro card.

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CFB757MKTRQGKNZBG3V6YRT6MNVLQ36T/

[ovirt-users] Re: vGPU not available in "type mdev"

[Marc Le Grand]

update:
I installed this driver, it looks like it supports vgpu :
./NVIDIA-Linux-x86_64-410.71-grid.run
then
NVIDIA-vGPU-rhel-7.5-410.68.x86_64.rpm
but it's the same, nothing in  column "type mdev"
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/63KPA7LWDUOXZJOB2WVFAVQ5VXWGQWX6/

[ovirt-users] vGPU not available in "type mdev"

[Marc Le Grand]

Hello
I followed the tutorial regarding vGPU but it's not working, i i guess it's a 
Nvidia licence issue, but i need to be sure.
My node is installed using the node ISO image.
I just removed the nouveau driver ans installed the nVidia one.
My product is : "GK106GL [Quadro K4000]"
My driver is : NVIDIA-Linux-x86_64-390.87
In the host peripherals I see my card (pci__05_00_0) listed, but the column 
"type mdev" is empty, as the doc says I should see vGPU i guess something is 
missing.
I took a look, there seems to be nVidia vGPU copatible driver, but no trace of 
it. The only vGPU stuff i found it's "NVIDIA VIRTUAL GPU" and i understand I 
have to pay to use vGPU on my nVidia card.
is this correct or no ? 
If i'm supposed to pay is there a free workaround ?
thanks for your help
marc
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFJMRSEFKPIBLMCFF6EYEWRN7NB7Q6L6/

[ovirt-users] Re: Cloud-init reset network configuration to default dhcp after reboot and regular run

[Eitan Raviv]

According to cloud-init 0.7.9 documentation cloud-init is configured
to run by default on each boot [1] and to render the user-selected
network configuration on first boot [2]. Also, in absence of a data
source to configure the network, it will fall back to configuring DHCP
on eth0 [2].

As you noted, if you run a VM once, and then in the next regular run
the cloud-init flag is not selected in the VM configuration in engine,
there is no data-source and cloud-init falls back to dhcp as
documented.

The 'marker' file you refer to are also documented as follows:

* disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled
* preventing cloud-init from configuring the network [2] with: echo
‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg
whichever scenario is used to run a VM, this can be accomplished by
adding the above commands to the custom_script that cloud-init runs at
the last stage of its operation [3].

There is possibly a third 'hack' that would not require any marker file:
* assign your static IP to a NIC not named 'eth0'
I have not tested it myself but it looks like a corollary of [2]

HTH

[1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator
[2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local
[3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final

On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov  wrote:
>
> 20.11.2018 15:30, Mike Lykov пишет:
>
> > "cloud-init used to use a "marker" file that it created on initial
> > execution. If that "marker" file existed it would not rerun on reboot. "
> > - are it not working  in ovirt/this cloud-init version ?
>
> new restart:
>
> --
> 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that
> we need already exist from a previous run that would allow us to stop early.
> 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no
> previous run detected that would allow us to stop early.
> -
>
> which files it try to find ?
>
> --
> Mike
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5DWNRQZ3VPRWPFYMOLT/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS2TA2B6FILCNIYPHAW5/

[ovirt-users] Re: selfhost

[Kaustav Majumder]

Do you mean nested virtualization?

On Tue, Nov 27, 2018 at 5:07 PM  wrote:

> Hi ,
> can we build ovirt-selfhost inside ovirt-selfhost ?
>
>
>
> can anybody answer this question ,please
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/V43WNJGSDEPMOB57Z454P6HWNGZCU3M6/
>


-- 

KAUSTAV MAJUMDER

ASSOCIATE SOFTWARE ENGINEER

Red Hat India PVT LTD. 

kmajum...@redhat.comM: 08981884037 IM: IRC: kmajumder

TRIED. TESTED. TRUSTED. 
@redhatway    @redhatinc
   @redhatsnaps

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/L347K6JXZ22SCSY2TFEMUGSTUC7CECQK/

[ovirt-users] selfhost

[mustafa . taha . mu95]

Hi , 
can we build ovirt-selfhost inside ovirt-selfhost ? 



can anybody answer this question ,please  
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V43WNJGSDEPMOB57Z454P6HWNGZCU3M6/

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Kaustav Majumder]

You are welcome.

On Tue, Nov 27, 2018 at 4:24 PM Abhishek Sahni 
wrote:

> Thanks a lot. :-)
>
> On Tue, Nov 27, 2018 at 4:22 PM Kaustav Majumder 
> wrote:
>
>>
>>
>> On Tue, Nov 27, 2018 at 4:05 PM Abhishek Sahni 
>> wrote:
>>
>>> That is amazing, resetting bricks resolved the issue.
>>>
>>> Thanks much Sahina and Kaustav.
>>>
>>> However, Do we have manual steps to recover those bricks.
>>>
>> https://gluster.readthedocs.io/en/latest/release-notes/3.9.0/
>>
>>>
>>> On Tue, Nov 27, 2018 at 3:57 PM Abhishek Sahni 
>>> wrote:
>>>
 I just enabled it on default cluster and now the volumes are visible.
 It seems like gluster service was disabled by default on cluster.

 On Tue, Nov 27, 2018 at 3:51 PM Sahina Bose  wrote:

>
>
> On Tue, Nov 27, 2018 at 3:45 PM Kaustav Majumder 
> wrote:
>
>> I am not sure why ovirt is not showing any volume.
>> Sahina, is this a bug?
>>
>
> Check if gluster service is enabled on the cluster.
> The volumes are managed only if this is true
>
>
>> On Tue, Nov 27, 2018 at 3:10 PM Abhishek Sahni <
>> abhishek.sahni1...@gmail.com> wrote:
>>
>>> Hello Kaustav,
>>>
>>> That's weird, I never saw any volumes under the storage tab since
>>> installation. I am using HC setup deployed using cockpit console.
>>>
>>> https://imgur.com/a/nH9rzK8
>>>
>>> Did I miss something?
>>>
>>>
>>> On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder <
>>> kmaju...@redhat.com> wrote:
>>>
 Click on volume for which you want to reset the brick-> under
 bricks tab select the brick you wan to reset -> once you do you will 
 see
 the 'Reset Brick' option is active.
 Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png

 On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
 abhishek.sahni1...@gmail.com> wrote:

> Thanks Sahina for your response, I am not able to find it on UI,
> please help me to navigate? and yes I am using oVirt 4.2.6.4-1.
>
> On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose 
> wrote:
>
>>
>>
>> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
>> abhishek.sahni1...@gmail.com> wrote:
>>
>>> Hello Team,
>>>
>>> We are running a setup of 3-way replica HC gluster setup
>>> configured during the initial deployment from the cockpit console 
>>> using
>>> ansible.
>>>
>>> NODE1
>>>   - /dev/sda   (OS)
>>>   - /dev/sdb   ( Gluster Bricks )
>>>* /gluster_bricks/engine/engine/
>>>* /gluster_bricks/data/data/
>>>* /gluster_bricks/vmstore/vmstore/
>>>
>>> NODE2 and NODE3 with a similar setup.
>>>
>>> There is a mishap that /dev/sdb on NODE2 totally got crashed and
>>> now there is nothing inside. However, I have created similar 
>>> directories
>>> after mounting it back i.e.,
>>>
>>>* /gluster_bricks/engine/engine/
>>>* /gluster_bricks/data/data/
>>>* /gluster_bricks/vmstore/vmstore/
>>> but it is not yet recovered.
>>>
>>> =
>>> [root@node2 ~]# gluster volume status
>>> Status of volume: data
>>> Gluster process TCP Port  RDMA Port
>>> Online  Pid
>>>
>>> --
>>> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>>>  1
>>> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>>>  N/A
>>> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>>>  4303
>>> Self-heal Daemon on localhost   N/A   N/A
>>> Y   23976
>>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>>  27838
>>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>>  27424
>>>
>>> Task Status of Volume data
>>>
>>> --
>>> There are no active volume tasks
>>>
>>> Status of volume: engine
>>> Gluster process TCP Port  RDMA Port
>>> Online  Pid
>>>
>>> --
>>> Brick *.*.*.1:/gluster_bricks/engine/eng
>>> ine 49153 0
>>> Y   7
>>> Brick *.*.*.2:/gluster_bricks/engine/eng
>>> ine N/A   N/A
>>> N  

[ovirt-users] Re: Remote console access for old Ovirt 3.6 install

[David Gossage]

Thanks, I'll look into it though I am hoping to migrate the whole system to
new hardware and updated version in coming weeks.
Last night I copied the engine vm image to a simple kvm host and loaded up
the image and ran the xfs_repair on /var which fixed the problems it had
then copied the image back over to ovirt and it started up.  Little lengthy
but it got me back up.

*David Gossage*
*Carousel Checks Inc. | System Administrator*
*Office* 708.613.2284


On Tue, Nov 27, 2018 at 12:54 AM Yedidyah Bar David  wrote:

> On Mon, Nov 26, 2018 at 8:18 PM David Gossage
>  wrote:
> >
> > I have an older 3.6.7 setup I am still using at a location.  The
> hosted-engine is up but not responding
> >
> > {"reason": "failed liveliness check", "health": "bad", "vm": "up",
> "detail": "up"}
> >
> > I am guessing it got into some paused or halted state after a power
> outage and storage went offline for a short bit and I may need to manually
> perform some tasks.  When I attempt the suggested method of
> > hosted-engine --set-maintenance --mode=global
> > hosted-engine --console
> >
> > I get an error about
> >
> > Use the password you've set using --add-console-password for logging in
> >
> > ** (remote-viewer:11479): WARNING **: Could not open X display
> > Cannot open display:
> > Run 'remote-viewer --help' to see a full list of available command line
> options
>
> Recent versions configure the hosted-engine vm to use a serial console,
> which is much easier to use (if you have no X on the host).
>
> For older versions, you might want to check a page I wrote some time ago,
> that does not exist anymore on the website, but can be found at
> archive.org:
>
>
> http://web.archive.org/web/20150704004004/http://www.ovirt.org:80/Hosted_Engine_Console
>
> Good luck and best regards,
>
> >
> > Their are 7 other VM's running I was able to manually continue from
> vdsClient
> >
> > Is their a way to get remote access to this engine?
> >
> > David Gossage
> > Carousel Checks Inc. | System Administrator
> > Office 708.613.2284
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QVO7CA4MDK7BIJJWZPEP6JLPSAJMVQCD/
>
>
>
> --
> Didi
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JH6YUZ6ONHSIIJMIW2AS6LC5QDPTGH6N/

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Abhishek Sahni]

Thanks a lot. :-)

On Tue, Nov 27, 2018 at 4:22 PM Kaustav Majumder 
wrote:

>
>
> On Tue, Nov 27, 2018 at 4:05 PM Abhishek Sahni 
> wrote:
>
>> That is amazing, resetting bricks resolved the issue.
>>
>> Thanks much Sahina and Kaustav.
>>
>> However, Do we have manual steps to recover those bricks.
>>
> https://gluster.readthedocs.io/en/latest/release-notes/3.9.0/
>
>>
>> On Tue, Nov 27, 2018 at 3:57 PM Abhishek Sahni 
>> wrote:
>>
>>> I just enabled it on default cluster and now the volumes are visible. It
>>> seems like gluster service was disabled by default on cluster.
>>>
>>> On Tue, Nov 27, 2018 at 3:51 PM Sahina Bose  wrote:
>>>


 On Tue, Nov 27, 2018 at 3:45 PM Kaustav Majumder 
 wrote:

> I am not sure why ovirt is not showing any volume.
> Sahina, is this a bug?
>

 Check if gluster service is enabled on the cluster.
 The volumes are managed only if this is true


> On Tue, Nov 27, 2018 at 3:10 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Hello Kaustav,
>>
>> That's weird, I never saw any volumes under the storage tab since
>> installation. I am using HC setup deployed using cockpit console.
>>
>> https://imgur.com/a/nH9rzK8
>>
>> Did I miss something?
>>
>>
>> On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder 
>> wrote:
>>
>>> Click on volume for which you want to reset the brick-> under bricks
>>> tab select the brick you wan to reset -> once you do you will see the
>>> 'Reset Brick' option is active.
>>> Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png
>>>
>>> On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
>>> abhishek.sahni1...@gmail.com> wrote:
>>>
 Thanks Sahina for your response, I am not able to find it on UI,
 please help me to navigate? and yes I am using oVirt 4.2.6.4-1.

 On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose 
 wrote:

>
>
> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Hello Team,
>>
>> We are running a setup of 3-way replica HC gluster setup
>> configured during the initial deployment from the cockpit console 
>> using
>> ansible.
>>
>> NODE1
>>   - /dev/sda   (OS)
>>   - /dev/sdb   ( Gluster Bricks )
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>>
>> NODE2 and NODE3 with a similar setup.
>>
>> There is a mishap that /dev/sdb on NODE2 totally got crashed and
>> now there is nothing inside. However, I have created similar 
>> directories
>> after mounting it back i.e.,
>>
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>> but it is not yet recovered.
>>
>> =
>> [root@node2 ~]# gluster volume status
>> Status of volume: data
>> Gluster process TCP Port  RDMA Port
>> Online  Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>>  1
>> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>>  N/A
>> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>>  4303
>> Self-heal Daemon on localhost   N/A   N/A
>> Y   23976
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>>
>> Task Status of Volume data
>>
>> --
>> There are no active volume tasks
>>
>> Status of volume: engine
>> Gluster process TCP Port  RDMA Port
>> Online  Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/engine/eng
>> ine 49153 0
>> Y   7
>> Brick *.*.*.2:/gluster_bricks/engine/eng
>> ine N/A   N/A
>> N   N/A
>> Brick *.*.*.3:/gluster_bricks/engine/eng
>> ine 49153 0
>> Y   4314
>> Self-heal Daemon on localhost   N/A   N/A
>> Y   23976

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Kaustav Majumder]

On Tue, Nov 27, 2018 at 4:05 PM Abhishek Sahni 
wrote:

> That is amazing, resetting bricks resolved the issue.
>
> Thanks much Sahina and Kaustav.
>
> However, Do we have manual steps to recover those bricks.
>
https://gluster.readthedocs.io/en/latest/release-notes/3.9.0/

>
> On Tue, Nov 27, 2018 at 3:57 PM Abhishek Sahni 
> wrote:
>
>> I just enabled it on default cluster and now the volumes are visible. It
>> seems like gluster service was disabled by default on cluster.
>>
>> On Tue, Nov 27, 2018 at 3:51 PM Sahina Bose  wrote:
>>
>>>
>>>
>>> On Tue, Nov 27, 2018 at 3:45 PM Kaustav Majumder 
>>> wrote:
>>>
 I am not sure why ovirt is not showing any volume.
 Sahina, is this a bug?

>>>
>>> Check if gluster service is enabled on the cluster.
>>> The volumes are managed only if this is true
>>>
>>>
 On Tue, Nov 27, 2018 at 3:10 PM Abhishek Sahni <
 abhishek.sahni1...@gmail.com> wrote:

> Hello Kaustav,
>
> That's weird, I never saw any volumes under the storage tab since
> installation. I am using HC setup deployed using cockpit console.
>
> https://imgur.com/a/nH9rzK8
>
> Did I miss something?
>
>
> On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder 
> wrote:
>
>> Click on volume for which you want to reset the brick-> under bricks
>> tab select the brick you wan to reset -> once you do you will see the
>> 'Reset Brick' option is active.
>> Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png
>>
>> On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
>> abhishek.sahni1...@gmail.com> wrote:
>>
>>> Thanks Sahina for your response, I am not able to find it on UI,
>>> please help me to navigate? and yes I am using oVirt 4.2.6.4-1.
>>>
>>> On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose 
>>> wrote:
>>>


 On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
 abhishek.sahni1...@gmail.com> wrote:

> Hello Team,
>
> We are running a setup of 3-way replica HC gluster setup
> configured during the initial deployment from the cockpit console 
> using
> ansible.
>
> NODE1
>   - /dev/sda   (OS)
>   - /dev/sdb   ( Gluster Bricks )
>* /gluster_bricks/engine/engine/
>* /gluster_bricks/data/data/
>* /gluster_bricks/vmstore/vmstore/
>
> NODE2 and NODE3 with a similar setup.
>
> There is a mishap that /dev/sdb on NODE2 totally got crashed and
> now there is nothing inside. However, I have created similar 
> directories
> after mounting it back i.e.,
>
>* /gluster_bricks/engine/engine/
>* /gluster_bricks/data/data/
>* /gluster_bricks/vmstore/vmstore/
> but it is not yet recovered.
>
> =
> [root@node2 ~]# gluster volume status
> Status of volume: data
> Gluster process TCP Port  RDMA Port
> Online  Pid
>
> --
> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>1
> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>N/A
> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>4303
> Self-heal Daemon on localhost   N/A   N/A
> Y   23976
> Self-heal Daemon on *.*.*.1  N/A   N/AY
>27838
> Self-heal Daemon on *.*.*.3  N/A   N/AY
>27424
>
> Task Status of Volume data
>
> --
> There are no active volume tasks
>
> Status of volume: engine
> Gluster process TCP Port  RDMA Port
> Online  Pid
>
> --
> Brick *.*.*.1:/gluster_bricks/engine/eng
> ine 49153 0
> Y   7
> Brick *.*.*.2:/gluster_bricks/engine/eng
> ine N/A   N/A
> N   N/A
> Brick *.*.*.3:/gluster_bricks/engine/eng
> ine 49153 0
> Y   4314
> Self-heal Daemon on localhost   N/A   N/A
> Y   23976
> Self-heal Daemon on *.*.*.3  N/A   N/AY
>27424
> Self-heal Daemon on *.*.*.1  N/A   N/AY
>27838
>
> Task Status of Volume e

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Sahina Bose]

On Tue, Nov 27, 2018 at 3:45 PM Kaustav Majumder 
wrote:

> I am not sure why ovirt is not showing any volume.
> Sahina, is this a bug?
>

Check if gluster service is enabled on the cluster.
The volumes are managed only if this is true


> On Tue, Nov 27, 2018 at 3:10 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Hello Kaustav,
>>
>> That's weird, I never saw any volumes under the storage tab since
>> installation. I am using HC setup deployed using cockpit console.
>>
>> https://imgur.com/a/nH9rzK8
>>
>> Did I miss something?
>>
>>
>> On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder 
>> wrote:
>>
>>> Click on volume for which you want to reset the brick-> under bricks tab
>>> select the brick you wan to reset -> once you do you will see the 'Reset
>>> Brick' option is active.
>>> Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png
>>>
>>> On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
>>> abhishek.sahni1...@gmail.com> wrote:
>>>
 Thanks Sahina for your response, I am not able to find it on UI, please
 help me to navigate? and yes I am using oVirt 4.2.6.4-1.

 On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose  wrote:

>
>
> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Hello Team,
>>
>> We are running a setup of 3-way replica HC gluster setup configured
>> during the initial deployment from the cockpit console using ansible.
>>
>> NODE1
>>   - /dev/sda   (OS)
>>   - /dev/sdb   ( Gluster Bricks )
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>>
>> NODE2 and NODE3 with a similar setup.
>>
>> There is a mishap that /dev/sdb on NODE2 totally got crashed and now
>> there is nothing inside. However, I have created similar directories 
>> after
>> mounting it back i.e.,
>>
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>> but it is not yet recovered.
>>
>> =
>> [root@node2 ~]# gluster volume status
>> Status of volume: data
>> Gluster process TCP Port  RDMA Port
>> Online  Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>>  1
>> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>>  N/A
>> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>>  4303
>> Self-heal Daemon on localhost   N/A   N/AY
>>23976
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>>
>> Task Status of Volume data
>>
>> --
>> There are no active volume tasks
>>
>> Status of volume: engine
>> Gluster process TCP Port  RDMA Port
>> Online  Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/engine/eng
>> ine 49153 0  Y
>>7
>> Brick *.*.*.2:/gluster_bricks/engine/eng
>> ine N/A   N/AN
>>N/A
>> Brick *.*.*.3:/gluster_bricks/engine/eng
>> ine 49153 0  Y
>>4314
>> Self-heal Daemon on localhost   N/A   N/AY
>>23976
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>>
>> Task Status of Volume engine
>>
>> --
>> There are no active volume tasks
>>
>> Status of volume: vmstore
>> Gluster process TCP Port  RDMA Port
>> Online  Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/vmstore/vm
>> store   49154 0  Y
>>21603
>> Brick *.*.*.2:/gluster_bricks/vmstore/vm
>> store   N/A   N/AN
>>N/A
>> Brick *.*.*.3:/gluster_bricks/vmstore/vm
>> store   49154 0  Y
>>26845
>> Self-heal Daemon on localhost   N/A   N/AY
>>23976
>> Self-heal Daemon on *.*.*.3  N/A 

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Kaustav Majumder]

I am not sure why ovirt is not showing any volume.
Sahina, is this a bug?

On Tue, Nov 27, 2018 at 3:10 PM Abhishek Sahni 
wrote:

> Hello Kaustav,
>
> That's weird, I never saw any volumes under the storage tab since
> installation. I am using HC setup deployed using cockpit console.
>
> https://imgur.com/a/nH9rzK8
>
> Did I miss something?
>
>
> On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder 
> wrote:
>
>> Click on volume for which you want to reset the brick-> under bricks tab
>> select the brick you wan to reset -> once you do you will see the 'Reset
>> Brick' option is active.
>> Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png
>>
>> On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
>> abhishek.sahni1...@gmail.com> wrote:
>>
>>> Thanks Sahina for your response, I am not able to find it on UI, please
>>> help me to navigate? and yes I am using oVirt 4.2.6.4-1.
>>>
>>> On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose  wrote:
>>>


 On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
 abhishek.sahni1...@gmail.com> wrote:

> Hello Team,
>
> We are running a setup of 3-way replica HC gluster setup configured
> during the initial deployment from the cockpit console using ansible.
>
> NODE1
>   - /dev/sda   (OS)
>   - /dev/sdb   ( Gluster Bricks )
>* /gluster_bricks/engine/engine/
>* /gluster_bricks/data/data/
>* /gluster_bricks/vmstore/vmstore/
>
> NODE2 and NODE3 with a similar setup.
>
> There is a mishap that /dev/sdb on NODE2 totally got crashed and now
> there is nothing inside. However, I have created similar directories after
> mounting it back i.e.,
>
>* /gluster_bricks/engine/engine/
>* /gluster_bricks/data/data/
>* /gluster_bricks/vmstore/vmstore/
> but it is not yet recovered.
>
> =
> [root@node2 ~]# gluster volume status
> Status of volume: data
> Gluster process TCP Port  RDMA Port
> Online  Pid
>
> --
> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>  1
> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>  N/A
> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>  4303
> Self-heal Daemon on localhost   N/A   N/AY
>23976
> Self-heal Daemon on *.*.*.1  N/A   N/AY
>  27838
> Self-heal Daemon on *.*.*.3  N/A   N/AY
>  27424
>
> Task Status of Volume data
>
> --
> There are no active volume tasks
>
> Status of volume: engine
> Gluster process TCP Port  RDMA Port
> Online  Pid
>
> --
> Brick *.*.*.1:/gluster_bricks/engine/eng
> ine 49153 0  Y
>7
> Brick *.*.*.2:/gluster_bricks/engine/eng
> ine N/A   N/AN
>N/A
> Brick *.*.*.3:/gluster_bricks/engine/eng
> ine 49153 0  Y
>4314
> Self-heal Daemon on localhost   N/A   N/AY
>23976
> Self-heal Daemon on *.*.*.3  N/A   N/AY
>  27424
> Self-heal Daemon on *.*.*.1  N/A   N/AY
>  27838
>
> Task Status of Volume engine
>
> --
> There are no active volume tasks
>
> Status of volume: vmstore
> Gluster process TCP Port  RDMA Port
> Online  Pid
>
> --
> Brick *.*.*.1:/gluster_bricks/vmstore/vm
> store   49154 0  Y
>21603
> Brick *.*.*.2:/gluster_bricks/vmstore/vm
> store   N/A   N/AN
>N/A
> Brick *.*.*.3:/gluster_bricks/vmstore/vm
> store   49154 0  Y
>26845
> Self-heal Daemon on localhost   N/A   N/AY
>23976
> Self-heal Daemon on *.*.*.3  N/A   N/AY
>  27424
> Self-heal Daemon on *.*.*.1  N/A   N/AY
>  27838
>
> Task Status of Volume vmstore
>
> --
> There are no active volume tasks
> 

[ovirt-users] Re: AffinityGroup API

[Ondra Machacek]

Can you please share the script? And also what's the permission of the
user you are executing the script.

When see error 'User is not authorized to perform the action', we print
in engine.log, what's exactly wrong meaning we print what permissions
the user is missing in order to execute that action. So it may help you
find out what's wrong as well.

On 11/26/18 5:35 PM, Schreuders, Cliffe wrote:

Yes, the related issue we came across was that when using the Ruby gem,
assigning a VM to an Affinity Group raises an exception that states the
User is not authorized to perform the action; however, using the same
account works fine from the Admin portal and carrying out the exact same
steps via the Python SDK works as expected. The end result is that we
ended up calling a Python script from our Ruby code just to set the
affinity group.

Thanks, Paul.

On 26/11/2018 12:11, Staniforth, Paul wrote:

Hi Andrej

I believe they are using 4.2.5 they get a permission error although they can 
use the python SDK with the same account.

Paul S.

From: Ondra Machacek 
Sent: 26 November 2018 11:41
To: Staniforth, Paul
Cc: Andrej Krejcir; users
Subject: Re: [ovirt-users] AffinityGroup API

What version of the SDK do you use?
I can see it's supported in latest version.

On 11/26/18 11:13 AM, Andrej Krejcir wrote:

Hi,

I don't know much about ruby SDK. I think the SDKs for various languages
are generated from the API specification.

Ondra, is this a bug in ruby SDK?


Andrej

On Fri, 23 Nov 2018 at 18:06, Staniforth, Paul <
p.stanifo...@leedsbeckett.ac.uk> wrote:


Hello Andrej,

Also the Affinity Groups apparently aren't  available
in the Ruby SDK should I add this to the bug report?


Thanks,

Paul S.
--
*From:* Andrej Krejcir 
*Sent:* 21 November 2018 13:32
*To:* Staniforth, Paul
*Cc:* users
*Subject:* Re: [ovirt-users] AffinityGroup API

Hi,

Yes, the AffinityGroupHosts is missing. Can you please open a bug[1] so we
can add it?

As a workaround, the hosts can be modified by PUT request to the
AffinityGroup endpoint directly, for example:

PUT /ovirt-engine/api/clusters/1234/affinitygroups/5678

   
   
   
   


However, this will replace all hosts in the affinity group with the hosts
listed.


Best regards,
Andrej


[1] - https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine

On Wed, 21 Nov 2018 at 13:26,  wrote:


Hello,
 When using the API to update an AffinityGroup there is a
AffinityGroupVm and AffinityGroupVms so I can add or remove VMs but there
is no AffinityGroupHost or AffinityGroupHosts, therefore I can't add or
remove hosts.

Thanks,
Paul S.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BUMDJ34JRLDHSE6CPUVZOD3I2TI2YBQD/


To view the terms under which this email is distributed, please go to:-
http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html



To view the terms under which this email is distributed, please go to:-
http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/IZEOPB3SYNBYEE6B7KKBHA6E24IOZ7HY/

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Abhishek Sahni]

Hello Kaustav,

That's weird, I never saw any volumes under the storage tab since
installation. I am using HC setup deployed using cockpit console.

https://imgur.com/a/nH9rzK8

Did I miss something?


On Tue, Nov 27, 2018 at 2:50 PM Kaustav Majumder 
wrote:

> Click on volume for which you want to reset the brick-> under bricks tab
> select the brick you wan to reset -> once you do you will see the 'Reset
> Brick' option is active.
> Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png
>
> On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Thanks Sahina for your response, I am not able to find it on UI, please
>> help me to navigate? and yes I am using oVirt 4.2.6.4-1.
>>
>> On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose  wrote:
>>
>>>
>>>
>>> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
>>> abhishek.sahni1...@gmail.com> wrote:
>>>
 Hello Team,

 We are running a setup of 3-way replica HC gluster setup configured
 during the initial deployment from the cockpit console using ansible.

 NODE1
   - /dev/sda   (OS)
   - /dev/sdb   ( Gluster Bricks )
* /gluster_bricks/engine/engine/
* /gluster_bricks/data/data/
* /gluster_bricks/vmstore/vmstore/

 NODE2 and NODE3 with a similar setup.

 There is a mishap that /dev/sdb on NODE2 totally got crashed and now
 there is nothing inside. However, I have created similar directories after
 mounting it back i.e.,

* /gluster_bricks/engine/engine/
* /gluster_bricks/data/data/
* /gluster_bricks/vmstore/vmstore/
 but it is not yet recovered.

 =
 [root@node2 ~]# gluster volume status
 Status of volume: data
 Gluster process TCP Port  RDMA Port
 Online  Pid

 --
 Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
  1
 Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
  N/A
 Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
  4303
 Self-heal Daemon on localhost   N/A   N/AY
  23976
 Self-heal Daemon on *.*.*.1  N/A   N/AY
  27838
 Self-heal Daemon on *.*.*.3  N/A   N/AY
  27424

 Task Status of Volume data

 --
 There are no active volume tasks

 Status of volume: engine
 Gluster process TCP Port  RDMA Port
 Online  Pid

 --
 Brick *.*.*.1:/gluster_bricks/engine/eng
 ine 49153 0  Y
  7
 Brick *.*.*.2:/gluster_bricks/engine/eng
 ine N/A   N/AN
  N/A
 Brick *.*.*.3:/gluster_bricks/engine/eng
 ine 49153 0  Y
  4314
 Self-heal Daemon on localhost   N/A   N/AY
  23976
 Self-heal Daemon on *.*.*.3  N/A   N/AY
  27424
 Self-heal Daemon on *.*.*.1  N/A   N/AY
  27838

 Task Status of Volume engine

 --
 There are no active volume tasks

 Status of volume: vmstore
 Gluster process TCP Port  RDMA Port
 Online  Pid

 --
 Brick *.*.*.1:/gluster_bricks/vmstore/vm
 store   49154 0  Y
  21603
 Brick *.*.*.2:/gluster_bricks/vmstore/vm
 store   N/A   N/AN
  N/A
 Brick *.*.*.3:/gluster_bricks/vmstore/vm
 store   49154 0  Y
  26845
 Self-heal Daemon on localhost   N/A   N/AY
  23976
 Self-heal Daemon on *.*.*.3  N/A   N/AY
  27424
 Self-heal Daemon on *.*.*.1  N/A   N/AY
  27838

 Task Status of Volume vmstore

 --
 There are no active volume tasks
 =


 Can someone please suggest the steps to recover the setup?

 I have tried the below workaround but it doesn't help.


 https://lists.gluster.org/pipermail/gluster-users/2013-November/015079.html

>>>
>>>  You can reset the bri

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Kaustav Majumder]

Click on volume for which you want to reset the brick-> under bricks tab
select the brick you wan to reset -> once you do you will see the 'Reset
Brick' option is active.
Attached is a screenshot -> https://i.imgur.com/QUMSrzt.png

On Tue, Nov 27, 2018 at 2:43 PM Abhishek Sahni 
wrote:

> Thanks Sahina for your response, I am not able to find it on UI, please
> help me to navigate? and yes I am using oVirt 4.2.6.4-1.
>
> On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose  wrote:
>
>>
>>
>> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
>> abhishek.sahni1...@gmail.com> wrote:
>>
>>> Hello Team,
>>>
>>> We are running a setup of 3-way replica HC gluster setup configured
>>> during the initial deployment from the cockpit console using ansible.
>>>
>>> NODE1
>>>   - /dev/sda   (OS)
>>>   - /dev/sdb   ( Gluster Bricks )
>>>* /gluster_bricks/engine/engine/
>>>* /gluster_bricks/data/data/
>>>* /gluster_bricks/vmstore/vmstore/
>>>
>>> NODE2 and NODE3 with a similar setup.
>>>
>>> There is a mishap that /dev/sdb on NODE2 totally got crashed and now
>>> there is nothing inside. However, I have created similar directories after
>>> mounting it back i.e.,
>>>
>>>* /gluster_bricks/engine/engine/
>>>* /gluster_bricks/data/data/
>>>* /gluster_bricks/vmstore/vmstore/
>>> but it is not yet recovered.
>>>
>>> =
>>> [root@node2 ~]# gluster volume status
>>> Status of volume: data
>>> Gluster process TCP Port  RDMA Port  Online
>>> Pid
>>>
>>> --
>>> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>>>  1
>>> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>>>  N/A
>>> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>>>  4303
>>> Self-heal Daemon on localhost   N/A   N/AY
>>>  23976
>>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>>  27838
>>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>>  27424
>>>
>>> Task Status of Volume data
>>>
>>> --
>>> There are no active volume tasks
>>>
>>> Status of volume: engine
>>> Gluster process TCP Port  RDMA Port  Online
>>> Pid
>>>
>>> --
>>> Brick *.*.*.1:/gluster_bricks/engine/eng
>>> ine 49153 0  Y
>>>  7
>>> Brick *.*.*.2:/gluster_bricks/engine/eng
>>> ine N/A   N/AN
>>>  N/A
>>> Brick *.*.*.3:/gluster_bricks/engine/eng
>>> ine 49153 0  Y
>>>  4314
>>> Self-heal Daemon on localhost   N/A   N/AY
>>>  23976
>>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>>  27424
>>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>>  27838
>>>
>>> Task Status of Volume engine
>>>
>>> --
>>> There are no active volume tasks
>>>
>>> Status of volume: vmstore
>>> Gluster process TCP Port  RDMA Port  Online
>>> Pid
>>>
>>> --
>>> Brick *.*.*.1:/gluster_bricks/vmstore/vm
>>> store   49154 0  Y
>>>  21603
>>> Brick *.*.*.2:/gluster_bricks/vmstore/vm
>>> store   N/A   N/AN
>>>  N/A
>>> Brick *.*.*.3:/gluster_bricks/vmstore/vm
>>> store   49154 0  Y
>>>  26845
>>> Self-heal Daemon on localhost   N/A   N/AY
>>>  23976
>>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>>  27424
>>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>>  27838
>>>
>>> Task Status of Volume vmstore
>>>
>>> --
>>> There are no active volume tasks
>>> =
>>>
>>>
>>> Can someone please suggest the steps to recover the setup?
>>>
>>> I have tried the below workaround but it doesn't help.
>>>
>>>
>>> https://lists.gluster.org/pipermail/gluster-users/2013-November/015079.html
>>>
>>
>>  You can reset the brick - if you're on oVirt 4.2.x, there's a UI option
>> in the bricks subtab to do this.
>>
>>
>>>
>>> --
>>>
>>> ABHISHEK SAHNI
>>> Mob : +91-990-701-5143
>>>
>>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovi

[ovirt-users] Re: Recover accidentally deleted gluster node having bricks ( Engine, Data and Vmstore)

[Abhishek Sahni]

Thanks Sahina for your response, I am not able to find it on UI, please
help me to navigate? and yes I am using oVirt 4.2.6.4-1.

On Tue, Nov 27, 2018 at 12:55 PM Sahina Bose  wrote:

>
>
> On Tue, Nov 20, 2018 at 5:56 PM Abhishek Sahni <
> abhishek.sahni1...@gmail.com> wrote:
>
>> Hello Team,
>>
>> We are running a setup of 3-way replica HC gluster setup configured
>> during the initial deployment from the cockpit console using ansible.
>>
>> NODE1
>>   - /dev/sda   (OS)
>>   - /dev/sdb   ( Gluster Bricks )
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>>
>> NODE2 and NODE3 with a similar setup.
>>
>> There is a mishap that /dev/sdb on NODE2 totally got crashed and now
>> there is nothing inside. However, I have created similar directories after
>> mounting it back i.e.,
>>
>>* /gluster_bricks/engine/engine/
>>* /gluster_bricks/data/data/
>>* /gluster_bricks/vmstore/vmstore/
>> but it is not yet recovered.
>>
>> =
>> [root@node2 ~]# gluster volume status
>> Status of volume: data
>> Gluster process TCP Port  RDMA Port  Online
>> Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/data/data  49152 0  Y
>>  1
>> Brick *.*.*.2:/gluster_bricks/data/data  N/A   N/AN
>>  N/A
>> Brick *.*.*.3:/gluster_bricks/data/data  49152 0  Y
>>  4303
>> Self-heal Daemon on localhost   N/A   N/AY
>>  23976
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>>
>> Task Status of Volume data
>>
>> --
>> There are no active volume tasks
>>
>> Status of volume: engine
>> Gluster process TCP Port  RDMA Port  Online
>> Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/engine/eng
>> ine 49153 0  Y
>>  7
>> Brick *.*.*.2:/gluster_bricks/engine/eng
>> ine N/A   N/AN
>>  N/A
>> Brick *.*.*.3:/gluster_bricks/engine/eng
>> ine 49153 0  Y
>>  4314
>> Self-heal Daemon on localhost   N/A   N/AY
>>  23976
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>>
>> Task Status of Volume engine
>>
>> --
>> There are no active volume tasks
>>
>> Status of volume: vmstore
>> Gluster process TCP Port  RDMA Port  Online
>> Pid
>>
>> --
>> Brick *.*.*.1:/gluster_bricks/vmstore/vm
>> store   49154 0  Y
>>  21603
>> Brick *.*.*.2:/gluster_bricks/vmstore/vm
>> store   N/A   N/AN
>>  N/A
>> Brick *.*.*.3:/gluster_bricks/vmstore/vm
>> store   49154 0  Y
>>  26845
>> Self-heal Daemon on localhost   N/A   N/AY
>>  23976
>> Self-heal Daemon on *.*.*.3  N/A   N/AY
>>  27424
>> Self-heal Daemon on *.*.*.1  N/A   N/AY
>>  27838
>>
>> Task Status of Volume vmstore
>>
>> --
>> There are no active volume tasks
>> =
>>
>>
>> Can someone please suggest the steps to recover the setup?
>>
>> I have tried the below workaround but it doesn't help.
>>
>>
>> https://lists.gluster.org/pipermail/gluster-users/2013-November/015079.html
>>
>
>  You can reset the brick - if you're on oVirt 4.2.x, there's a UI option
> in the bricks subtab to do this.
>
>
>>
>> --
>>
>> ABHISHEK SAHNI
>> Mob : +91-990-701-5143
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WFYUBA4DPHOSAZHGCRV2AAT4JWL4LWWV/
>>
>

-- 

ABHISHEK SAHNI
Mob : +91-990-701-5143
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of C

[ovirt-users] extract nested attribute from a href link with ansible ovirt_vm_facts

[Nathanaël Blanchet]

Hello

I'd like to extract all vms which have the lease optionnal attribute 
and  display the name of the storage domain of that lease.


I managed to get that dict:

    "lease": {
    "storage_domain": {
    "href": 
"/ovirt-engine/api/storagedomains/0dc2941a-bdc2-4ce4-8ad7-43fa9c944f88",

    "id": "0dc2941a-bdc2-4ce4-8ad7-43fa9c944f88"
    }

but how can I get the name of the storage instead of its id?

thank you for your help

--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SGM7QXWNEPKE4X5EFKCYCJ4TK6W62JG6/

[ovirt-users] Re: Upgrade 4.0 to 4.1: Global Maintenance Mode not recognized

[Simone Tiraboschi]

On Tue, Nov 27, 2018 at 8:45 AM Edward Haas  wrote:

> Where did you managed to get a 4.1 version from?
> I would recommend using a supported version (4.2).
>
> On Mon, Nov 26, 2018 at 1:20 PM gregor  wrote:
>
>> During installation the firewall was enable or changed therefore I get
>> an "NoRouteToHostException" from the Engine to the Host.
>> After disabling the firewall on the Host the Data Center and VM's are up
>> and running.
>>
>> regards
>> gregor
>>
>> Am 26.11.18 um 07:50 schrieb gregor:
>> > The Engine is up but the host stucks in NonResponsive.
>> >
>> > The Webinterface stuck in "hanlding non respsonsive host". "Validating"
>> > is green and "Executing" is spinning.
>> >
>> > Can anybody help?
>> > I found no errors in the logs under /var/log/ovirt-hosted-engine-ha and
>> > journalclt
>> >
>> > regards
>> > gregor
>> >
>> >
>> > Am 26.11.18 um 07:35 schrieb gregor:
>> >> I was able to change the maintenance state in the database to finish
>> the
>> >> upgrade with engine-setup.
>> >>
>> >> these are the lines:
>> >>
>> >> select vds_id,ha_global_maintenance from vds_statistics where vds_id =
>> >> '706599d5-2dbc-400c-b9da-5b5906de6dbd';
>> >> update vds_statistics set ha_global_maintenance = 't' where vds_id =
>> >> '706599d5-2dbc-400c-b9da-5b5906de6dbd';
>> >>
>> >> Now it's time to wait if the host and engine can reboot and start the
>> vm's.
>> >>
>> >> regards
>> >> gregor
>> >>
>> >> Am 26.11.18 um 06:07 schrieb gregor:
>> >>> Hello,
>> >>>
>> >>> I upgraded one host from 4.0 to 4.1 without problems. Now I have a
>> >>> problem with another host, in another network, where the Global
>> >>> Maintenance mode is not recognized by engine-setup.
>>
>> >>> Is there a way to force the setup or set the maintenance mode inside
>> the
>> >>> database?
>>
>>
Global maintenance is an hosted-engine specific concept.
Are you using hosted-engine?
Did you really set the global maintenace?



> >>> One problem can be that an the host was accidentally upgraded to 4.1
>> >>> before I upgraded the engine.
>> >>>
>> >>> kind regards
>> >>> gregor
>> >>> ___
>> >>> Users mailing list -- users@ovirt.org
>> >>> To unsubscribe send an email to users-le...@ovirt.org
>> >>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> >>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> >>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/RQOX7YHHW3GTYEOP5YMG6NF2OD4BHUC7/
>> >>>
>> >> ___
>> >> Users mailing list -- users@ovirt.org
>> >> To unsubscribe send an email to users-le...@ovirt.org
>> >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> >> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> >> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TLXT24MHJHSPQDI7ENVVJO2WVOBHHLB4/
>> >>
>> > ___
>> > Users mailing list -- users@ovirt.org
>> > To unsubscribe send an email to users-le...@ovirt.org
>> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> > oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> > List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7M2HF3S6UHCLR7QK2AU2GZBN7DGPEHBF/
>> >
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/P2EVD5IRRG7YUXD36KKJ74YXFXMKX4RG/
>>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZMOAUEFF33KNJSCMCPCJAZGWBNC267WP/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LRNSH5NKJR2EB6JOY6PJXTCHPBSLZ6G6/