On Sun, Apr 11, 2021 at 2:45 PM David White via Users <users@ovirt.org> wrote:
> Thanks for the response here. > Unfortunately, things are still not 100% stable after I performed that > host upgrade. > It appears to me that 1 of the hosts keeps booting back with the old > management vlan (VLAN 1) instead of the new vlan (VLAN 10). > > I'm able to (mostly) fiddle around with it and get it back online, but it > seems like every reboot, vlan 1 comes back, and breaks connectivity with > the other two hosts. > I also didn't realize, until late yesterday afternoon, that you could use > the oVirt Manager web UI to configure each host's network settings. > > This whole time, I've been trying to use nmcli, nmtui, and manually > editing /etc/sysconfig/network-scripts/ files by hand. > When I found the network settings inside of the Engine / manager web UI, I > discovered that, for example, oVirt Engine manager saw that the new vlan > (VLAN 10) was "unmanaged" by the engine. > *Question: *Would you recommend that all network settings be modified by > the oVirt engine instead of the manual process on the OS? > I think so, but that's not my expertise. Adding Eitan. > > *Question: *Is it possible to setup a vlan inside the engine *without* an > IP address being assigned to each of the physical hosts? > I was really hoping to setup VLAN 100 with public IP addresses, and use > layer 2 switching to send that traffic into the oVirt cluster. > Eitan? > > Here is a screenshot overview of what I want my environment to look like, > logically. You'll note that I was going to put VLAN 20 and VLAN 100 onto > the same host physical interface. > This is what I - and I think the oVirt documentation - refers to as the > front-end traffic. > VLAN 10 is/was going to be on its own interface going to the 10Gbps switch. > > *Question: *Do you see anything "wrong" with this picture? Are there ways > I can / should change it to improve? > Eitan? You might also want to have a look at this somewhat-outdated-but-still-mostly-relevant document, for RHV, probably applies 99% to oVirt as well: https://www.redhat.com/en/resources/best-practice-rhv-technology-detail > > As for the /etc/hosts files, I'm actually doing that. > However, as I'm typing this, I realized that I never defined the Engine IP > address in the hosts, nor do I put anything inside the Engine's /etc/hosts > file. > *Question: *Perhaps this was part of my problem, when DNS connectivity > was not working. Thoughts? > Not sure about "general" hosts, but hosted-engine hosts definitely need to be able to connect to the engine (at least, for making sure it's alive), so need it to be locally-resolvable. If you plan to run DNS inside a VM, you definitely want the engine machine's IP in /etc/hosts on all hosted-engine hosts. And probably have some kind of automation for making sure this is up-to-date... Good luck, > > Thanks again, > David > > [image: Screenshot from 2021-04-10 17-21-39.png] > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Sunday, April 11, 2021 3:05 AM, Yedidyah Bar David <d...@redhat.com> > wrote: > > On Sat, Apr 10, 2021 at 1:14 PM David White via Users <users@ovirt.org> > wrote: > >> This is resolved, and my environment is 100% stable now. >> > > Glad to hear that, thanks for the report! > > >> >> Or was, until I then used the engine to "upgrade" one of the hosts, at >> which point I started having problems again after the reboot, because the >> old vlan came back. >> I'll finish getting things stabilized today, and hopefully won't run into >> this again. >> >> I've been turning things on and off quite a bit, because they aren't in a >> proper data center (yet) and are just sitting here in my home office. >> So I'm sure shutting them down and turning them back on fairly often >> hasn't helped the situation. >> >> I initially had a few issues going on: >> >> 1. I of course first broke things when I tried to change the >> management vlan >> 2. Aside from my notes below and the troubleshooting steps I went >> through, yesterday, I had forgotten that connectivity to the DNS server >> hadn't been restored. Once I got DNS operational, the engine was able to >> see two of the hosts, and finally started showing some green. >> 3. I then went in and ran `hosted-engine --vm-stop` to shutdown the >> engine, and then I started it again... and viola. The last remaining >> problematic host came online, and a few minutes later, the disks, volumes, >> and datacenter came online. >> 4. I think part of my problem has been this switch. I purchased a >> Netgear GS324T for my frontend traffic. But I've also needed to put my >> backend traffic onto some temporary ports on that switch until I can get a >> VM controller setup that will run my other switch, a Ubiquiti US-XG-16 for >> my permanent backend traffic. The Netgear hasn't been nearly as simple to >> configure as I had hoped. The vlan behavior has also been inconsistent - >> sometimes I have vlan settings in place, and things work. Sometimes they >> don't work. It has also been re-assigning a of the vlans occasionally >> after >> reboots, which has been frustrating. I'm close to being completely done >> configuring the infrastructure, but I'm also getting increasingly tempted >> to go find a different switch. >> >> Lessons learned: >> >> 1. Always make sure DNS is functional >> 1. I was really hoping that I could run DNS as a VM (or multiple VMs) >> *inside* the cluster. >> 2. That said, if the cluster and the engine won't even start >> correctly without, then I may need to run DNS externally. I'm open to >> feedback on this. >> 1. I have 1 extra U of space at the datacenter reserved, and I do >> have a 4th spare server that I haven't decided what to do with yet. >> It has >> way more CPU and RAM than would be necessary to run an internal DNS >> server... but perhaps I have no choice. *Thoughts*? >> >> > You can also have the IP addresses of the engine and hosts in /etc/hosts > of all machines (engine and hosts) - then things should work fine. It does > mean you'll have to manually maintain these hosts files somehow. > > >> >> 1. >> 1. Make sure your vlan settings are correct *before* you start >> deploying the hosted engine and configure oVirt. >> >> > Definitely. As well as making sure that IP addresses (and netmasks, > routes, etc.) are as intended and working, name resolution is correct (DNS > or /etc/hosts), etc. . > > >> >> 1. >> 2. If possible, don't turn off and turn on your servers constantly. >> :) I realize this is a given. I just don't have much choice in the matter >> right now, due to lack of datacenter in my home office. >> >> > While definitely not recommended, in principle this should be harmless. If > you find concrete reproducible bugs around this, please report them (with > clear accurate details - just "I turn off and on my hosts and things stop > working" is not helpful, obviously...). > > Thanks again and best regards, > > >> > > 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/6TWZCFKAYF75GFCZQ4DBBWM53LHSWV2O/ >> > > > -- > Didi > > > _______________________________________________ > 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/NQQPZMLIDCVYH3GC4VGXELRLS7RSYDJ7/ > -- Didi
_______________________________________________ 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/LH26FDODF6NM4N3XD6IK2BQE6LE7W6T2/
