12:07 p.m.
Hello,
I'm successfully testing and using OVN on a single host environment with
self hosted engine and 4.1
I'm using ip of ovirtmgmt for the host local ip used for OVN tunneling,
even if actually with a single host it is not so important...
ovirtmgmt bridge is on top ot lacp based bonding
Now I would like to apply it on another environment composed by 3 hosts.
Here ovirtmgmt bridge is on top of an active-backup bonding.
Are there any cons to put the local ip used for tunneling on ovirtmgmt ip?
Any problems/impacts on engine access/functionality using this ip for the
tunnel?
Is in genera OVN considered stable/fully usable in 4.1?
Thanks in advance,
Gianluca
3:55 p.m.
Hello Gianluca,
OVN is a tech preview feature in 4.1
It's 'fully usable' as far as the basic networking functionality goes
(network, ports, subnets), but it's still missing some parts like
authentication, automatci host installation, some of the rest support and
others.
You can use ovirtmgmt for the OVN tunnels. How ovirtmgmt is configured is
also not relevant for OVN.
I am using a similar setup (without bonds) on my dev environment and it's
working fine.
Let me know if this answers your questions.
Thanks,
Marcin
On Wed, Feb 15, 2017 at 10:07 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com
wrote:
Hello,
I'm successfully testing and using OVN on a single host environment with
self hosted engine and 4.1
I'm using ip of ovirtmgmt for the host local ip used for OVN tunneling,
even if actually with a single host it is not so important...
ovirtmgmt bridge is on top ot lacp based bonding
Now I would like to apply it on another environment composed by 3 hosts.
Here ovirtmgmt bridge is on top of an active-backup bonding.
Are there any cons to put the local ip used for tunneling on ovirtmgmt ip?
Any problems/impacts on engine access/functionality using this ip for the
tunnel?
Is in genera OVN considered stable/fully usable in 4.1?
Thanks in advance,
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:59 p.m.
On Wed, Feb 15, 2017 at 1:55 PM, Marcin Mirecki <mmirecki(a)redhat.com> wrote:
Hello Gianluca,
OVN is a tech preview feature in 4.1
It's 'fully usable' as far as the basic networking functionality goes
(network, ports, subnets),
OK, my question was mainly related to negative interference with other
parts of oVirt.
I plan to use it side by side with normal networking so that in the same
Cluster/Datacenter I can have VMs with "legacy" networks, VMs with OVN
provided networks and eventually VMs with a mix of the two.
BTW: I see that while I can hot add an OVN nic to a VM, I cannot hot edit
an OVN nic; I get the error:
Cannot edit Interface. External network cannot be changed while the virtual
machine is running.
Any plan to solve this?
but it's still missing some parts like authentication, automatic
host
installation, some of the rest support and others.
Not a big problem for my tests.
With missing authentication do you mean that I could set up a non-oVirt
host installing controller and driver parts an let it join the others
without control?
Or keystone/similar integration?
You can use ovirtmgmt for the OVN tunnels. How ovirtmgmt is
configured is
also not relevant for OVN.
I am using a similar setup (without bonds) on my dev environment and it's
working fine.
So I could have ovirtmgmt on a vlan based bonding and use it without
problems?
In the sense that the tunnel basically already realizes the isolation from
the ovirtmgmt network itself (what usually we do making vlans) without
interfering in case I have a great exchange of data for example over the
tunnel between 2 VMs placed on different hosts?
BTW: does it make sense to create another vlan on the bonding (that is
already setup with vlans), assigning an ip on the hosts and then use it?
Probably the answer above applies to this too...
In this case is it recommended to do it from inside oVirt itself or one can
do it manually in the OS (supposing plain CentOS configuration for
hypervisors)?
The same question could also apply to a general case where for example my
hosts have to integrate into a dedicated lan in the infrastructure (eg for
backup or monitoring or what else)... would I configure this lan from oVirt
or better from hosts themselves?
Thanks in advance for your time
Gianluca
6:23 p.m.
It should not have any negative interference on configuration issues,
but
it could have a negative impact on performace of your ovirtmgmt network, in
case your OVN traffic saturates the connection.
Cannot edit Interface. External network cannot be changed while the
virtual machine is running.
The error message is incorrect (it predates the introduction of nic
hotplugging)
It is enough to unplug/plug the nic before/after doing changes (the nic
must be in the unplugged state to change it).
As far as I know there is already a bug reported about the error message
being incorrect.
With missing authentication do you mean that I could set up a
non-oVirt
host installing controller and driver parts an let it join the others
without control?
There are two problems that relate to authentication:
- ovirt-provider-ovn does not authenticate request. Currently anyone can
send requests to it, and create/delete networks or ports. This should be
implemented in the near future.
- no authentication to access to OVN databases. A workaround for now could
be putting OVN management traffic on a private network not accessible from
outside. This is be implemented by the OVN team.
In the sense that the tunnel basically already realizes the isolation
from
the ovirtmgmt network itself (what usually we do making vlans) without
interfering in case I have a great exchange of data for example over
the
tunnel between 2 VMs placed on different hosts?
If the traffic going over the tunnel saturates that link, it will interfere
with with your ovirtmgm traffic. For testing this setup should be ok, I
would not recommend it for production.
BTW: does it make sense to create another vlan on the bonding (that is
already setup with vlans), assigning an ip on the hosts and then use it?
The tunnel should take care of the isolation, so I don't think it would add
any value.
The same question could also apply to a general case where for example
my
hosts have to integrate into a dedicated lan in the infrastructure (eg for
backup or monitoring or what else)... would I configure this lan from oVirt
or better from hosts themselves?
Any configuration changes made manually would cause ovirt to see them as
unsynchronized. To do it cleanly you would have to hide the nics used for
this by adding them to 'hidden_nic' in vdsm configuration (nics ignored by
ovirt). Let me know if you want more information on this.
If you need a network to be used by the host, a better solution would be to
just create a separate network from ovirt (a non-vm network if you don't
need a bridge on top of the nic).
Marcin
On Wed, Feb 15, 2017 at 2:59 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
On Wed, Feb 15, 2017 at 1:55 PM, Marcin Mirecki
<mmirecki(a)redhat.com>
wrote:
> Hello Gianluca,
>
> OVN is a tech preview feature in 4.1
> It's 'fully usable' as far as the basic networking functionality goes
> (network, ports, subnets),
>
OK, my question was mainly related to negative interference with other
parts of oVirt.
I plan to use it side by side with normal networking so that in the same
Cluster/Datacenter I can have VMs with "legacy" networks, VMs with OVN
provided networks and eventually VMs with a mix of the two.
BTW: I see that while I can hot add an OVN nic to a VM, I cannot hot edit
an OVN nic; I get the error:
Cannot edit Interface. External network cannot be changed while the
virtual machine is running.
Any plan to solve this?
> but it's still missing some parts like authentication, automatic host
> installation, some of the rest support and others.
>
Not a big problem for my tests.
With missing authentication do you mean that I could set up a non-oVirt
host installing controller and driver parts an let it join the others
without control?
Or keystone/similar integration?
> You can use ovirtmgmt for the OVN tunnels. How ovirtmgmt is configured is
> also not relevant for OVN.
> I am using a similar setup (without bonds) on my dev environment and it's
> working fine.
>
So I could have ovirtmgmt on a vlan based bonding and use it without
problems?
In the sense that the tunnel basically already realizes the isolation from
the ovirtmgmt network itself (what usually we do making vlans) without
interfering in case I have a great exchange of data for example over the
tunnel between 2 VMs placed on different hosts?
BTW: does it make sense to create another vlan on the bonding (that is
already setup with vlans), assigning an ip on the hosts and then use it?
Probably the answer above applies to this too...
In this case is it recommended to do it from inside oVirt itself or one
can do it manually in the OS (supposing plain CentOS configuration for
hypervisors)?
The same question could also apply to a general case where for example my
hosts have to integrate into a dedicated lan in the infrastructure (eg for
backup or monitoring or what else)... would I configure this lan from oVirt
or better from hosts themselves?
Thanks in advance for your time
Gianluca
6:43 p.m.
On Wed, Feb 15, 2017 at 4:23 PM, Marcin Mirecki <mmirecki(a)redhat.com> wrote:
It should not have any negative interference on configuration
issues,
but
it could have a negative impact on performace of your ovirtmgmt network,
in case your OVN traffic saturates the connection.
>Cannot edit Interface. External network cannot be changed while the
virtual machine is running.
The error message is incorrect (it predates the introduction of nic
hotplugging)
It is enough to unplug/plug the nic before/after doing changes (the nic
must be in the unplugged state to change it).
As far as I know there is already a bug reported about the error message
being incorrect.
OK. I just verified that it works as you described, thanks
>In the sense that the tunnel basically already realizes the
isolation
from the ovirtmgmt network itself (what usually we do making vlans) without
>interfering in case I have a great exchange of data for example over the
tunnel between 2 VMs placed on different hosts?
If the traffic going over the tunnel saturates that link, it will
interfere with with your ovirtmgm traffic. For testing this setup should be
ok, I would not recommend it for production.
OK, but at least the packets would be invisible to the ovirtmgmt network
I mean, typically on the same adapter you put separate vlans to segregate
traffic. This doesn't give you the double of the bandwidth but the
isolation of the network so that it doesn't to go and inspect the packet to
see what is the target and so on...
Does this make sense in this way for the tunnel too or nothing at all?
>BTW: does it make sense to create another vlan on the bonding (that is
already setup with vlans), assigning an ip on the hosts and then use it?
The tunnel should take care of the isolation, so I don't think it would
add any value.
>The same question could also apply to a general case where for example my
hosts have to integrate into a dedicated lan in the infrastructure (eg for
backup or monitoring or what else)... would I configure this lan from oVirt
or better from hosts themselves?
Any configuration changes made manually would cause ovirt to see them as
unsynchronized. To do it cleanly you would have to hide the nics used for
this by adding them to 'hidden_nic' in vdsm configuration (nics ignored by
ovirt). Let me know if you want more information on this.
If you need a network to be used by the host, a better solution would be
to just create a separate network from ovirt (a non-vm network if you don't
need a bridge on top of the nic).
Ah, I see. I think the relevant lines in vdsm.conf are:
# Comma-separated list of fnmatch-patterns for host nics to be hidden
# from vdsm.
# hidden_nics = w*,usb*
# Comma-separated list of fnmatch-patterns for host bonds to be hidden
# from vdsm.
# hidden_bonds =
# Comma-separated list of fnmatch-patterns for host vlans to be hidden
# from vdsm. vlan names must be in the format "dev.VLANID" (e.g.
# eth0.100, em1.20, eth2.200). vlans with alternative names must be
# hidden from vdsm (e.g. eth0.10-fcoe, em1.myvlan100, vlan200)
# hidden_vlans =
And in case I have to create some file of type 01_hidden.conf in
/etc/vdsm/vdsm.conf.d/ to preserve across upgrades, correct?
Gianluca
11:54 a.m.
OVN is aleady using GENEVE, VXLAN or STT tunnels (the user can choose any),
so the isolation is already assured.
The scripts provided by ovirt configure a geneve tunnel.
You are free so override this manually to vxlan or stt if you want, let me
know if you need any howto info.
On Wed, Feb 15, 2017 at 4:43 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
On Wed, Feb 15, 2017 at 4:23 PM, Marcin Mirecki
<mmirecki(a)redhat.com>
wrote:
> It should not have any negative interference on configuration issues,
> but
> it could have a negative impact on performace of your ovirtmgmt network,
> in case your OVN traffic saturates the connection.
>
> >Cannot edit Interface. External network cannot be changed while the
> virtual machine is running.
> The error message is incorrect (it predates the introduction of nic
> hotplugging)
> It is enough to unplug/plug the nic before/after doing changes (the nic
> must be in the unplugged state to change it).
> As far as I know there is already a bug reported about the error message
> being incorrect.
>
OK. I just verified that it works as you described, thanks
> >In the sense that the tunnel basically already realizes the isolation
> from the ovirtmgmt network itself (what usually we do making vlans) without
> >interfering in case I have a great exchange of data for example over the
> tunnel between 2 VMs placed on different hosts?
> If the traffic going over the tunnel saturates that link, it will
> interfere with with your ovirtmgm traffic. For testing this setup should be
> ok, I would not recommend it for production.
>
OK, but at least the packets would be invisible to the ovirtmgmt network
I mean, typically on the same adapter you put separate vlans to segregate
traffic. This doesn't give you the double of the bandwidth but the
isolation of the network so that it doesn't to go and inspect the packet to
see what is the target and so on...
Does this make sense in this way for the tunnel too or nothing at all?
>
>
> >BTW: does it make sense to create another vlan on the bonding (that is
> already setup with vlans), assigning an ip on the hosts and then use it?
> The tunnel should take care of the isolation, so I don't think it would
> add any value.
>
> >The same question could also apply to a general case where for example
> my hosts have to integrate into a dedicated lan in the infrastructure (eg
> for backup or monitoring or what else)... would I configure this lan from
> oVirt or better from hosts themselves?
> Any configuration changes made manually would cause ovirt to see them as
> unsynchronized. To do it cleanly you would have to hide the nics used for
> this by adding them to 'hidden_nic' in vdsm configuration (nics ignored by
> ovirt). Let me know if you want more information on this.
> If you need a network to be used by the host, a better solution would be
> to just create a separate network from ovirt (a non-vm network if you don't
> need a bridge on top of the nic).
>
Ah, I see. I think the relevant lines in vdsm.conf are:
# Comma-separated list of fnmatch-patterns for host nics to be hidden
# from vdsm.
# hidden_nics = w*,usb*
# Comma-separated list of fnmatch-patterns for host bonds to be hidden
# from vdsm.
# hidden_bonds =
# Comma-separated list of fnmatch-patterns for host vlans to be hidden
# from vdsm. vlan names must be in the format "dev.VLANID" (e.g.
# eth0.100, em1.20, eth2.200). vlans with alternative names must be
# hidden from vdsm (e.g. eth0.10-fcoe, em1.myvlan100, vlan200)
# hidden_vlans =
And in case I have to create some file of type 01_hidden.conf in
/etc/vdsm/vdsm.conf.d/ to preserve across upgrades, correct?
Gianluca
12:40 p.m.
On Thu, Feb 16, 2017 at 9:54 AM, Marcin Mirecki <mmirecki(a)redhat.com> wrote:
OVN is aleady using GENEVE, VXLAN or STT tunnels (the user can
choose
any), so the isolation is already assured.
The scripts provided by ovirt configure a geneve tunnel.
You are free so override this manually to vxlan or stt if you want, let me
know if you need any howto info.
yes, please.
I have used in the mean time the vdsm-tool command that takes care of
creating the default geneve tunnel
In my case
vdsm-tool ovn-config 10.4.168.80 10.4.168.81
but I would like to know how to manually use other types too.
I watched the deep dive demo about ovn but at the bottom of the related
slide there are three lines that should be equivalent to the above command,
something like
ovs-vsctl set open ? external-ids:ovn-remote=tcp:10.4.168.80:6642
ovs-vsctl set open ? external-ids:ovn-encap=type=geneve
ovs-vsctl set open ? external-ids:ovn-encap-ip=10.4.168.81
The ? character seems a dot or a comma, I have not understood the
syntax....
(what are the accepted words for type= in the second line?)
Thanks again,
Gianluca
11:22 p.m.
From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
To: "Marcin Mirecki" <mmirecki(a)redhat.com>
Cc: "Ovirt Users" <users(a)ovirt.org>
Sent: Thursday, February 16, 2017 4:40:46 AM
Subject: Re: [ovirt-users] questions on OVN
On Thu, Feb 16, 2017 at 9:54 AM, Marcin Mirecki < mmirecki(a)redhat.com >
wrote:
OVN is aleady using GENEVE, VXLAN or STT tunnels (the user can choose any),
so the isolation is already assured.
The scripts provided by ovirt configure a geneve tunnel.
You are free so override this manually to vxlan or stt if you want, let me
know if you need any howto info.
A small correction/clarification: for hypervisor-hypervisor tunnels, the
only tunnel encapsulations that are currently supported are GENEVE and STT.
The rationale is explained in detail at
http://openvswitch.org/support/dist-docs/ovn-architecture.7.html in the
"Design Decisions" section. VXLAN tunnels are supported for hypervisor-gateway
tunnels only.
yes, please.
I have used in the mean time the vdsm-tool command that takes care of
creating the default geneve tunnel
In my case
vdsm-tool ovn-config 10.4.168.80 10.4.168.81
but I would like to know how to manually use other types too.
I watched the deep dive demo about ovn but at the bottom of the related slide
there are three lines that should be equivalent to the above command,
something like
ovs-vsctl set open ? external-ids:ovn-remote=tcp: 10.4.168.80:6642
ovs-vsctl set open ? external-ids:ovn-encap=type=geneve
ovs-vsctl set open ? external-ids:ovn-encap-ip=10.4.168.81
The ? character seems a dot or a comma, I have not understood the syntax....
(what are the accepted words for type= in the second line?)
The syntax here is "ovs-vsctl set <table> <record>
<column>[:<key>]=<value>...".
In this case, the table name is "Open_vSwitch", "open" can be used as
a
shorthand because the table name is not case-sensitive and prefixes of
the table name are accepted as long as they are unique.
The "." character specifies the record name as explained in the ovs-vsctl man
page at http://openvswitch.org/support/dist-docs-2.5/ovs-vsctl.8.txt:
Open_vSwitch
Global configuration for an ovs-vswitchd. This table contains
exactly one record, identified by specifying . as the record
name.
Valid settings for external-ids:ovn-encap-type= are given in the ovn-controller
man page http://openvswitch.org/support/dist-docs-2.5/ovn-controller.8.txt:
external_ids:ovn-encap-type
The encapsulation type that a chassis should use to con‐
nect to this node. Multiple encapsulation types may be
specified with a comma-separated list. Each listed
encapsulation type will be paired with ovn-encap-ip.
Supported tunnel types for connecting hypervisors are
geneve and stt. Gateways may use geneve, vxlan, or stt.
Due to the limited amount of metadata in vxlan, the capa‐
bilities and performance of connected gateways will be
reduced versus other tunnel formats.
Hope this helps,
Lance
Thanks again,
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:19 p.m.
I missed the last line.
A vdsm configuration is created from a default vdsm configuration file
under /etc/vdsm/vdsm.conf. Then it reads conf files from drop-in dirs and
updates the configuration according to the files:
- /etc/vdsm/vdsm.conf - for user configuration. We install this file if
missing, and never touch this file during upgrade.
- /etc/vdsm/vdsm.conf.d/ - for admin drop-in conf files.
- /usr/lib/vdsm/vdsm.conf.d/ - for vendor drop-in configuration files.
- /var/run/vdsm/vdsm.conf.d/ - for admin temporary configuration.
Files with a .conf suffix can be placed into any of the vdsm.conf.d drop-in
directories.
The priority of the configuration files is determined by the number prefix
of each file.
On Wed, Feb 15, 2017 at 4:43 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
On Wed, Feb 15, 2017 at 4:23 PM, Marcin Mirecki
<mmirecki(a)redhat.com>
wrote:
> It should not have any negative interference on configuration issues,
> but
> it could have a negative impact on performace of your ovirtmgmt network,
> in case your OVN traffic saturates the connection.
>
> >Cannot edit Interface. External network cannot be changed while the
> virtual machine is running.
> The error message is incorrect (it predates the introduction of nic
> hotplugging)
> It is enough to unplug/plug the nic before/after doing changes (the nic
> must be in the unplugged state to change it).
> As far as I know there is already a bug reported about the error message
> being incorrect.
>
OK. I just verified that it works as you described, thanks
> >In the sense that the tunnel basically already realizes the isolation
> from the ovirtmgmt network itself (what usually we do making vlans) without
> >interfering in case I have a great exchange of data for example over the
> tunnel between 2 VMs placed on different hosts?
> If the traffic going over the tunnel saturates that link, it will
> interfere with with your ovirtmgm traffic. For testing this setup should be
> ok, I would not recommend it for production.
>
OK, but at least the packets would be invisible to the ovirtmgmt network
I mean, typically on the same adapter you put separate vlans to segregate
traffic. This doesn't give you the double of the bandwidth but the
isolation of the network so that it doesn't to go and inspect the packet to
see what is the target and so on...
Does this make sense in this way for the tunnel too or nothing at all?
>
>
> >BTW: does it make sense to create another vlan on the bonding (that is
> already setup with vlans), assigning an ip on the hosts and then use it?
> The tunnel should take care of the isolation, so I don't think it would
> add any value.
>
> >The same question could also apply to a general case where for example
> my hosts have to integrate into a dedicated lan in the infrastructure (eg
> for backup or monitoring or what else)... would I configure this lan from
> oVirt or better from hosts themselves?
> Any configuration changes made manually would cause ovirt to see them as
> unsynchronized. To do it cleanly you would have to hide the nics used for
> this by adding them to 'hidden_nic' in vdsm configuration (nics ignored by
> ovirt). Let me know if you want more information on this.
> If you need a network to be used by the host, a better solution would be
> to just create a separate network from ovirt (a non-vm network if you don't
> need a bridge on top of the nic).
>
Ah, I see. I think the relevant lines in vdsm.conf are:
# Comma-separated list of fnmatch-patterns for host nics to be hidden
# from vdsm.
# hidden_nics = w*,usb*
# Comma-separated list of fnmatch-patterns for host bonds to be hidden
# from vdsm.
# hidden_bonds =
# Comma-separated list of fnmatch-patterns for host vlans to be hidden
# from vdsm. vlan names must be in the format "dev.VLANID" (e.g.
# eth0.100, em1.20, eth2.200). vlans with alternative names must be
# hidden from vdsm (e.g. eth0.10-fcoe, em1.myvlan100, vlan200)
# hidden_vlans =
And in case I have to create some file of type 01_hidden.conf in
/etc/vdsm/vdsm.conf.d/ to preserve across upgrades, correct?
Gianluca
2834
days inactive
2835
days old
8 comments
3 participants
participants (3)
-
Gianluca Cecchi -
Lance Richardson -
Marcin Mirecki