August 2023 - Users - Ovirt List Archives

engine-config -s UserSessionTimeOutInterval=X problem

by marek

ovirt 4.5.4, standalone engine, centos 8 stream [root@ovirt ~]# engine-config -g UserSessionTimeOutInterval Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false UserSessionTimeOutInterval: 30 version: general [root@ovirt ~]# engine-config -s UserSessionTimeOutInterval=60 Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false Cannot set value 60 to key UserSessionTimeOutInterval. any ideas where is the problem? Marek

1 year, 7 months

5
6
0 / 0

Unable to upload or download iso via admin portal

by Igor Filipovic

Hi, I'm having a trouble on fresh 4.4.10.7 installation (on oracle linux), I'm not able to upload or download any file using storage domain upload image function. I've imported CA certificate and have tried on several browsers (firefow, chrome,edge), on different computers (and browsers are green - claiming that I'm securely connected), but I'm always getting error regarding CA certificate when I test connection, or when I try to upload ISO image. I've tried to upload ISO image via cli commands (upload_disk.py), and that scenario was successful, however this method It is not very convenient for my co-workers. I have 5 physical hosts, one is dedicated to run ovirt-engine, and other 4 are kvm hypervisors. When I try to upload ISO this is what engine.log logs: 2023-04-08 11:00:28,339+02 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-2) [f6b62add-0a0c-45ee-a985-a76171843382] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: 1eb97088-b805-4616-af55-0ac9d1d7dfbe Type: SystemAction group CREATE_DISK with role type USER 2023-04-08 11:00:28,340+02 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-2) [f6b62add-0a0c-45ee-a985-a76171843382] Updating image transfer a78b18c5-e395-4c29-aa5c-15ffff8a1cb6 (image 4f758325-ac11-4071-a9fa-d180425e8604) phase to Paused by System (message: 'Sent 0MB') 2023-04-08 11:00:28,363+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-2) [f6b62add-0a0c-45ee-a985-a76171843382] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,062), Unable to upload image to disk 4f758325-ac11-4071-a9fa-d180425e8604 due to a network error. Ensure ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://engine-dr.somedomain/ovirt-engine/services/pki-resource?resource=... 2023-04-08 11:00:28,363+02 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-2) [f6b62add-0a0c-45ee-a985-a76171843382] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: 1eb97088-b805-4616-af55-0ac9d1d7dfbe Type: SystemAction group CREATE_DISK with role type USER Can you please point me in some direction to try to fix this? Thanks, and best regards Igor

1 year, 7 months

4
4
1 / 0

Node Intel I7 13700 Raptor Lake

by sarpi17＠gmail.com

Hello, how are you? I have an Ovirt Engine Version 4.4.10 installed. I installed Ovirt Node on a computer with an Intel I7 13700 Raptor Lake processor. When I want to link that node with the Engine I get the error that the CPU family is not correct, I tried with several of those that appear, but none is correct and Raptor Lake does not appear. What can I do? Thanks

1 year, 7 months

1
0
0 / 0

oVirt 4.5.5 VDSM error

by cmicarelli＠fdmservices.it

