On Thu, Jul 30, 2020 at 12:07 AM <thomas@hoberg.net> wrote:
I honestly don't know, because I have not tried myself, so you might just want to stop reading right here.
Same here :-)
But from what I understand about the design philosophy of oVirt, it should be ok to change it, while nobody probably ever tested it and everybody would tell you it's a bad idea to do so, unless you're willing to rebuild from scratch.
The reason it *should* be ok is that the nodes don't care about the management engine. They care only about the information on the shared cluster storage. How that gets there, who changes it: They couldn't care less.
I mostly agree. I am not sure about OVS/OVN. If you do use it, pay extra attention in your tests, before trying this on your production setup.
Yet, I believe I have seen events being reported back to the management engine via REST API calls, referring to the management engine via URIs that should have been using FQDN only. So there is some biliateral communication going on, mostly asynchronous as far as I can see and not using IPs.
Indeed. If you see anything accessing the engine machine using its IP address directly, not through its FQDN, I'd consider it a bug. If such a bug exists in any part of oVirt, please file one. Thanks! As mentioned, not sure about OVS/OVN. If it's indeed so, I'd still consider it a bug, but perhaps it won't be fixed (I am not a networking expert, not sure). I can also see why people might claim that OVS/OVN requires such an exception, even in principle (even if technically you can change it to use names and rely on name resolution).
What I can tell you, is that /etc/sysconfig/network-scripts/ifcfg-eth0 has NM_CONTROLLED=no inside, so nmtui won't go near it. You can change that, delete the line, edit the config... and hopefully it will live.
I assume you refer to the appliance, on hosted-engine. In a standalone engine, we do not really care - it's up to the admin to configure networking etc. Generally speaking, you should follow OS docs. I think that with NM_CONTROLLED=no, you can simply edit the file (or update DHCP), and restart networking (or just reboot).
And in case things go seriously wrong, you should be able to fix it with hosted-engine --console
But, again, I never tried it myself.
But I use DHCP on two out of four farms...
In any case: Please test carefully before doing this on production. Good luck and best regards, -- Didi