[Engine-devel] network features review
avi tal
atal at redhat.com
Tue May 22 12:53:56 UTC 2012
On 05/22/2012 03:06 PM, Livnat Peer wrote:
> On 22/05/12 14:35, avi tal 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)
>> not true. especially in linux we configure "default gateway". unlike
>> windows which holds gateway for each interface, linux holds only one
>> default gateway.
> I'll leave this one to Danken.
Running POC in my machine:
# cat ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=X.Y.129.10
NETMASK=255.255.255.0
GATEWAY=X.Y.129.254
# cat ifcfg-eth2
DEVICE=eth2
ONBOOT=yes
BOOTPROTO=static
IPADDR=X.Y.127.10
NETMASK=255.255.255.0
GATEWAY=X.Y.127.254
# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=...
GATEWAY=X.Y.128.254
# service network restart
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.129.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
X.Y.127.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2
169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3
0.0.0.0 X.Y.127.254 0.0.0.0 UG 0 0 0 eth2
NOTE: we can add static routing to each interface using route-<interface>
>
>>> 2. Why do we block it for networks which are not the management network
>> because otherwise will have to hold the rhevm in the same network with
>> the hosts.
>> only rhevm bridge is protected from remove and if we'll have gateway
>> configured under other network, removing the network will cause losing
>> of our connectivity to the host (in case rhevm and host are in different
>> networks).
>>> 3. We need to support configuring the host default gateway.
>> ^^ 1.
>>>
>>> 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.
>> Agree, actually bootstrap should configure rhevm network as bridgeless
>> network by default.
>> We should be able to convert rhevm to bridged network after installVds.
>>>
>>> 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.
>> I believe we should think about the entire check connectivity mechanism.
>> Check connectivity shouldn't rely on the UI check box, it should also
>> run automatically in some cases:
>
> It should not run automatically because what it does is not only check
> connectivity but also rolls back changes if we loose connectivity.
>
> Let's assume the administrator would like to move the management from
> one network to another, he is doing the configuration through RHEVM,
> looses connectivity and then goes and physically changes the cables.
>
> In the above case it is ok to loose connectivity and I don't want my
> changes to roll back.
>
>
>> 1. edit mgmt network
>> 2. edit other network gateway (if we'll be allowed).
>> 3. MUST, when configuring DHCP on different networks.
>> 4. when running SetupNetwork. because it forces the user to send the
>> management network every time he'd like to update the network.
>> 5. remove network. we should be able to check route table before
>> removing network and if the specific network holds the GATEWAY we should
>> run check connectivity, not before we alert the user.
>>
>> In general, gateway should always be monitored by engine and store in
>> DB: which interface holds the gateway etc'.
>> When we'll be able to do so, we should manage this network (that holds
>> the GW) as a "protected network".
>> And also expose it to the UI.
>>> 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.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
More information about the Engine-devel
mailing list