[libvirt] [PATCH] v2:Support for adding a static route to a bridge

Laine Stump laine at laine.org
Wed Apr 10 19:11:57 UTC 2013


On 04/10/2013 01:38 PM, Gene Czarcinski wrote:
> On 04/09/2013 04:28 PM, Gene Czarcinski wrote:
>> OK, how about having it both ways.  If we can have both mask and
>> prefix, why not both via and gateway.  I know gateway has some
>> history attached to it but the new /sbin/ip uses via.  I am just
>> trying to keep a line of text being as close to not exceeding 80
>> characters as practical.  Correct me if I am wrong but all of this is
>> suppose to be free-form and this should be valid:
>>
>>         <route ip='ipv6'  address='fd00:dead:beef:472::1' prefix='64'
>>                     gateway='fd00:dead:beef:10::2'  />
>>
>> Of course, when it gets written back out by code it will all be on a
>> "single" line.
>>
>> How about one of you other folks chiming in on this.  gateway? ...
>> via? ... anybody (besides the two of us) care??
> OK, unless someone can present a convincing argument, I am going with
> "via" and not "gateway".  Thus, the general form is:
>     <route  family=... address=... prefix=... via=... />
>     </route>
>
> Why "via" and not "gateway".  Well, /sbin/ip uses "via" whereas
> /sbin/route uses "gateway".  If there was a convincing argument to
> keep gateway instead off via, the /sbin/ip code would be different or
> would be changed to  gateway.  BTW, IMHO, netmask could disappear also
> and have prefix= only.


Nope. In libvirt *nothing* can ever disappear. We try our hardest to
provide 100% backward compatibility for existing applications (and have
so far been successful at it).

>
> Also, the current implementation enforces that the address specified
> with via= must be resolvable into a network-address which has been
> defined for the interface.  That is, you cannot point via= off into
> some address that the virtualization host has no idea where it is.

Right. It must be directly reachable by the network/interface it's added to.




More information about the libvir-list mailing list