[Engine-devel] network features review
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.
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.
> 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:
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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Tue, May 22, 2012 at 03:53:56PM +0300, avi tal wrote:
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>
I am afraid that I've been misleading Livnat and Simon in private communications. I've repressed this fact for a long while, but apparently initscripts's usage of GATEWAY, be it in interface or hostwide config, is to set the host's default gateway. /etc/sysconfig/network-scripts/ifup-eth : if [ -n "${GATEWAY}" ] ...; then ip route replace default ${METRIC:+metric $METRIC} \ via ${GATEWAY} ${WINDOW:+window $WINDOW} ${SRC} \ ${GATEWAYDEV:+dev $GATEWAYDEV} ... This means that oVirt's current behavior is ok as it is - we set GATEWAY for a single network that is always on, and thus control the host's default gateway.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "avi tal" <atal@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, May 22, 2012 4:54:09 PM Subject: Re: [Engine-devel] network features review
On Tue, May 22, 2012 at 03:53:56PM +0300, avi tal wrote:
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>
I am afraid that I've been misleading Livnat and Simon in private communications. I've repressed this fact for a long while, but apparently initscripts's usage of GATEWAY, be it in interface or hostwide config, is to set the host's default gateway. /etc/sysconfig/network-scripts/ifup-eth :
if [ -n "${GATEWAY}" ] ...; then ip route replace default ${METRIC:+metric $METRIC} \ via ${GATEWAY} ${WINDOW:+window $WINDOW} ${SRC} \ ${GATEWAYDEV:+dev $GATEWAYDEV} ...
This means that oVirt's current behavior is ok as it is - we set GATEWAY for a single network that is always on, and thus control the host's default gateway.
Did not read the entire thread yet, but just relating to this one. Current behaviour is not OK in any case, engine only supports setting default gateway on the management network - not on a selected network. This is not always the case. Actually many times the management network will be segregated where the engine and the nodes are on the same VLAN - no need for default gateway, while the clients are on the remote network thus the default gateway is requested to be on the Display network. The simple solution to properly support a single default gateway as interface independent is to place it in /etc/sysconfig/network. And remove it from a specific network dialogue. Make it a host level config. The only misleading information you gave is that if engine will provide a GATEWAY per network and then a hosts level config in /etc/sysconfig/network this will allow for per network gateway + one default gateway. This is not the case and when testing that I realized it does not work. This is why I did not open the RFE we've discussed I'm still investigating how to support multiple gateways, probably through iproute2 policy tables. However this change is not trivial so I recommend ATM to focus on the relevantly minor change of setting host level gateway and not network level. Simon.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Livnat Peer Sent: Tuesday, May 22, 2012 11:46 AM To: engine-devel@ovirt.org Subject: [Engine-devel] network features review
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
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
management network, it validates that we did not loose connectivity to
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
problem the the 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)
Actually, I think they will not survive even vdsm restart.
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
As above, without vdsm restart, not necessarily machine reboot 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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.
The host IP can be change, however it requires re-installing the host, that runs the bootstrap script.
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
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.
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.
doing more than the above requires substantially more work both in VDSM and engine.
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.
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
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.
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.
The host IP can be change, however it requires re-installing the host, that runs the bootstrap script.
yes, thanks for the clarification.
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
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.
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.
yes, I agree.
doing more than the above requires substantially more work both in VDSM and engine.
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.
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
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
participants (6)
-
avi tal -
Dan Kenigsberg -
Igor Lvovsky -
Livnat Peer -
Moti Asayag -
Simon Grinberg