HI guys, I've installed a new ovirt stack 4.5 and everything works fine. After the upgrade to 4.5.5 VDSM doesn't work correctly --------------------------------------------------------------------------------------- [root@lce8cdpnode2 opt]# systemctl status vdsmd.service ● vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2023-08-22 14:34:44 CEST; 19min ago Process: 3332 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS) Main PID: 3413 (vdsmd) Tasks: 56 (limit: 823896) Memory: 312.3M CGroup: /system.slice/vdsmd.service ├─3413 /usr/bin/python3 /usr/libexec/vdsm/vdsmd └─4704 /usr/libexec/ioprocess --read-pipe-fd 59 --write-pipe-fd 58 --max-threads 10 --max-queued-requests 10 Aug 22 14:34:44 lce8cdpnode2..local vdsmd_init_common.sh[3332]: vdsm: Running test_space Aug 22 14:34:44 lce8cdpnode2..local vdsmd_init_common.sh[3332]: vdsm: Running test_lo Aug 22 14:34:44 lce8cdpnode2..local systemd[1]: Started Virtual Desktop Server Manager. Aug 22 14:34:47 lce8cdpnode2..local vdsm[3413]: WARN MOM not available. Error: [Errno 2] No such file or directory Aug 22 14:34:47 lce8cdpnode2..local vdsm[3413]: WARN MOM not available, KSM stats will be missing. Error: Aug 22 14:41:30 lce8cdpnode2..local vdsm[3413]: WARN unhandled write event Aug 22 14:41:40 lce8cdpnode2..local vdsm[3413]: WARN unhandled write event Aug 22 14:41:43 lce8cdpnode2..local vdsm[3413]: ERROR Error getting managedvolume connector info: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/vdsm/host/caps.py", line 161, in get caps["connector_info"] = managedvolume.connector_info() File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 63, in wrapper return func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 78, in connector_info return run_helper("connector_info") File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 184, in run_helper sub_cmd, cmd_input=cmd_input) File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 38, in __call__ return callMethod() File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 36, in <lambda> **kwargs) File "<string>", line 2, in managedvolume_run_helper File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod raise convert_to_error(kind, result) vdsm.storage.exception.ManagedVolumeHelperFailed: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> Aug 22 14:41:43 lce8cdpnode2..local vdsm[3413]: ERROR Error getting managedvolume connector info: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/vdsm/host/caps.py", line 161, in get caps["connector_info"] = managedvolume.connector_info() File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 63, in wrapper return func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 78, in connector_info return run_helper("connector_info") File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 184, in run_helper sub_cmd, cmd_input=cmd_input) File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 38, in __call__ return callMethod() File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 36, in <lambda> **kwargs) File "<string>", line 2, in managedvolume_run_helper File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod raise convert_to_error(kind, result) vdsm.storage.exception.ManagedVolumeHelperFailed: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> Aug 22 14:41:45 lce8cdpnode2..local vdsm[3413]: ERROR Error getting managedvolume connector info: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/vdsm/host/caps.py", line 161, in get caps["connector_info"] = managedvolume.connector_info() File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 63, in wrapper return func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 78, in connector_info return run_helper("connector_info") File "/usr/lib/python3.6/site-packages/vdsm/storage/managedvolume.py", line 184, in run_helper sub_cmd, cmd_input=cmd_input) File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 38, in __call__ return callMethod() File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 36, in <lambda> **kwargs) File "<string>", line 2, in managedvolume_run_helper File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod raise convert_to_error(kind, result) vdsm.storage.exception.ManagedVolumeHelperFailed: Managed Volume Helper failed.: ('Error executing helper: Command [\'/usr/bin/python3\', \'/usr/libexec/vdsm/managedvolume-helper\', \'connector_info\'] failed with rc> lines 7-72/72 (END) ------------------------------ Someone have had same problem Regards C

1 year, 7 months

2
1
0 / 0

ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials

by cmicarelli＠fdmservices.it

Hi Guys, I'm tried to install ovirt 4.5 on centos 8 stream and everytime file with this error ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials Someone could help me? Regrards

1 year, 7 months

2
2
0 / 0

Re: Active Active Stretched Node cluster not working as expected.

by Gianluca Cecchi

On Tue, Aug 22, 2023 at 8:52 AM Gaurang Patel <gaurang.patel(a)allotgroup.com> wrote: > Suggest any other solution if any. > > > Your subject says "not working as expected" and you refer to the RHV DR guides. My comment is that in my opinion HCI architecture is not expected to work / be supported for active active DR scenarios as described there. But you can follow general GlusterFS indications for solving split brain scenarios, like this one: https://docs.gluster.org/en/main/Troubleshooting/resolving-splitbrain/ and / or submit your question also to GlusterFS mailing lists or see if here you find useful information for supported configurations, quorum setup to prevent split brain conditions, ecc: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5... https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5... HIH, Gianluca

1 year, 7 months

1
0
0 / 0

Active Active Stretched Node cluster not working as expected.

by gaurang.patel＠allotgroup.com

