- Users - oVirt List Archives

Re: System unable to recover after a crash
by Strahil 13 Jul '19

13 Jul '19

Hi Carl, I'd recommend you to avoid DNS & DHCP unless you oVirt infra consistes of hundreds of servers. It is far more reliable to use static IPs + /etc/hosts . As you could 'ssh' to the engine, check the logs - there should be a clue why it failed. Most probably it's related to the DNS/IP used. I think the devs can tell their opinion on Monday. Best Regards, Strahil NikolovOn Jul 13, 2019 15:08, carl langlois <crl.langlois(a)gmail.com> wrote: > > Hi > Thanks for the info. There have been some progress with the situation. So to make the story as short as possible we are in a process of changing our range of IP addresse to 10.8.X.X to 10.16.X.X for all of the ovirt infra. This implies a new DHCP server, new switchs etc etc. For now we went back to our old IP address ranges because we were not able to stabilize the system. > > So the last status using our new range of addresses was that gluster was all fine, the hosted engine domaine was moutning okey. I suspect DNS table was not properly updated.. but i am not 100% sure. But if we tried to used the new range of adrreses everything seems to be fine except that the hosted-engine always fail the "liveliness check" after going up. I was not able to solve this situation so i went back to our previous DHCP server. > > So i am not sure what is missing for the hosted-engine to use the DHCP server. Is there any hardcode config in the hosted-egnine that need to be updated when chaging DHCP server(i.e new address with the same hostname, new gateway..) > > More info on the test i did with the new DHCP server -- > All node have name resolution working. I am able to ssh to the hosted-engine > > Any suggestions will be appreciated as i am out of idea for now. Do i need to redo some sort of setup in the engine to take into account the range of address/new gateway? There is also a LDAP server access configure in the engine for username mapping.. > Carl > > > > > On Sat, Jul 13, 2019 at 6:31 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >> >> Can you mount the volume manually at another location ? >> Also, have you done any changes to Gluster ? >> >> Please provide "gluster volume info engine" . I have noticed the following in your logs: option 'parallel-readdir' is not recognized >> >> Best Regards, >> Strahil Nikolov >> >> В петък, 12 юли 2019 г., 22:30:41 ч. Гринуич+3, carl langlois <crl.langlois(a)gmail.com> написа: >> >> >> Hi , >> >> I am in state where my system does not recover from a major failure. I have pinpoint the probleme to be that the hosted engine storage domain is not able to mount >> >> I have a glusterfs containing the storage domain. but when it attempt to mount glusterfs to /rhev/data-center/mnt/glusterSD/ovhost1:_engine i get >> >> +------------------------------------------------------------------------------+ >> [2019-07-12 19:19:44.063608] I [rpc-clnt.c:1986:rpc_clnt_reconfig] 0-engine-client-2: changing port to 49153 (from 0) >> [2019-07-12 19:19:55.033725] I [fuse-bridge.c:4205:fuse_init] 0-glusterfs-fuse: FUSE inited with protocol versions: glusterfs 7.24 kernel 7.22 >> [2019-07-12 19:19:55.033748] I [fuse-bridge.c:4835:fuse_graph_sync] 0-fuse: switched to graph 0 >> [2019-07-12 19:19:55.033895] I [MSGID: 108006] [afr-common.c:537

1 0

Does Ovirt 4.3.4 have support for NFS 4/4.1/4.2 or pNFS
by Erick Perez 13 Jul '19

13 Jul '19

I have read the archives and the most recent discussion was 5 years ago. So I better ask again. My NAS runs Centos with NFS4.2 (and I am testing Ganesha in another server) Does Ovirt 4.3.4 have support for NFS 4/4.1/4.2 or pNFS Specially version 4.2 due to: Server-Side Copy: NFSv4.2 supports copy_file_range() system call, which allows the NFS client to efficiently copy data without wasting network resources. But this will only happen if the Ovirt (which I know is Centos based) supports NFS 4.2. Not sure If I update the NFS toolset on the Ovirt install, it will break something or worst.

3 2

System unable to recover after a crash
by carl langlois 13 Jul '19

13 Jul '19

Hi , I am in state where my system does not recover from a major failure. I have pinpoint the probleme to be that the hosted engine storage domain is not able to mount I have a glusterfs containing the storage domain. but when it attempt to mount glusterfs to /rhev/data-center/mnt/glusterSD/ovhost1:_engine i get +------------------------------------------------------------------------------+ [2019-07-12 19:19:44.063608] I [rpc-clnt.c:1986:rpc_clnt_reconfig] 0-engine-client-2: changing port to 49153 (from 0) [2019-07-12 19:19:55.033725] I [fuse-bridge.c:4205:fuse_init] 0-glusterfs-fuse: FUSE inited with protocol versions: glusterfs 7.24 kernel 7.22 [2019-07-12 19:19:55.033748] I [fuse-bridge.c:4835:fuse_graph_sync] 0-fuse: switched to graph 0 [2019-07-12 19:19:55.033895] I [MSGID: 108006] [afr-common.c:5372:afr_local_init] 0-engine-replicate-0: no subvolumes up [2019-07-12 19:19:55.033938] E [fuse-bridge.c:4271:fuse_first_lookup] 0-fuse: first lookup on root failed (Transport endpoint is not connected) [2019-07-12 19:19:55.034041] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk] 0-fuse: 00000000-0000-0000-0000-000000000001: failed to resolve (Transport endpoint is not connected) [2019-07-12 19:19:55.034060] E [fuse-bridge.c:900:fuse_getattr_resume] 0-glusterfs-fuse: 2: GETATTR 1 (00000000-0000-0000-0000-000000000001) resolution failed [2019-07-12 19:19:55.034095] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk] 0-fuse: 00000000-0000-0000-0000-000000000001: failed to resolve (Transport endpoint is not connected) [2019-07-12 19:19:55.034102] E [fuse-bridge.c:900:fuse_getattr_resume] 0-glusterfs-fuse: 3: GETATTR 1 (00000000-0000-0000-0000-000000000001) resolution failed [2019-07-12 19:19:55.035596] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk] 0-fuse: 00000000-0000-0000-0000-000000000001: failed to resolve (Transport endpoint is not connected) [2019-07-12 19:19:55.035611] E [fuse-bridge.c:900:fuse_getattr_resume] 0-glusterfs-fuse: 4: GETATTR 1 (00000000-0000-0000-0000-000000000001) resolution failed [2019-07-12 19:19:55.047957] I [fuse-bridge.c:5093:fuse_thread_proc] 0-fuse: initating unmount of /rhev/data-center/mnt/glusterSD/ovhost1:_engine The message "I [MSGID: 108006] [afr-common.c:5372:afr_local_init] 0-engine-replicate-0: no subvolumes up" repeated 3 times between [2019-07-12 19:19:55.033895] and [2019-07-12 19:19:55.035588] [2019-07-12 19:19:55.048138] W [glusterfsd.c:1375:cleanup_and_exit] (-->/lib64/libpthread.so.0(+0x7e25) [0x7f51cecb3e25] -->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xe5) [0x5632143bd4b5] -->/usr/sbin/glusterfs(cleanup_and_exit+0x6b) [0x5632143bd32b] ) 0-: received signum (15), shutting down [2019-07-12 19:19:55.048150] I [fuse-bridge.c:5852:fini] 0-fuse: Unmounting '/rhev/data-center/mnt/glusterSD/ovhost1:_engine'. [2019-07-12 19:19:55.048155] I [fuse-bridge.c:5857:fini] 0-fuse: Closing fuse connection to '/rhev/data-center/mnt/glusterSD/ovhost1:_engine'. [2019-07-12 19:19:56.029923] I [MSGID: 100030] [glusterfsd.c:2511:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.12.11 (args: /usr/sbin/glusterfs --volfile-server=ovhost1 --volfile-server=ovhost2 --volfile-server=ovhost3 --volfile-id=/engine /rhev/data-center/mnt/glusterSD/ovhost1:_engine) [2019-07-12 19:19:56.032209] W [MSGID: 101002] [options.c:995:xl_opt_validate] 0-glusterfs: option 'address-family' is deprecated, preferred is 'transport.address-family', continuing with correction [2019-07-12 19:19:56.037510] I [MSGID: 101190] [event-epoll.c:613:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1 [2019-07-12 19:19:56.039618] I [MSGID: 101190] [event-epoll.c:613:event_dispatch_epoll_worker] 0-epoll: Started thread with index 2 [2019-07-12 19:19:56.039691] W [MSGID: 101174] [graph.c:363:_log_if_unknown_option] 0-engine-readdir-ahead: option 'parallel-readdir' is not recognized [2019-07-12 19:19:56.039739] I [MSGID: 114020] [client.c:2360:notify] 0-engine-client-0: parent translators are ready, attempting connect on transport [2019-07-12 19:19:56.043324] I [MSGID: 114020] [client.c:2360:notify] 0-engine-client-1: parent translators are ready, attempting connect on transport [2019-07-12 19:19:56.043481] I [rpc-clnt.c:1986:rpc_clnt_reconfig] 0-engine-client-0: changing port to 49153 (from 0) [2019-07-12 19:19:56.048539] I [MSGID: 114020] [client.c:2360:notify] 0-engine-client-2: parent translators are ready, attempting connect on transport [2019-07-12 19:19:56.048952] I [rpc-clnt.c:1986:rpc_clnt_reconfig] 0-engine-client-1: changing port to 49153 (from 0) Final graph: without this mount point the ha-agent is not starting. the volume seem to be okey Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovhost1:/gluster_bricks/data/data 49152 0 Y 7505 Brick ovhost2:/gluster_bricks/data/data 49152 0 Y 3640 Brick ovhost3:/gluster_bricks/data/data 49152 0 Y 6329 Self-heal Daemon on localhost N/A N/A Y 7712 Self-heal Daemon on ovhost2 N/A N/A Y 4925 Self-heal Daemon on ovhost3 N/A N/A Y 6501 Task Status of Volume data ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: engine Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovhost1:/gluster_bricks/engine/engine 49153 0 Y 7514 Brick ovhost2:/gluster_bricks/engine/engine 49153 0 Y 3662 Brick ovhost3:/gluster_bricks/engine/engine 49153 0 Y 6339 Self-heal Daemon on localhost N/A N/A Y 7712 Self-heal Daemon on ovhost2 N/A N/A Y 4925 Self-heal Daemon on ovhost3 N/A N/A Y 6501 Task Status of Volume engine ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: iso Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovhost1:/gluster_bricks/iso/iso 49154 0 Y 7523 Brick ovhost2:/gluster_bricks/iso/iso 49154 0 Y 3715 Brick ovhost3:/gluster_bricks/iso/iso 49154 0 Y 6349 Self-heal Daemon on localhost N/A N/A Y 7712 Self-heal Daemon on ovhost2 N/A N/A Y 4925 Self-heal Daemon on ovhost3 N/A N/A Y 6501 Task Status of Volume iso ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: vmstore Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovhost1:/gluster_bricks/vmstore/vmsto re 49155 0 Y 7532 Brick ovhost2:/gluster_bricks/vmstore/vmsto re 49155 0 Y 3739 Brick ovhost3:/gluster_bricks/vmstore/vmsto re 49155 0 Y 6359 Self-heal Daemon on localhost N/A N/A Y 7712 Self-heal Daemon on ovhost2 N/A N/A Y 4925 Self-heal Daemon on ovhost3 N/A N/A Y 6501 Task Status of Volume vmstore ------------------------------------------------------------------------------ There are no active volume tasks I am not sure what to look for at this point Any help would be really appreciated. Thanks Carl

3 3

"Actual timezone in guest doesn't match configuration" for Windows VMs since guest agent 4.3
by Matthias Leopold 12 Jul '19

12 Jul '19

Hi, the oVirt guest agent seems to report DST configuration for the timezone since version 4.3 (of the guest agent). this results in "Actual timezone in guest doesn't match configuration" messages in the UI for windows VMs because the timezone field can't be matched with oVirt configuration anymore (no DST flag). to me this looks like a bug. shall I report it? I know there was a similar thread at the beginning of May, but there was no solution mentioned. Matthias

2 3

An error has occurred during installation of Host
by lliujd＠gmail.com 11 Jul '19

11 Jul '19

Hello everyone, I have installed an 'oVirt Engine' by 'yum install ovirt-engine' and the engine runs fine after 'engine-setup'. But when I trying to add node host,some error occurred: 1st: An error has occurred during installation of Host node02: Yum Cannot queue package dmidecode: 'ascii' codec can't encode characters in position 143-147: ordinal not in range(128). 2ed: An error has occurred during installation of Host node02: Failed to execute stage 'Environment packages setup': 'ascii' codec can't encode characters in position 143-147: ordinal not in range(128). 3rd: Host node02 installation failed. Command returned failure code 1 during SSH session 'root@node02'. On host node02,package dmidecode has been installed: rpm -qa | grep dmidecode python-dmidecode-3.12.2-3.el7.x86_64 dmidecode-3.1-2.el7.x86_64 anyone can help ? Thanks !

2 2

Update 4.2.8 --> 4.3.5
by Christoph Köhler 11 Jul '19

11 Jul '19

Hello! We have a 4.2.8 environment with some managed gluster-volumes as storage domains and we want to go up to 4.3.5. How is that procedure especially with the gluster nodes in ovirt that are running 3.12.15? My fear is on the jump to gluster 6. Do the cluster work if the first node (of three) is upgraded? And what about the sequence - first the hypervisors or first gluster nodes? Is there anyone who had done this? Greetings! Christoph Köhler

1 0

Re: VM Migrations Failing
by Strahil 11 Jul '19

11 Jul '19

Power down the VM and reduce the memory a little bit but keep the maximum memory value the same or larger. Then power it up and extend the ram to the same value the VM had. It's a wild guess... So don't expect miracles. Best Regards, Strahil NikolovOn Jul 10, 2019 18:21, Michael Watters <wattersm(a)watters.ws> wrote: > > I need to migrate running VMs from one host in our cluster to another > however the task keeps failing any time I start a migration. The engine > logs show a few different errors as follows. > > 2019-07-10 09:53:19,440-04 ERROR > [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] > (ForkJoinPool-1-worker-2) [] Migration of VM 'vm1' to host > 'ovirt-node-production3' failed: VM destroyed during the startup. > > 2019-07-10 09:53:06,542-04 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (default task-51) [c1daf639-ff39-4397-b1bf-09426cacf72d] EVENT_ID: > VM_MIGRATION_FAILED(65), Migration failed due to a failed validation: > [Cannot migrate VM. There is no host that satisfies current scheduling > constraints. See below for details:, The host ovirt-node-production3 did > not satisfy internal filter Memory.] (VM: vm2, Source: > ovirt-node-production2). > > I also checked the vdsm.log on the destination host which is showing an > error like this. > > ERROR (jsonrpc/2) [virt.vm] > (vmId='f5bb25a8-3176-40b6-b21b-f07ed1089b27') Alias not found for device > type balloon during migration at destination host (vm:5562) > > Does anybody know how to resolve this? The destination host is able to > run VMs and I've been able to move a few VMs by shutting down and doing > a restart however I'd like to do a live migration if possible. > > > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)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/AWOTK2Q7OJGJX…

2 1

Manual Migration not working and Dashboard broken after 4.3.4 update
by Neil 11 Jul '19

11 Jul '19

Hi guys. I have two problems since upgrading from 4.2.x to 4.3.4 First issue is I can no longer manually migrate VM's between hosts, I get an error in the ovirt GUI that says "Could not fetch data needed for VM migrate operation" and nothing gets logged either in my engine.log or my vdsm.log Then the other issue is my Dashboard says the following "Error! Could not fetch dashboard data. Please ensure that data warehouse is properly installed and configured." If I look at my ovirt-engine-dwhd.log I see the following if I try restart the dwh service... 2019-07-09 11:48:04|ETL Service Started ovirtEngineDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbJdbcConnection|jdbc:postgresql://localhost:5432/ovirt_engine_history?sslfactory=org.postgresql.ssl.NonValidatingFactory hoursToKeepDaily|0 hoursToKeepHourly|720 ovirtEngineDbPassword|********************** runDeleteTime|3 ovirtEngineDbJdbcConnection|jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory runInterleave|60 limitRows|limit 1000 ovirtEngineHistoryDbUser|ovirt_engine_history ovirtEngineDbUser|engine deleteIncrement|10 timeBetweenErrorEvents|300000 hoursToKeepSamples|24 deleteMultiplier|1000 lastErrorSent|2011-07-03 12:46:47.000000 etlVersion|4.3.0 dwhAggregationDebug|false dwhUuid|dca0ebd3-c58f-4389-a1f8-6aecc20b1316 ovirtEngineHistoryDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbPassword|********************** 2019-07-09 11:48:10|ETL Service Stopped 2019-07-09 11:49:59|ETL Service Started ovirtEngineDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbJdbcConnection|jdbc:postgresql://localhost:5432/ovirt_engine_history?sslfactory=org.postgresql.ssl.NonValidatingFactory hoursToKeepDaily|0 hoursToKeepHourly|720 ovirtEngineDbPassword|********************** runDeleteTime|3 ovirtEngineDbJdbcConnection|jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory runInterleave|60 limitRows|limit 1000 ovirtEngineHistoryDbUser|ovirt_engine_history ovirtEngineDbUser|engine deleteIncrement|10 timeBetweenErrorEvents|300000 hoursToKeepSamples|24 deleteMultiplier|1000 lastErrorSent|2011-07-03 12:46:47.000000 etlVersion|4.3.0 dwhAggregationDebug|false dwhUuid|dca0ebd3-c58f-4389-a1f8-6aecc20b1316 ovirtEngineHistoryDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbPassword|********************** 2019-07-09 11:52:56|ETL Service Stopped 2019-07-09 11:52:57|ETL Service Started ovirtEngineDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbJdbcConnection|jdbc:postgresql://localhost:5432/ovirt_engine_history?sslfactory=org.postgresql.ssl.NonValidatingFactory hoursToKeepDaily|0 hoursToKeepHourly|720 ovirtEngineDbPassword|********************** runDeleteTime|3 ovirtEngineDbJdbcConnection|jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory runInterleave|60 limitRows|limit 1000 ovirtEngineHistoryDbUser|ovirt_engine_history ovirtEngineDbUser|engine deleteIncrement|10 timeBetweenErrorEvents|300000 hoursToKeepSamples|24 deleteMultiplier|1000 lastErrorSent|2011-07-03 12:46:47.000000 etlVersion|4.3.0 dwhAggregationDebug|false dwhUuid|dca0ebd3-c58f-4389-a1f8-6aecc20b1316 ovirtEngineHistoryDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbPassword|********************** 2019-07-09 12:16:01|ETL Service Stopped 2019-07-09 12:16:45|ETL Service Started ovirtEngineDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbJdbcConnection|jdbc:postgresql://localhost:5432/ovirt_engine_history?sslfactory=org.postgresql.ssl.NonValidatingFactory hoursToKeepDaily|0 hoursToKeepHourly|720 ovirtEngineDbPassword|********************** runDeleteTime|3 ovirtEngineDbJdbcConnection|jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory runInterleave|60 limitRows|limit 1000 ovirtEngineHistoryDbUser|ovirt_engine_history ovirtEngineDbUser|engine deleteIncrement|10 timeBetweenErrorEvents|300000 hoursToKeepSamples|24 deleteMultiplier|1000 lastErrorSent|2011-07-03 12:46:47.000000 etlVersion|4.3.0 dwhAggregationDebug|false dwhUuid|dca0ebd3-c58f-4389-a1f8-6aecc20b1316 ovirtEngineHistoryDbDriverClass|org.postgresql.Driver ovirtEngineHistoryDbPassword|********************** I have a hosted engine, and I have two hosts and my storage is FC based. The hosts are still running on 4.2 because I'm unable to migrate VM's off. I have plenty resources available in terms of CPU and Memory on the destination host, and my Cluster version is set to 4.2 because my hosts are still on 4.2 I have recently upgraded from 4.1 to 4.2 and then I upgraded my hosts to 4.2 as well, but I can't get my hosts to 4.3 because of the above migration issue. Below my ovirt packages installed... ovirt-ansible-cluster-upgrade-1.1.13-1.el7.noarch ovirt-ansible-disaster-recovery-1.1.4-1.el7.noarch ovirt-ansible-engine-setup-1.1.9-1.el7.noarch ovirt-ansible-hosted-engine-setup-1.0.20-1.el7.noarch ovirt-ansible-image-template-1.1.11-1.el7.noarch ovirt-ansible-infra-1.1.12-1.el7.noarch ovirt-ansible-manageiq-1.1.14-1.el7.noarch ovirt-ansible-repositories-1.1.5-1.el7.noarch ovirt-ansible-roles-1.1.6-1.el7.noarch ovirt-ansible-shutdown-env-1.0.3-1.el7.noarch ovirt-ansible-vm-infra-1.1.18-1.el7.noarch ovirt-cockpit-sso-0.1.1-1.el7.noarch ovirt-engine-4.3.4.3-1.el7.noarch ovirt-engine-api-explorer-0.0.5-1.el7.noarch ovirt-engine-backend-4.3.4.3-1.el7.noarch ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch ovirt-engine-dbscripts-4.3.4.3-1.el7.noarch ovirt-engine-dwh-4.3.0-1.el7.noarch ovirt-engine-dwh-setup-4.3.0-1.el7.noarch ovirt-engine-extension-aaa-jdbc-1.1.10-1.el7.noarch ovirt-engine-extensions-api-impl-4.3.4.3-1.el7.noarch ovirt-engine-metrics-1.3.3.1-1.el7.noarch ovirt-engine-restapi-4.3.4.3-1.el7.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7.centos.noarch ovirt-engine-setup-4.3.4.3-1.el7.noarch ovirt-engine-setup-base-4.3.4.3-1.el7.noarch ovirt-engine-setup-plugin-cinderlib-4.3.4.3-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-4.3.4.3-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-common-4.3.4.3-1.el7.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.3.4.3-1.el7.noarch ovirt-engine-setup-plugin-websocket-proxy-4.3.4.3-1.el7.noarch ovirt-engine-tools-4.3.4.3-1.el7.noarch ovirt-engine-tools-backup-4.3.4.3-1.el7.noarch ovirt-engine-ui-extensions-1.0.5-1.el7.noarch ovirt-engine-vmconsole-proxy-helper-4.3.4.3-1.el7.noarch ovirt-engine-webadmin-portal-4.3.4.3-1.el7.noarch ovirt-engine-websocket-proxy-4.3.4.3-1.el7.noarch ovirt-engine-wildfly-15.0.1-1.el7.x86_64 ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch ovirt-guest-agent-common-1.0.16-1.el7.noarch ovirt-guest-tools-iso-4.3-3.el7.noarch ovirt-host-deploy-common-1.8.0-1.el7.noarch ovirt-host-deploy-java-1.8.0-1.el7.noarch ovirt-imageio-common-1.5.1-0.el7.x86_64 ovirt-imageio-proxy-1.5.1-0.el7.noarch ovirt-imageio-proxy-setup-1.5.1-0.el7.noarch ovirt-iso-uploader-4.3.1-1.el7.noarch ovirt-js-dependencies-1.2.0-3.1.el7.centos.noarch ovirt-provider-ovn-1.2.22-1.el7.noarch ovirt-release41-4.1.9-1.el7.centos.noarch ovirt-release42-4.2.8-1.el7.noarch ovirt-release43-4.3.4-1.el7.noarch ovirt-vmconsole-1.0.7-2.el7.noarch ovirt-vmconsole-proxy-1.0.7-2.el7.noarch ovirt-web-ui-1.5.2-1.el7.noarch python2-ovirt-engine-lib-4.3.4.3-1.el7.noarch python2-ovirt-host-deploy-1.8.0-1.el7.noarch python2-ovirt-setup-lib-1.2.0-1.el7.noarch python-ovirt-engine-sdk4-4.3.1-2.el7.x86_64 [root@dell-ovirt ~]# rpm -qa | grep postgre rh-postgresql10-postgresql-contrib-10.6-1.el7.x86_64 rh-postgresql10-postgresql-10.6-1.el7.x86_64 postgresql-libs-9.2.24-1.el7_5.x86_64 collectd-postgresql-5.8.1-4.el7.x86_64 postgresql-server-9.2.24-1.el7_5.x86_64 rh-postgresql10-postgresql-server-10.6-1.el7.x86_64 rh-postgresql95-postgresql-9.5.14-1.el7.x86_64 rh-postgresql95-postgresql-contrib-9.5.14-1.el7.x86_64 postgresql-jdbc-9.2.1002-6.el7_5.noarch rh-postgresql10-runtime-3.1-1.el7.x86_64 rh-postgresql95-postgresql-libs-9.5.14-1.el7.x86_64 rh-postgresql10-postgresql-libs-10.6-1.el7.x86_64 postgresql-9.2.24-1.el7_5.x86_64 rh-postgresql95-runtime-2.2-2.el7.x86_64 rh-postgresql95-postgresql-server-9.5.14-1.el7.x86_64 I'm also seeing a strange error on my hosts when I log in showing... node status: DEGRADED Please check the status manually using `nodectl check` [root@host-a ~]# nodectl check Status: FAILED Bootloader ... OK Layer boot entries ... OK Valid boot entries ... OK Mount points ... OK Separate /var ... OK Discard is used ... OK Basic storage ... OK Initialized VG ... OK Initialized Thin Pool ... OK Initialized LVs ... OK Thin storage ... FAILED - It looks like the LVM layout is not correct. The reason could be an incorrect installation. Checking available space in thinpool ... OK Checking thinpool auto-extend ... FAILED - In order to enable thinpool auto-extend,activation/thin_pool_autoextend_threshold needs to be set below 100 in lvm.conf vdsmd ... OK I'm running CentOS Linux release 7.6.1810 (Core) These are my package versions on my hosts... [root@host-a ~]# rpm -qa | grep -i ovirt ovirt-release41-4.1.9-1.el7.centos.noarch ovirt-hosted-engine-ha-2.2.19-1.el7.noarch ovirt-host-deploy-1.7.4-1.el7.noarch ovirt-node-ng-nodectl-4.2.0-0.20190121.0.el7.noarch ovirt-vmconsole-host-1.0.6-2.el7.noarch ovirt-provider-ovn-driver-1.2.18-1.el7.noarch ovirt-engine-appliance-4.2-20190121.1.el7.noarch ovirt-release42-4.2.8-1.el7.noarch ovirt-release43-4.3.4-1.el7.noarch python-ovirt-engine-sdk4-4.2.9-2.el7.x86_64 cockpit-ovirt-dashboard-0.11.38-1.el7.noarch ovirt-imageio-daemon-1.4.6-1.el7.noarch ovirt-host-4.2.3-1.el7.x86_64 ovirt-setup-lib-1.1.5-1.el7.noarch ovirt-node-ng-image-update-4.2.8-1.el7.noarch ovirt-imageio-common-1.4.6-1.el7.x86_64 ovirt-vmconsole-1.0.6-2.el7.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7.centos.noarch ovirt-host-dependencies-4.2.3-1.el7.x86_64 ovirt-release-host-node-4.2.8-1.el7.noarch cockpit-machines-ovirt-193-2.el7.noarch ovirt-hosted-engine-setup-2.2.33-1.el7.noarch [root@host-a ~]# rpm -qa | grep -i vdsm vdsm-http-4.20.46-1.el7.noarch vdsm-common-4.20.46-1.el7.noarch vdsm-network-4.20.46-1.el7.x86_64 vdsm-jsonrpc-4.20.46-1.el7.noarch vdsm-4.20.46-1.el7.x86_64 vdsm-hook-ethtool-options-4.20.46-1.el7.noarch vdsm-hook-vhostmd-4.20.46-1.el7.noarch vdsm-python-4.20.46-1.el7.noarch vdsm-api-4.20.46-1.el7.noarch vdsm-yajsonrpc-4.20.46-1.el7.noarch vdsm-hook-fcoe-4.20.46-1.el7.noarch vdsm-hook-openstacknet-4.20.46-1.el7.noarch vdsm-client-4.20.46-1.el7.noarch vdsm-gluster-4.20.46-1.el7.x86_64 vdsm-hook-vmfex-dev-4.20.46-1.el7.noarch I am seeing the following error every minute or so in my vdsm.log as follows.... 2019-07-09 12:50:31,543+0200 WARN (qgapoller/2) [virt.periodic.VmDispatcher] could not run <function <lambda> at 0x7f52b01b85f0> on ['9a6561b8-5702-43dc-9e92-1dc5dfed4eef'] (periodic:323) Then also under /var/log/messages.. Jul 9 12:57:48 host-a ovs-vsctl: ovs|00001|db_ctl_base|ERR|unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) I'm not using ovn so I'm guessing this can be ignored. If I search for ERROR or WARN in my logs nothing relevant is logged Any suggestions on what to start looking for please? Please let me know if you need further info. Thank you. Regards. Neil Wilson

4 9

Re: Impossible to install VM Machine
by Juan Pablo Lorier 10 Jul '19

10 Jul '19

Hi Abdoul, what I don't get right is what is your setup. Ovirt can have data domains that is where you put the vm disks. That domains can be NFS share, gluster bricks, iscsi san or direct disk. When you say files sharing folders, I can't think of a data domain attached there unless it's a NFS local share. Maybe I'm missing something, but I can see that working. Do you have a data domain in storage? I tend to think you have because otherway you can't create the disks for the vms (which you add when you create the vm) Please, replay to the list too so others can see the thread. Regards On 10/7/19 16:51, Abdoul-Rahamane Issoufou Oumarou wrote: > Thank you Juan Pablo, > > Yes indeed I installed everything on one machine. Before I used > ovirt-node and ovirt but it always gave me the same problem. > > I'm going to try again and I'll make you a catch of the mistakes I get. > > Otherwise for storage, I created FILES sharing folders on the ovirt > machine it's them that I use. > > Thank you very much > > Le mer. 10 juil. 2019 à 20:24, Juan Pablo Lorier <jplorier(a)gmail.com > <mailto:jplorier@gmail.com>> a écrit : > > Hi, > > We need more information to try and find the problem. Did you look at > the logs in ovirt-engine? I assume by your description that you ran an > all in one install. What storage are you using? > > Regards >

2 1

Impossible to install VM Machine
by Juan Pablo Lorier 10 Jul '19

10 Jul '19

Hi, We need more information to try and find the problem. Did you look at the logs in ovirt-engine? I assume by your description that you ran an all in one install. What storage are you using? Regards

1 0