[Engine-devel] network features review

Livnat Peer lpeer at redhat.com
Tue May 22 08:45:38 UTC 2012


Hi All,

This is a summary of comments we(*) gathered while reviewing the current
network related functionality in oVirt, we'll open the relevant RFE/Bugs
but wanted to share first to get comments:


Default Gateway:
----------------
current status -
  In the UI/API we expose to the user the possibility to configure the
  default gateway for the host. We expose this option only when editing
  the management network.

comments -
Apparently we do not configure the host default gateway but the
network gateway.

1. We need to fix the phrasing to gateway (not default gateway)
2. Why do we block it for networks which are not the management network
3. We need to support configuring the host default gateway.


Non VM (Bridge-less) Network:
-----------------------------
current status -
During bootstrap we configure the management network on the host. We did
not implement configuring bridge-less management network during bootstrap.

comments -
1. Supporting bridge-less network is a new feature,the design of this
feature did not include changing the bootstrap process which make this
feature non-useful when it comes to management network.

Today one can edit a network only when it is not attached to clusters,
at this point you can change the management network to be non-VM
network, the problem is that we configure the management network on the
host during bootstrap and we do not get a parameter if to create a
bridge or not (we always create a bridge).

What we end up with is - we can't change the management network once we
added clusters/hosts but if changing it before attaching a cluster we
ignore it in the bootstrap process.


Check connectivity:
--------------------
current status -
The 'check connectivity' functionality is available only when editing
the management network, it validates that we did not loose connectivity
to the host, if we did the changes are rolled backed automatically.

comments -
1. Sometimes when changing configuration of another network we can
'damage' the connectivity to the host. We want to expose the check
connectivity functionality on any network configuration change.

VLAN tagging of management Network
-----------------------------------

current status -
The user can set a VLAN tag on the management network.

comments -
1. Any configuration of the management network needs support in the
bootstrap process (see explanation above for bridge-less network)
2. In case of VLAN tagging it is even more complicated, when adding a
host to oVirt we add it's address and it can not be changed after the
host was added to the system. in the bootstrap process we set the
management network on the nic oVirt engine used to ssh through, unless
the VLAN device is already configured and the IP used for the ssh is
already on this VLAN (for which it will work) we can't set the network
to be on another IP address.

Rollback network configuration:
--------------------------------
current status -
 We have the option to make changes to the host network configuration
and not persist the changes (they won't survive machine reboot)

comments -
1. We are missing the functionality of rolling back the changes (without
rebooting the machine), this functionality is the complementary behavior
of 'save network configuration'.


Predefined bonds:
-----------------
current status -
In the bootstrap process we create bonds0-5 on the hosts and then
we use them when creating a bond on the host

comments -
1. Creating the bonds in the host during the bootstrap process is not
needed and we can let the user choose the bond name (limited to bondX)
and create bonds only upon request.


Editing Network properties while Network is attached to cluster/s
------------------------------------------------------------------
current status -
Changing the network properties is blocked if the network is attached to
a cluster.

comments -
1. We should relax this approach. to start with we can enable editing
when there are no active hosts in the cluster/s.

doing more than the above requires substantially more work both in VDSM
and engine.



Thank you, Livnat


(*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag,
Muli Salem, Alona Kaplan, Livnat Peer}

(**) We have even longer list for the UI changes needed, for them we'll
open bugs directly to avoid another long email.



More information about the Engine-devel mailing list