Sure, we always welcome contributions of any kind.
You can post a blog or proposal doc changes at
On Thu, May 10, 2018 at 7:19 AM, Justin Zygmont <jzygmont(a)proofpoint.com>
wrote:
I see, thanks. Maybe I could help add that scenario to the docs for
you?
*From:* Edward Haas [mailto:ehaas@redhat.com]
*Sent:* Wednesday, May 9, 2018 2:26 PM
*To:* Justin Zygmont <jzygmont(a)proofpoint.com>
*Cc:* users(a)ovirt.org
*Subject:* Re: [ovirt-users] routing
On Mon, May 7, 2018 at 7:50 AM, Justin Zygmont <jzygmont(a)proofpoint.com>
wrote:
Thanks for the reply,
Ok I see what you’re saying, its just confusing because there are several
places that mention the gateways and none of them are clear on what they’re
doing.
For example, under Cluster > Networks > Manage Networks, default route is
only selectable for 1 network, yet in each network you create there is
still the option of choosing a IP address and gateway.
On the host there are multiple routing tables, the default main one
contains the default route of the host. Each defined network also maintains
its own routing table, for traffic that it generated or is destined to it
(in case the network has an IP).
So these are not the same things.
Even if I don’t put in any IP or gateway for a tagged vlan, it still
depends of the management gateway to forward to the router. I thought I
should be able to lose the management network and still have all the tagged
vlans working?
Setting an IP on a network is useful if you need the *host* to communicate
with some remote on an IP level.
If you need VM communication, then an IP on a host network is not needed.
The vnics are connected through a bridge, not through a router. So traffic
from a VM is not passing through the L3 stack of the host and its routing
entries on the host do not effect that traffic.
*From:* Edward Haas [mailto:ehaas@redhat.com]
*Sent:* Sunday, May 6, 2018 7:34 AM
*To:* Justin Zygmont <jzygmont(a)proofpoint.com>
*Cc:* users(a)ovirt.org
*Subject:* Re: [ovirt-users] routing
Not sure if I understand what you are asking here, but the need for a
gateway per network has emerged from the need to support other host
networks (not VM networks) beside the management one.
As an example, migration and storage networks can be defined, each passing
dedicated traffic (one for storage communication and another for VM
migration traffic), they may need to pass through different gateways.
So the management network can be accessed using gateway A, storage using B
and migration using C. A will usually be set on a host level as the host
default gateway, and the others will be set for the individual networks.
Otherwise, how would you expect storage to use a different router (than
the management one) in the network?
Thanks,
Edy.
On Thu, May 3, 2018 at 1:08 AM, Justin Zygmont <jzygmont(a)proofpoint.com>
wrote:
I don’t understand why you would want this unless the ovirtnode itself was
actually the router, wouldn’t you want to only have an IP on the management
network, and leave the rest of the VLANS blank so they depend on the router
to route the traffic:
NIC1 -> ovirt-mgmt - gateway set
NIC2 -> VLAN3, VLAN4, etc…
https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks/
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ovirt.org_docume...
*Viewing or Editing the Gateway for a Logical Network*
Users can define the gateway, along with the IP address and subnet mask,
for a logical network. This is necessary when multiple networks exist on a
host and traffic should be routed through the specified network, rather
than the default gateway.
If multiple networks exist on a host and the gateways are not defined,
return traffic will be routed through the default gateway, which may not
reach the intended destination. This would result in users being unable to
ping the host.
oVirt handles multiple gateways automatically whenever an interface goes
up or down.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
<
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ovirt.org_mailm...