6:45 p.m.
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.
9:35 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:06 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
10:53 p.m.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
11:54 p.m.
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.
12:42 a.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "avi tal" <atal(a)redhat.com>
Cc: engine-devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:52 p.m.
-----Original Message-----
From: engine-devel-bounces(a)ovirt.org
[mailto:engine-devel-bounces@ovirt.org]
On Behalf Of Livnat Peer
Sent: Tuesday, May 22, 2012 11:46 AM
To: engine-devel(a)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
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)
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),
As above, without vdsm restart, not necessarily machine reboot
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:39 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:02 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
3:31 a.m.
Please forgive the late response and the lengthy remarks, some you may not like :)
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: engine-devel(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4357
days inactive
4357
days old
9 comments
6 participants
participants (6)
-
avi tal -
Dan Kenigsberg -
Igor Lvovsky -
Livnat Peer -
Moti Asayag -
Simon Grinberg