Hi, i have a Six node Stretched HCI cluster with 2 x 3 =6 distributed Replicated bricks, want to achieve Active - Active Disaster Recovery , if my three hosts in DC power Down or Failed my DR Site Three node should take care of running virtual machines. During Split-brain scenario Ovirt-Hosted-Engine VM goes in PAUSE mode and not restarting on DR hosts and waited for long time, due to this my all production VMs are not restarting on DR Site. please guide to achieve Active-Active Disaster Recovery with 6 node stretched cluster. i referred document hosted official site but did not get success, it would be great help of anybody can extend help or guide me for the same. https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/... My Setup insight. root@phnode06 /]# gluster volume status Status of volume: data Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 172.16.1.1:/gluster_bricks/data/data 58744 0 Y 1746524 Brick 172.16.1.2:/gluster_bricks/data/data 58732 0 Y 2933385 Brick 172.16.1.3:/gluster_bricks/data/data 60442 0 Y 6158 Brick phnode04..local:/gluster_bricks /data/data1 51661 0 Y 5905 Brick phnode05..local:/gluster_bricks /data/data1 52177 0 Y 6178 Brick phnode06..local:/gluster_bricks /data/data1 59910 0 Y 6208 Self-heal Daemon on localhost N/A N/A Y 5878 Self-heal Daemon on phnode03..local N/A N/A Y 6133 Self-heal Daemon on gluster01..local N/A N/A Y 6072 Self-heal Daemon on phnode05..local N/A N/A Y 5751 Self-heal Daemon on gluster02..local N/A N/A Y 5746 Self-heal Daemon on phnode04..local N/A N/A Y 4734 Task Status of Volume data ------------------------------------------------------------------------------ Task : Rebalance ID : 1c30fbfa-2707-457e-b844-ccaf2e07aa7f Status : completed Status of volume: engine Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 172.16.1.1:/gluster_bricks/engine/eng ine 53723 0 Y 1746535 Brick 172.16.1.2:/gluster_bricks/engine/eng ine 49937 0 Y 2933395 Brick 172.16.1.3:/gluster_bricks/engine/eng ine 53370 0 Y 6171 Brick phnode04..local:/gluster_bricks /engine/engine1 52024 0 Y 5916 Brick phnode05..local:/gluster_bricks /engine/engine1 51785 0 Y 6189 Brick phnode06..local:/gluster_bricks /engine/engine1 55443 0 Y 6221 Self-heal Daemon on localhost N/A N/A Y 5878 Self-heal Daemon on gluster02..local N/A N/A Y 5746 Self-heal Daemon on gluster01..local N/A N/A Y 6072 Self-heal Daemon on phnode05..local N/A N/A Y 5751 Self-heal Daemon on phnode03..local N/A N/A Y 6133 Self-heal Daemon on phnode04..local N/A N/A Y 4734 Task Status of Volume engine ------------------------------------------------------------------------------ Task : Rebalance ID : 21304de4-b100-4860-b408-5e58103080a2 Status : completed Status of volume: vmstore Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 172.16.1.1:/gluster_bricks/vmstore/vm store 50244 0 Y 1746546 Brick 172.16.1.2:/gluster_bricks/vmstore/vm store 51607 0 Y 2933405 Brick 172.16.1.3:/gluster_bricks/vmstore/vm store 49835 0 Y 6182 Brick phnode04..local:/gluster_bricks /vmstore/vmstore1 54098 0 Y 5927 Brick phnode05..local:/gluster_bricks /vmstore/vmstore1 56565 0 Y 6200 Brick phnode06..local:/gluster_bricks /vmstore/vmstore1 58653 0 Y 1853456 Self-heal Daemon on localhost N/A N/A Y 5878 Self-heal Daemon on gluster02..local N/A N/A Y 5746 Self-heal Daemon on gluster01..local N/A N/A Y 6072 Self-heal Daemon on phnode05..local N/A N/A Y 5751 Self-heal Daemon on phnode03..local N/A N/A Y 6133 Self-heal Daemon on phnode04..local N/A N/A Y 4734 Task Status of Volume vmstore ------------------------------------------------------------------------------ Task : Rebalance ID : 7d1849f8-433a-43b1-93bc-d674a7b0aef3 Status : completed [root@phnode06 /]# hosted-engine --vm-status --== Host phnode01..local (id: 1) status ==-- Host ID : 1 Host timestamp : 9113939 Score : 3400 Engine status : {"vm": "up", "health": "good", "detail": "Up"} Hostname : phnode01..local Local maintenance : False stopped : False crc32 : 00979124 conf_on_shared_storage : True local_conf_timestamp : 9113939 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=9113939 (Sat Aug 19 14:39:41 2023) host-id=1 score=3400 vm_conf_refresh_time=9113939 (Sat Aug 19 14:39:41 2023) conf_on_shared_storage=True maintenance=False state=EngineUp stopped=False --== Host phnode03..local (id: 2) status ==-- Host ID : 2 Host timestamp : 405629 Score : 3400 Engine status : {"vm": "down", "health": "bad", "detail": "unknown", "reason": "vm not running on this host"} Hostname : phnode03..local Local maintenance : False stopped : False crc32 : 0b1c7489 conf_on_shared_storage : True local_conf_timestamp : 405630 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=405629 (Sat Aug 19 14:39:43 2023) host-id=2 score=3400 vm_conf_refresh_time=405630 (Sat Aug 19 14:39:43 2023) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host phnode02..local (id: 3) status ==-- Host ID : 3 Host timestamp : 9069311 Score : 3400 Engine status : {"vm": "down", "health": "bad", "detail": "unknown", "reason": "vm not running on this host"} Hostname : phnode02..local Local maintenance : False stopped : False crc32 : b84baa31 conf_on_shared_storage : True local_conf_timestamp : 9069311 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=9069311 (Sat Aug 19 14:39:41 2023) host-id=3 score=3400 vm_conf_refresh_time=9069311 (Sat Aug 19 14:39:41 2023) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host phnode04..local (id: 4) status ==-- Host ID : 4 Host timestamp : 1055893 Score : 3400 Engine status : {"vm": "down", "health": "bad", "detail": "unknown", "reason": "vm not running on this host"} Hostname : phnode04..local Local maintenance : False stopped : False crc32 : 58a9b84c conf_on_shared_storage : True local_conf_timestamp : 1055893 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=1055893 (Sat Aug 19 14:39:38 2023) host-id=4 score=3400 vm_conf_refresh_time=1055893 (Sat Aug 19 14:39:38 2023) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host phnode05..local (id: 5) status ==-- Host ID : 5 Host timestamp : 404187 Score : 3400 Engine status : {"vm": "down", "health": "bad", "detail": "unknown", "reason": "vm not running on this host"} Hostname : phnode05..local Local maintenance : False stopped : False crc32 : 48cf9186 conf_on_shared_storage : True local_conf_timestamp : 404187 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=404187 (Sat Aug 19 14:39:40 2023) host-id=5 score=3400 vm_conf_refresh_time=404187 (Sat Aug 19 14:39:40 2023) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host phnode06..local (id: 6) status ==-- Host ID : 6 Host timestamp : 1055902 Score : 3400 Engine status : {"vm": "down", "health": "bad", "detail": "unknown", "reason": "vm not running on this host"} Hostname : phnode06..local Local maintenance : False stopped : False crc32 : 913ff6c2 conf_on_shared_storage : True local_conf_timestamp : 1055902 Status up-to-date : True Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=1055902 (Sat Aug 19 14:39:48 2023) host-id=6 score=3400 vm_conf_refresh_time=1055902 (Sat Aug 19 14:39:48 2023) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False [root@phnode06 /]#

