Non responsive host (4.3.10)
by Maria Souvalioti
Hello everyone!
Due to a recent major power outage in my area I now have an unresponsive self hosted host in an environment of 3 self hosted hosts. There's one vm stuck on there as well as some metadata I guess from when hosted engine was running there (before the power went down).
I'm running 4.3.10 ovirt node with 3 nodes and GlusterFS, no arbiter, and I'm using it to provide services to our clients i.e. DNS, web sites, wikis, ticketing etc. and I cannot shut them down.
The ovirt engine is up and running and I can manage all the other VMs that run on the other hosts through the web gui.
The unresponsive host replies only to ICMP requests; in every other sense it's dead, no ssh, no gluster bricks, no console, nothing.
I tried to place the faulty host in maintenance, using the option to stop glusterd, but wasn't able to as the engine won't let the host go into maintenance mode because it thinks the host has running VMs on it. The host won't go into maintenance even if I chose the "Ignore gluster quorum and self-heal validations" option.
I spent last week creating a backup environment were I copied the VMs, to have somewhere to run them in case something goes terribly wrong with the systems or the gluster in the production system.
I'm thinking of using the global maintenance mode and then shutting down the engine itself with *hosted-engine --vm-shutdown* and rebooting the affected host.
Should I remove the host from the cluster and then re-add it or should I do something else?
Thanks for any of your help!
1 day, 3 hours
novnc console error: promise.js missing?
by karl.morgan＠gmail.com
Seeing the following on the engine when attempting to start a novnc console
2023-03-31 11:57:34,988-07 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-29) [307c22a9] START, SetVmTicketVDSCommand(HostName = ov2node02-mn, SetVmTicketVDSCommandParameters:{hostId='19a92de3-c6e4-4f4e-be31-1d5533a2b6b6', vmId='4481b0e9-a96c-4ee7-8bd2-572558eb9fda', protocol='VNC', ticket='LMl903dd', validTime='120', userName='admin@ovirt', userId='9e88a363-34cb-466a-8ba9-25e46819423b', disconnectAction='LOCK_SCREEN', consoleDisconnectActionDelay='0'}), log id: 1d6520d5
2023-03-31 11:57:35,031-07 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-29) [307c22a9] FINISH, SetVmTicketVDSCommand, return: , log id: 1d6520d5
2023-03-31 11:57:35,044-07 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-29) [307c22a9] EVENT_ID: VM_SET_TICKET(164), User admin@ovirt@internalkeycloak-authz initiated console session for VM first
2023-03-31 11:57:35,158-07 INFO [org.ovirt.engine.core.utils.servlet.ServletUtils] (default task-29) [] Can't read file '/usr/share/ovirt-engine/files/novnc/vendor/promise.js' for request '/ovirt-engine/services/files/novnc/vendor/promise.js' -- 404
Curious if this is obvious to anyone? How to resolve?
ovirt-engine-webadmin-portal-4.5.4-1.el9.noarch
ovirt-engine-4.5.4-1.el9.noarch
5 days, 7 hours
OKD Installer Provisioned Infrastructure in oVirt > 4.3
by Fredrik Arneving
Hi,
I've successfully installed OKD <= 4.8 in my ovirt 4.3 self-hosted engine setup. However, I have now found out that the imageio-proxy and/or imageio-deamon has changed it's API calls and ports to make the OKD install fail on self-hosted (all-in-one) setups on ovirt 4.4 and 4.5. Since I've upgraded to version 4.5 I can no longer install OKD with Installer Provisioned Infrastructure.
I recently read throough a long thread in bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1871348) on how to get image uploads working from the GUI but haven't found any solutions for making the OKD install work. The suggested solution, engine-config -s "EnableImageioProxy=false", didn't solve my problem.
Would it be possible to tweak the setup so that the OKD installer can upload it's image through imageio? I don't use the imageio service for anything else since I (almost) only kickstart my new vm's from my foreman servers so if other use cases than the OKD install would fail I can live with that.
I take it the problem only appears for a self-hosted setup. If it was possible to migrate the engine to a standalone host (not a powerful compute node but somewhere with 4vCPU and 16 GB RAM) would that make the solution easier? I would lose a lot of my current infrastructure if I had to reinstall but if I can't find a better solution I will have to.
Any help would be appreciated.
1 week, 1 day
VM host deploy failed
by Latchezar Filtchev
Hi there,
Centos Stream 8 fresh standalone install from nightly build of ovirt-engine. VM host Centos Stream 8 node nightly build repo enabled.
Cannot add host to engine. The error message:
Host n1 installation failed. Task Install ovirt-hosted-engine-setup package failed to execute. Please check logs for more details: /var/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20230530094214-n1.............
Any hint will be appreciated.
Thank you!
Best,
Latcho
2023-05-30 09:42:26 EEST - {
"uuid" : "e905de36-7b04-4b52-96b8-71855d561446",
"counter" : 99,
"stdout" : "fatal: [n1.aubgin.local]: FAILED! => {\"changed\": false, \"failures\": [], \"msg\": \"Depsolve Error occurred: \\n Problem: conflicting requests\\n - nothing provides python3-importlib-resources needed by ovirt-hosted-engine-setup-2.7.1-0.0.master.20230414113600.git340e19b.el8.noarch\", \"rc\": 1, \"results\": []}",
"start_line" : 87,
"end_line" : 88,
"runner_ident" : "c7d833e9-8de3-4d53-87a3-72c3d80177ce",
"event" : "runner_on_failed",
"pid" : 41043,
"created" : "2023-05-30T06:42:25.111204",
"parent_uuid" : "ac162d01-a065-3587-db9e-000000000228",
"event_data" : {
"playbook" : "ovirt-host-deploy.yml",
"playbook_uuid" : "de0dd632-7d53-4e08-a06c-610334200c49",
"play" : "all",
"play_uuid" : "ac162d01-a065-3587-db9e-000000000006",
"play_pattern" : "all",
"task" : "Install ovirt-hosted-engine-setup package",
"task_uuid" : "ac162d01-a065-3587-db9e-000000000228",
"task_action" : "ansible.builtin.yum",
"task_args" : "",
"task_path" : "/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-vdsm/tasks/packages.yml:6",
"role" : "ovirt-host-deploy-vdsm",
"host" : "n1.aubgin.local",
"remote_addr" : "n1.aubgin.local",
"res" : {
"failures" : [ ],
"results" : [ ],
"rc" : 1,
"msg" : "Depsolve Error occurred: \n Problem: conflicting requests\n - nothing provides python3-importlib-resources needed by ovirt-hosted-engine-setup-2.7.1-0.0.master.20230414113600.git340e19b.el8.noarch",
"invocation" : {
"module_args" : {
"name" : [ "ovirt-hosted-engine-setup" ],
"state" : "present",
"allow_downgrade" : false,
"autoremove" : false,
"bugfix" : false,
"cacheonly" : false,
"disable_gpg_check" : false,
"disable_plugin" : [ ],
"disablerepo" : [ ],
"download_only" : false,
"enable_plugin" : [ ],
"enablerepo" : [ ],
"exclude" : [ ],
"installroot" : "/",
"install_repoquery" : true,
"install_weak_deps" : true,
"security" : false,
"skip_broken" : false,
"update_cache" : false,
"update_only" : false,
"validate_certs" : true,
"sslverify" : true,
"lock_timeout" : 30,
"allowerasing" : false,
"nobest" : false,
"conf_file" : null,
"disable_excludes" : null,
"download_dir" : null,
"list" : null,
"releasever" : null
}
},
"_ansible_no_log" : null,
"changed" : false
},
"start" : "2023-05-30T06:42:23.217686",
"end" : "2023-05-30T06:42:25.111007",
"duration" : 1.893321,
"ignore_errors" : null,
"event_loop" : null,
"uuid" : "e905de36-7b04-4b52-96b8-71855d561446"
}
}
[root@e host-deploy]#
1 week, 1 day
ERROR HSMGetAllTasksStatusesVDS Cannot deactivate Logical Volume:
by parallax
Hello
environment: oVirt 4.5.4-1
messages like this appear in the event log
what do these errors mean?
the volume 114f08c4-f864-44e1-a937-19405307e643 has 128m size
ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-18) []
EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM kvm3 command
HSMGetAllTasksStatusesVDS failed: value=Cannot deactivate Logical Volume:
'error=General Storage Exception: ("5 [] [\' Logical volume
3526ebaa-31de-4c9f-b724-f0fbe5448a78/114f08c4-f864-44e1-a937-19405307e643
in
use.\']\\n3526ebaa-31de-4c9f-b724-f0fbe5448a78/[\'114f08c4-f864-44e1-a937-19405307e643\']",),
users={\'/dev/3526ebaa-31de-4c9f-b724-f0fbe5448a78/114f08c4-f864-44e1-a937-19405307e643\':
[{\'pid\': 2227780, \'command\': \'systemd-udevd\', \'user\': \'root\',
\'fd\': 7}]}' abortedcode=552
1 week, 6 days
Extended ovirt image disk and now virtual size is < 1 GiB and actual size i +1TB
by arc＠b4restore.com
Hi,
i extended 16 virtual image disks today by 1000GiB through the GUI and now we have a problem with some of them... 9 of them are shown if "edited" that they have a size of 0GiB and not 16360GiB as expected?
5 of them are not able to be extended either within the VM. we tried to power it off and then on again (not reboot, but actual power off / power on)
any suggestions to get out of this weird mode? disks seems as if they have the "old" size within the VM but are shown in oVirt as if they are 0GiB.?
They are relying on a posix compliant fs if that makes any difference, and they are thin-provisioned and discard-enabled.
Thanks in advance.
2 weeks
VM causes CPU blocks and forces reboot of host
by dominik.drazyk＠blackrack.pl
Hello,
I have recently migrated our customer's cluster to newer hardware (CentOS 8 Stream, 4 hypervisor nodes, 3 hosts with GlusterFS 5x 6TB SSD as JBOD with replica 3). After 1 month from the switch we encounter frequent vm locks that need host reboot in order to unlock the VM. Affected vms cannot be powered down from ovirt UI. Even if ovirt is successful in powering down affected vms, they cannot be booted again with information that OS disk is used. Once I reboot the host, vms can be turned on and everything works fine.
In vdsm logs I can note the following error:
2023-05-11 19:33:12,339+0200 ERROR (qgapoller/1) [virt.periodic.Operation] <bound method QemuGuestAgentPoller._poller
of <vdsm.virt.qemuguestagent.QemuGuestAgentPoller object at 0x7f553aa3e470>> operation failed (periodic:187)
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/vdsm/virt/periodic.py", line 185, in __call__
self._func()
File "/usr/lib/python3.6/site-packages/vdsm/virt/qemuguestagent.py", line 476, in _poller
vm_id, self._qga_call_get_vcpus(vm_obj))
File "/usr/lib/python3.6/site-packages/vdsm/virt/qemuguestagent.py", line 797, in _qga_call_get_vcpus
if 'online' in vcpus:
TypeError: argument of type 'NoneType' is not iterable
/var/log/messages reports:
May 11 19:35:15 kernel: task:CPU 7/KVM state:D stack: 0 pid: 7065 ppid: 1 flags: 0x80000182
May 11 19:35:15 kernel: Call Trace:
May 11 19:35:15 kernel: __schedule+0x2d1/0x870
May 11 19:35:15 kernel: schedule+0x55/0xf0
May 11 19:35:15 kernel: schedule_preempt_disabled+0xa/0x10
May 11 19:35:15 kernel: rwsem_down_read_slowpath+0x26e/0x3f0
May 11 19:35:15 kernel: down_read+0x95/0xa0
May 11 19:35:15 kernel: get_user_pages_unlocked+0x66/0x2a0
May 11 19:35:15 kernel: hva_to_pfn+0xf5/0x430 [kvm]
May 11 19:35:15 kernel: kvm_faultin_pfn+0x95/0x2e0 [kvm]
May 11 19:35:15 kernel: ? select_task_rq_fair+0x355/0x990
May 11 19:35:15 kernel: ? sched_clock+0x5/0x10
May 11 19:35:15 kernel: ? sched_clock_cpu+0xc/0xb0
May 11 19:35:15 kernel: direct_page_fault+0x3b4/0x860 [kvm]
May 11 19:35:15 kernel: kvm_mmu_page_fault+0x114/0x680 [kvm]
May 11 19:35:15 kernel: ? vmx_vmexit+0x9f/0x70d [kvm_intel]
May 11 19:35:15 kernel: ? vmx_vmexit+0xae/0x70d [kvm_intel]
May 11 19:35:15 kernel: ? gfn_to_pfn_cache_invalidate_start+0x190/0x190 [kvm]
May 11 19:35:15 kernel: vmx_handle_exit+0x177/0x770 [kvm_intel]
May 11 19:35:15 kernel: ? gfn_to_pfn_cache_invalidate_start+0x190/0x190 [kvm]
May 11 19:35:15 kernel: vcpu_enter_guest+0xafd/0x18e0 [kvm]
May 11 19:35:15 kernel: ? hrtimer_try_to_cancel+0x7b/0x100
May 11 19:35:15 kernel: kvm_arch_vcpu_ioctl_run+0x112/0x600 [kvm]
May 11 19:35:15 kernel: kvm_vcpu_ioctl+0x2c9/0x640 [kvm]
May 11 19:35:15 kernel: ? pollwake+0x74/0xa0
May 11 19:35:15 kernel: ? wake_up_q+0x70/0x70
May 11 19:35:15 kernel: ? __wake_up_common+0x7a/0x190
May 11 19:35:15 kernel: do_vfs_ioctl+0xa4/0x690
May 11 19:35:15 kernel: ksys_ioctl+0x64/0xa0
May 11 19:35:15 kernel: __x64_sys_ioctl+0x16/0x20
May 11 19:35:15 kernel: do_syscall_64+0x5b/0x1b0
May 11 19:35:15 kernel: entry_SYSCALL_64_after_hwframe+0x61/0xc6
May 11 19:35:15 kernel: RIP: 0033:0x7faf1a1387cb
May 11 19:35:15 kernel: Code: Unable to access opcode bytes at RIP 0x7faf1a1387a1.
May 11 19:35:15 kernel: RSP: 002b:00007fa6f5ffa6e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
May 11 19:35:15 kernel: RAX: ffffffffffffffda RBX: 000055be52e7bcf0 RCX: 00007faf1a1387cb
May 11 19:35:15 kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000027
May 11 19:35:15 kernel: RBP: 0000000000000000 R08: 000055be5158c6a8 R09: 00000007d9e95a00
May 11 19:35:15 kernel: R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
May 11 19:35:15 kernel: R13: 000055be515bcfc0 R14: 00007fffec958800 R15: 00007faf1d6c6000
May 11 19:35:15 kernel: INFO: task worker:714626 blocked for more than 120 seconds.
May 11 19:35:15 kernel: Not tainted 4.18.0-489.el8.x86_64 #1
May 11 19:35:15 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:35:15 kernel: task:worker state:D stack: 0 pid:714626 ppid: 1 flags:0x00000180
May 11 19:35:15 kernel: Call Trace:
May 11 19:35:15 kernel: __schedule+0x2d1/0x870
May 11 19:35:15 kernel: schedule+0x55/0xf0
May 11 19:35:15 kernel: schedule_preempt_disabled+0xa/0x10
May 11 19:35:15 kernel: rwsem_down_read_slowpath+0x26e/0x3f0
May 11 19:35:15 kernel: down_read+0x95/0xa0
May 11 19:35:15 kernel: do_madvise.part.30+0x2c3/0xa40
May 11 19:35:15 kernel: ? syscall_trace_enter+0x1ff/0x2d0
May 11 19:35:15 kernel: ? __x64_sys_madvise+0x26/0x30
May 11 19:35:15 kernel: __x64_sys_madvise+0x26/0x30
May 11 19:35:15 kernel: do_syscall_64+0x5b/0x1b0
May 11 19:35:15 kernel: entry_SYSCALL_64_after_hwframe+0x61/0xc6
May 11 19:35:15 kernel: RIP: 0033:0x7faf1a138a4b
May 11 19:35:15 kernel: Code: Unable to access opcode bytes at RIP 0x7faf1a138a21.
May 11 19:35:15 kernel: RSP: 002b:00007faf151ea7f8 EFLAGS: 00000206 ORIG_RAX: 000000000000001c
May 11 19:35:15 kernel: RAX: ffffffffffffffda RBX: 00007faf149eb000 RCX: 00007faf1a138a4b
May 11 19:35:15 kernel: RDX: 0000000000000004 RSI: 00000000007fb000 RDI: 00007faf149eb000
May 11 19:35:15 kernel: RBP: 0000000000000000 R08: 00000007faf080ba R09: 00000000ffffffff
May 11 19:35:15 kernel: R10: 00007faf151ea760 R11: 0000000000000206 R12: 00007faf15aec48e
May 11 19:35:15 kernel: R13: 00007faf15aec48f R14: 00007faf151eb700 R15: 00007faf151ea8c0
May 11 19:35:15 kernel: INFO: task worker:714628 blocked for more than 120 seconds.
May 11 19:35:15 kernel: Not tainted 4.18.0-489.el8.x86_64 #1
May 11 19:35:15 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Installed VDSM packages:
vdsm-api-4.50.3.4-1.el8.noarch
vdsm-network-4.50.3.4-1.el8.x86_64
vdsm-yajsonrpc-4.50.3.4-1.el8.noarch
vdsm-http-4.50.3.4-1.el8.noarch
vdsm-client-4.50.3.4-1.el8.noarch
vdsm-4.50.3.4-1.el8.x86_64
vdsm-gluster-4.50.3.4-1.el8.x86_64
vdsm-python-4.50.3.4-1.el8.noarch
vdsm-jsonrpc-4.50.3.4-1.el8.noarch
vdsm-common-4.50.3.4-1.el8.noarch
Libvirt:
libvirt-client-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-nodedev-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-logical-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-network-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-qemu-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-scsi-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-core-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-config-network-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-iscsi-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-rbd-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-libs-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-config-nwfilter-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-secret-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-disk-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-mpath-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-gluster-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
python3-libvirt-8.0.0-2.module_el8.7.0+1218+f626c2ff.x86_64
libvirt-daemon-driver-nwfilter-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-lock-sanlock-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-interface-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-driver-storage-iscsi-direct-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
libvirt-daemon-kvm-8.0.0-14.module_el8.8.0+1257+0c3374ae.x86_64
During the issue with locked vms, they do not respond from network, I cannot use VNC console (or any other) to check what is happening from VM perspective. The host cannot list running processes. There are plenty of resources left and each host runs about 30-35 vms.
First I thought that it might be related to glusterfs (I use gluster on other clusters and it usually works fine), so we migrated all vms back to old storage (NFS). The problem came back today on two hosts. I do not have such issues on other cluster which runs on Rocky 8.6 with hyperconverged glusterfs. Hence as a last resort I'll be migrating to Rocky 8 from CentOS 8-stream.
Has anyone observed such issues with ovirt hosts on CentOS 8-stream? Any form of help is welcome, as I'm running out of ideas.
2 weeks
Patching issue on RHEL 8.7-8.8
by jamesroark＠gmail.com
After applying RHEL updates for the recent upgrade from 8.7 to 8.8, I started getting some package problems on my oVirt engine and hosts.
Perhaps someone can help me figure out what is going on.
Environment:
oVirt 4.5.4-1.el8
Stand alone engine - Red Hat Enterprise Linux release 8.7 (Ootpa)
RHEL hosts - Red Hat Enterprise Linux release 8.7 (Ootpa)
# yum update
Updating Subscription Management repositories.
Last metadata expiration check: 3:01:05 ago on Fri 19 May 2023 09:43:55 AM EDT.
Error:
Problem: installed package centos-stream-release-8.6-1.el8.noarch obsoletes redhat-release < 9 provided by redhat-release-8.8-0.8.el8.x86_64
- cannot install the best update candidate for package redhat-release-8.7-0.3.el8.x86_64
- problem with installed package centos-stream-release-8.6-1.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
# yum update --nobest
Updating Subscription Management repositories.
Last metadata expiration check: 3:01:25 ago on Fri 19 May 2023 09:43:55 AM EDT.
Dependencies resolved.
Problem: installed package centos-stream-release-8.6-1.el8.noarch obsoletes redhat-release < 9 provided by redhat-release-8.8-0.8.el8.x86_64
- cannot install the best update candidate for package redhat-release-8.7-0.3.el8.x86_64
- problem with installed package centos-stream-release-8.6-1.el8.noarch
Nothing to do.
Complete!
I've applied the https://ovirt.org/download/install_on_rhel.html suggestions.
When I try to "Install nightly oVirt master snapshot" as suggested, I also get an error:
# dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-8
Updating Subscription Management repositories.
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-buil...>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Error: Failed to connect to https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/repo/...: Error
2 weeks
Ovirt 4.5.0 Support (End of Life Date)
by masood.ahmed＠digital.mod.uk
Hi,
I am working on a project and we would like to utilise (oVirt 4.5.) as the platform for our enterprise infrastructure.
We have arrived at this juncture because of a range of considerations related to hardware and software availability and compatibility.
My question is if there is on-going vendor \ professional support for oVirt moving forward, as one of my colleagues spoke with Red Hat, who stated they are going to end their support for the product.
we will not gain security accreditation for our project unless we have professional support available, community support only is not sufficient,
Any ideas of firms available for a support contract for oVirt 4.5.0?
thanks
2 weeks, 1 day
