On Tue, Sep 27, 2022 at 5:22 PM Matthew J Black <matthew(a)peregrineit.net>
wrote:
I need a quick piece of advice, please.
I'm at setting up the oVirt Engine VM (ie doing a "hosted-engine
--deploy") stage.
The Host has 3 NICs.
NIC_1 and NIC_2 are bonded (bond1) and run 2 VLANs (on bond1.1 and
bond1.2).
VLAN_1 is to be used as the "everyday connection VLAN for the VMs"
(including the oVirt Engine VM - I think).
VLAN_2 is *only* to be used for data traffic to-and-from our Ceph Cluster
(ie via the Ceph iSCSI Gateway Nodes).
NIC_3 (running VLAN_3) is to be used for oVirt-host-to-oVirt-host comms
(including "local" Gluster traffic - yes, the (oVirt) hosts are running a
couple of Gluster drives).
My question is: Which interface should we use for the "ovirtmgmt" Bridge?
I suspect it should be NIC_3 (VLAN_3), and I'm 99.999% sure it *shouldn't*
be bond1.2 (VLAN_2), but it might be bond1.1 (VLAN_1), so I thought I'd
better get peoples' input.
You see, I'm not sure what the purpose of the "ovirtmgmt" bridge is. Is it
for humans to talk to the oVirt Engine, or is it for the oVirt Engine to
talk to the VMs (and hosts), or is it for some other purpose, or is it for
some combination of the these? (I have read the doco on the ovirtmgmt
bridge, and I'm still somewhat confused.)
So, if someone wouldn't mind getting back to me about this, I'd appreciate
it.
Cheers
Dulux-Oz
In general the IP on the ovirtmgmt bridge is the one used to connect to the
engine server (eg for web admin gui access and ssh access to the server to
check logs and so on) and it is also used for mgmt communication between
engine and hosts.
So the choice of the adapter/bond should take this into consideration.
No VMs involved and no need to use that logical network (the ovirtmgmt one)
also for VMs virtual nics, but you can do it if needed/practical (eg lab or
small environments).
The must in general is that the network where you decide to put the engine
IP has to be routable with the networks where you decide to put the IPs of
your hosts (eg host1 could be on network1 and host2 in network2, with both
network1 and network2 routable with the network where the engine IP lives).
In the case of a Self Hosted Engine environment (engine as a VM inside the
oVirt infra that it manages), you start the deployment process using a
command on one server that will become at the end one of the managed hosts
(hypervisors). So in general for the ovirtmgmt bridge you will use the
network and so the adapter/bond that you use when you connect from your
client to the host through ssh to start the whole process with the
"hosted-engine --deploy" command.
See also this for temporary IP allocation for the self hosted engine
appliance (downstream RHV links provided, but quite the same for oVirt):
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/...
Also these:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/...
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/...
and review the deploy process flow:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/...
HIH,
Gianluca