1 year, 7 months

3
2
0 / 0

Issue - Bonding 802.3ad

by Anthony Bustillos

Hello team, I have this warning when I tried, to configure two ports with boonding 802.3ad. Warning: Bond is in link aggregation mode (Mode 4 ) but no partner mac has been reported for it. At least one slave has a different aggregator id. how I can to solved this warning? best Regards

1 year, 7 months

2
2
1 / 0

How to use Python to manage each node in batches, because I want to send some scripts to nodes in batches

by ZiYi Liu

By default, find the management in engine-web and use ssh management to restart and stop the node node. Can I get the host's secret key or other login information to log in through Python, and then send some commands or scripts?

1 year, 7 months

4
4
0 / 0

Update path of hosted_storage domain

by francesco＠shellrent.com

Hello everyone, we have a self hosted engine environment (oVirt 4.4.5) that use a replica 2 + arbiter glusterfs. Those servers are both glusterfs nodes and oVirt node of the hosted engine. For an upgrade we followed this guide https://access.redhat.com/documentation/it-it/red_hat_hyperconverged_infr.... The planned upgrade was adding 2 new servers (node3 and node4) that would replace the existing ones. We added to oVirt cluster and the glusterfs pool the servers and moved the engine in those new hosts, without touching the underlay glusterfs configuration. After the step n° 18 ("Reboot the existing and replacement hosts.Wait until all hosts are available before continuing.") of the guide we tried to start the engine but we got error on the hosted_storage domain due to old path (the glusterfs mounted path was "node1" and the backupvolfile was "node2"). For avoiding corruption we updated the database with the correct path and mount options accordly with the new configuration edited in the file /etc/ovirt-hosted-engine/hosted-engine.conf (as written in the guide). If we try to detach the node1 brick everything stop working causing storage error. We noticed that reference of node1 is still present in the file /rhev/data-center/mnt/glusterSD/node1.ovirt.xyz:_engine/36c75f6e-d95d-48f4-9ceb-ad2895ab2123/dom_md/metadata, on both of new hosts (node3 and node4). I'll be more than glad to attach any log file needed for understanding what's going on, and thank you whoever will take time for helping me out :) Regards, Francesco

1 year, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Users August 2023