[ovirt-users] Re: [External] : Re: Ovirt Hyperconverged
Hi Simon! I'd given up on ever finding any real person or back-channel on the Oracle side of oVirt, so you're saying there is actually such a thing! I'd [have] been more than happy to feed back all those results I was collecting in my desperate attempts to maintain a HCI infra with all those shifting Enterprise Linux players doing politics. Today my enterprise use case is transitioning to the cloud and my private use case to Proxmox. The latter has run mostly on Pentium Silver J5005 Atoms during the last couple of years and I am currently trying to work out the kinks on KVM live-migration between an Orange PI 5+ (32GB) and a Raspberry PI 5 (8GB) under Proxmox (using storage on a Ceph HCI cluster running on x86), so you may appreciate why an Oracle support contract wasn't in the picture for an infra I keep under four digits total invests to appease the wife. (Ok, I justed noticed that you're running OL9 on your OP5+, but I don't see you trying to port oVirt there...) Without that contract, it seems, that Oracle keeps very "stumm". So on HCI: When I ran across oVirt, that was somewhere when 4.3 was fresh and oVirt was advertised as "a solution for your entire enterprise" which included HCI, to catch potential Nutanix and vSphere customers. It sold me on the idea, that I could take an oVirt node ISO, install that on my hardware nodes, run a GUI wizard to thurn them into a clustered HCI appliance and be as happy as the other guy with Nut[ell]anix. That dream certainly cost me months of my life, not the hours I had imagined, but it paid a salary, too, when I managed to run it anyway. It took me long to realize that Oracle had ditched all their Xen stuff and become an oVirt convert. But even since then, there has been very little details and firm commitments nor even a branding that doesn't require typing classes to execute, so sorry, if most of my impressions are simply from informational gaps. But to my knowledge, Oracle never published node ISO images. Also to my knowledge, oVirt itself ditched HCI support, Redhat itself made nearly the entire technology stack oVirt is based on EOL, Gluster, oVirt, VDO and, of course, I had used all of that. Except storage tiering, where you'd use SSDs in your VDO/Gluster storage for a caching layer on top of HDDs: that I never got to work and then SSDs became mainline anyway. On my first EL8/oVirt 4.4 tests Oracle's Enterprise kernel failed immediately with VDO, which was missing then. Later even the Redhat kernel sometimes failed with VDO after kernel upgrades, because evidently nobody at Oracle cares about VDO. Funny, when you consider those Sun guys used to be very big into something similar... But also later I got into all kinds of trouble when I was setting up HCI with 4.4 and had not switched the kernels to the Redhat variant. If I remember correctly, the management engine never managed to connect to the network after it had been teleported into KVM and after it had been successfully configured locally on the temporary install node. I could have been that I tried this on nested virtualization, but it felt more kernel related, because switching that fixed the issue. Later I experimented with upgrades from 4.4 to 4.5 and ran into all sorts of trouble when switching the kernel there. Except that now things started failing with the Redhat kernel. Generally nobody seems to test switching between UEK and RHK on HCI nodes, which *should* be totally transparent on the wire and basically to all user space, if I understood Wim Coekaerts correctly, when we met in 2011. So my impression was that Oracle supported a subset of what oVirt supported and with HCI not even giving any search responses anywhere on oracle.com, I didn't see that remaining. And perhaps all I missed was to install 'cockpit-ovirt-dashboard'... So, good to know Oracle hasn't given up, good to know you keep an ear open here and now if there was a bit more public commitment for oVirt, we'd all be much happier. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KZ6ANPXHSFI2DQYIQP65XOIVA5ENIJJS/
[ovirt-users] Re: [External] : Re: Ovirt Hyperconverged
Hi Thomas, some feedback from Oracle: On Apr 17, 2024, at 5:12 PM, Thomas Hoberg wrote: I've tried to re-deploy oVirt 4.3 on CentOS7 servers because I had managed to utterly destroy a HCI farm, where most VMs had migrated to Oracles variant of RHV 4.4 on Oracle Linux. I guess I grew a bit careless towards its end. Mostly it was just an academic exercise to see if it could be resurrected... I was much happier with the Oracle variant anyway. Good to know! And I've hit similar issues all over the place: the ansible scripts and/or the python packages they interact with are utterly broken with now years of completely disjunct bug-fixing going on. The underlying CentOS 7 packages continue in maintenance (some more weeks to go..), but the oVirt 4.3 on top has been unmaintained for years. Since these are just sanity checks, I deleted all of them, one after the other (and there is lots of them!), and I eventually got it to work again. Don't have a single VM on it, though, because you can't trust it, the hardware is ancient and it really was just a finger exercise at that stage. With CentOS 7 going out of support now, it's really messing with a corpse. I'm currently operating Oracle's 4.4 variant running on their Linux, too, which still has Gluster based HCI built-in, even if they don't mention it at all. We mention it on our docs: https://docs.oracle.com/en/virtualization/oracle-linux-virtualization-manager/getstart/getstarted-hosted-engine-deploy.html#he-deploy-prereqs and it’s still there for 4.5 release. Just make sure you switch their Unbreakable Linux kernel for the Redhat variant everywhere, otherwise you'll risk all kinds of nasties. We support both UEK and RHCK (Red Hat Compatible Kernel); if an issue is there, we want to know :) It's been way more stable than oVirt 4.3 ever was, but that doesn't mean it's "enterprise": that was always one fat big exaggeration, withful thinking, whatever. This is due to oVirt people and our own testing too! oVirt 4.4 is, for sure, more stable too. And don't fall for their 4.5 variant, that came out end of last year: that one doesn't support HCI any more and actually seems to fail withOUT their Enterprise Linux kernels. We still support HCI and we still support our own kernel (UEK) as well as the Red Hat Compatible one. And no, it doesn't run on EL9 either, that might take another year or so, as Oracle's oVirt implementation is almost a year behind oVirt at the moment. This is our choice; we today have the same UEK7 kernel (5.15.0-x) available for OL8 and OL9 and we do not see any reason to force our customers/users to upgrade to 9. Simon ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://urldefense.com/v3/__https://www.ovirt.org/privacy-policy.html__;!!ACWV5N9M2RV99hQ!NOVxiz9jioj-jKvwi9kwGZXrQhW-zDhb2lvdm-lcIG3abkVfZzzq70mx3nFTW1XwqMrsHT7fb_YjNjx0$ oVirt Code of Conduct: https://urldefense.com/v3/__https://www.ovirt.org/community/about/community-guidelines/__;!!ACWV5N9M2RV99hQ!NOVxiz9jioj-jKvwi9kwGZXrQhW-zDhb2lvdm-lcIG3abkVfZzzq70mx3nFTW1XwqMrsHT7fb4lslbWH$ List Archives: https://urldefense.com/v3/__https://lists.ovirt.org/archives/list/users@ovirt.org/message/X435DYEU5BMHQ7ZHSTJPYF4ZCXQ2GJXU/__;!!ACWV5N9M2RV99hQ!NOVxiz9jioj-jKvwi9kwGZXrQhW-zDhb2lvdm-lcIG3abkVfZzzq70mx3nFTW1XwqMrsHT7fb5B95HQ-$ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2OYLZ4AVBCQJA6ROSSXUZ4WVQA2LOX3Q/
[ovirt-users] Re: [External] : Re: Ovirt Hyperconverged
Hi Ricardo,
When searching for SHE deployment errors, grep for error and failed:
grep -i -e error -e failed
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20240415201836-r0gt54.log
If you have the logs available, try again, will be easier to find the cause.
Marcos
-Original Message-
From: Ricardo OT
Sent: Monday, April 15, 2024 4:21 PM
To: users@ovirt.org
Subject: [External] : [ovirt-users] Re: Ovirt Hyperconverged
Hi,
I have recently tried to install the hosted engine on a node recently installed
with Rocky Linux 8.9 with glusterfs and with the nightly oVirt master snapshot
repository, and I have also tried to do the same with the Oracle distribution
and I have not been able to get the installation of the hosted engine to work.
Before this worked. Now I have only managed to install the engine as
standalone. Does anyone know what could be the reason?
:(
greep -i error
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20240415201836-r0gt54.log
-bash: greep: no se encontró la orden
[root@host-01 ~]# grep -i error
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20240415201836-r0gt54.log
2024-04-15 20:18:36,751+0200 DEBUG otopi.context context.dumpEnvironment:775
ENV BASE/error=bool:'False'
2024-04-15 20:18:37,219+0200 DEBUG otopi.context context.dumpEnvironment:775
ENV BASE/error=bool:'False'
errorlevel = 3
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54291
socket.gaierror: [Errno -2] Nombre o servicio desconocido
2024-04-15 20:21:25,754+0200 DEBUG otopi.context context.dumpEnvironment:775
ENV BASE/error=bool:'False'
2024-04-15 20:24:45,966+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:109
{'changed': False, 'stdout': '', 'stderr': "error: Falló al obtener la red
'default'\nerror: No se ha encontrado la red: No existe una red que coincida
con el nombre 'default'", 'rc': 1, 'cmd': ['virsh', 'net-undefine', 'default'],
'start': '2024-04-15 20:24:45.653112', 'end': '2024-04-15 20:24:45.737169',
'delta': '0:00:00.084057', 'msg': 'non-zero return code', 'invocation':
{'module_args': {'_raw_params': 'virsh net-undefine default', '_uses_shell':
False, 'warn': False, 'stdin_add_newline': True, 'strip_empty_ends': True,
'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes':
None, 'stdin': None}}, 'stdout_lines': [], 'stderr_lines': ["error: Falló al
obtener la red 'default'", "error: No se ha encontrado la red: No existe una
red que coincida con el nombre 'default'"], '_ansible_no_log': None}
2024-04-15 20:24:46,067+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:109
ignored: [localhost]: FAILED! => {"changed": false, "cmd": ["virsh",
"net-undefine", "default"], "delta": "0:00:00.084057", "end": "2024-04-15
20:24:45.737169", "msg": "non-zero return code", "rc": 1, "start": "2024-04-15
20:24:45.653112", "stderr": "error: Falló al obtener la red 'default'\nerror:
No se ha encontrado la red: No existe una red que coincida con el nombre
'default'", "stderr_lines": ["error: Falló al obtener la red 'default'",
"error: No se ha encontrado la red: No existe una red que coincida con el
nombre 'default'"], "stdout": "", "stdout_lines": []}
2024-04-15 20:24:50,986+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:109
{'changed': False, 'stdout': '', 'stderr': "error: Falló al identificarse la
red default como autoiniciable\nerror: Falló al crear enlace simbólico
'/etc/libvirt/qemu/networks/autostart/default.xml' en
'/etc/libvirt/qemu/networks/default.xml': El fichero ya existe", 'rc': 1,
'cmd': ['virsh', 'net-autostart', 'default'], 'start': '2024-04-15
20:24:49.654500', 'end': '2024-04-15 20:24:50.741081', 'delta':
'0:00:01.086581', 'msg': 'non-zero return code', 'invocation': {'module_args':
{'_raw_params': 'virsh net-autostart default', '_uses_shell': False, 'warn':
False, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None,
'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin':
None}}, 'stdout_lines': [], 'stderr_lines': ['error: Falló al identificarse la
red default como autoiniciable', "error: Falló al crear enlace simbólico
'/etc/libvirt/qemu/networks/autostart/default.xml' en
'/etc/libvirt/qemu/networks/default.xml': El fichero ya existe"],
'_ansible_no_log': None}
2024-04-15 20:24:51,087+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:109
ignored: [localhost]: FAILED! => {"changed": false, "cmd": ["virsh",
"net-autostart", "default"], "delta": "0:00:01.086581", "end": "2024-04-15
20:24:50.741081", "msg": "non-zero return code", "rc": 1, "start": "2024-04-15
20:24:49.654500", "stderr": "error: Falló al identificarse la red default como
autoiniciable\nerror: Falló al crear enlace simbólico
'/etc/libvirt/qemu/networks/autostart/default.xml' en
'/etc/libvirt/qemu/networks/default.xml': El
