Please forgive the late response and the lengthy remarks, some you may not like :) ----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, May 22, 2012 4:02:11 PM Subject: Re: [Engine-devel] network features review
On 22/05/12 15:39, Moti Asayag wrote:
On 05/22/2012 11:45 AM, Livnat Peer wrote:
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.
Bootstarp does not support most of the possible network configuration. It will fail if there is already a non bridged bond/Vlan etc. I think that what should be done here is nothing, the bootstrap need not touch the network configuration at all. All the admin has to do is verify that the host has connectivity to the engine Then 1. On initial setup on the engine side, before adding any host allow to edit the management network properties. (Vlan/VM network/MTU etc) 2. Allow to add the host 3. Use setup-networks to assign the management network according to the topology selected by the admin. It can be done easily by allowing the user to detach it and then attach. As long as it is within the context of the edit menu before he hits OK this is allowed. The above should allow for any supported network configuration to be applied without all the issues and limitations around that ATM. It also simplifies the bootstrap - it does not care about 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).
See the suggestion above it also solves this scenario.
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.
Agree, and this is should be always the default.
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,
Again the solution suggested above solves this too.
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.
If the IP is on the same network - you should be able to do so. But this is not the problem, usually the need to change an IP is not during host/node installation, so there is no problem here, if the user wants a different IP at installation phase he need to set it before he adds the host/node, thus you only need to worry about IP changes for already added host (see comment below)
The host IP can be change, however it requires re-installing the host, that runs the bootstrap script.
yes, thanks for the clarification.
As I recall this is true if the cert is created based on IP and not FQDN. The re-install is required to replace the certs. What should be done is to use FQDN to create the certs and not the IP. This should allow for change of the rhevm network IP as long as it resolves to the same FQDN. I think this was fixed when installing using boot strap or add a node from the New host button (But can't be sure). When doing from the node, then last time I checked it still uses the IP of the host.
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'.
Also missing indication that a network topology change has been applied but not saved. This lead into situations where after setting a configuration and it works the user forgets to save. Everything works well until the first reboot of the node/host. This may happen days/weeks/months after the actual configuration has been changed so the user may not understand what has happened (/me old geezer with bad memory has done it more then once :))
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
minor correction: There are 5 bonds, named bond0-4.
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.
+1
Modifying a cluster network with hosts in it seems problematic, since we'd have to propagate the network changes to the hosts. E.g. updating a network to be bridge-less, or tagging a network.
Perhaps we should allow updating a network only if the clusters have no hosts at all.
I like the first option better. I understand the complexity of having mixed mode so I won't dare suggesting doing the propagation on live hosts (Though on some properties this should be possible) however you can relax the above a bit and just request maintenance. Then upon activation, if networks properties are different then the current definition update the host (actually you don't have to check, just send new topo) There is a difference between placing 100 hosts into maintenance and between placing into maintenance, removing them, change definition and then re-adding. I just changed 3 host and it was irritating. I had to: 1. Place them all into maintenance 2. Move them into temp cluster with no network requirements 3. Change the network 4. Move the hosts back 5. Activate. With the suggest above only steps 1 and 5 are required.
yes, I agree.
doing more than the above requires substantially more work both in VDSM and engine.
Not that much considering what the user will have to do (look at the suggested solution) - it will pay back after the first user that forgot to set a network as vm-network after adding few hosts and calls support.
Another missing behavior is the capability to refresh Host nics by demand. At the moment it is enabled by activating a host, which requires moving the host to maintenance first or when facing network issues. Else, changes on host nics will not reflect to the ovirt-engine.
I agree this functionality comes from different areas, not only networking, running getVdsCaps on demand.
getVdsCaps is nothing compared to getAllVmsStats and you do the later every 10 seconds right? so why bother with on demand, why not just read it once a minute? When the update logic was created hot plug HW, virtual devices (NICs), etc was only a musing new comer, now with UCS and it's like it is a reality. There is no reason not to just update periodically.
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. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel