RE: How to setup a multi vlan connection to an (Ubuntu) XEN-server !!??

["louis.forums@xxxxxxxxx" <lsrbreda@xxxxxxxxx>]

My concerns with that are:
- Ubuntu seems to have deliberately chosen not to use the 
/etc/network/interfaces method. That method seems to be "end of life"
- I am not sure if it is a good idea to use a second config method next to the 
method canonical.com has chosen
- system seems to be the most modern tool and also the tool which structure is 
more logical to me than other methods
( I admit I have no real/practical experience with all of the possible options)

So I am not convinced about that direction yet, apart from the fact that I do 
not know how to define the intended setup (including vlans and multiple routing 
tables etc) using the "/etc/network/interfaces" method.

Louis
-----Original Message-----
From: Xen-users <xen-users-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Simon
Sent: Wednesday, October 5, 2022 7:45 PM
To: xen-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: How to setup a multi vlan connection to an (Ubuntu) XEN-server !!??

louis.forums@xxxxxxxxx <lsrbreda@xxxxxxxxx> wrote:

> I try to configure a Xen server based on the latest Ubuntu server. The server 
> will be connected to a network trunk using vlan's. 

Should be easy enough …

> I hoped this was relatively simple, however it is not. When installing 
> ubuntu-22.04.1-live-server-amd64.iso, I did not manage to setup the network, 
> so I did start digging into the problem. I did open lots of config files 
> searching for the network configuration ........ a crime ..... and discovered 
> that there are tons of (conflicting) tools and related ways to do that. 
>  
>  
> After many hours I discovered that part of the network config was stored in 
> the file "/etc/network/00-installer-config.yaml" and that file was generated 
> by an application called 'subiquity'. 
> By the way subiquity'. is using vconfig is which seems to be deprecated and 
> not ip(route2).  
> I could not find a decent specification of the yami file. I noted that AFTER 
> changing the config an "sudo netplan apply" is needed.
>  
> I also noted that the classic method via "/etc/network/interfaces" 
> does not work anymore and that "systemd.network - Network configuration"  is 
> not used. All files in "/etc/systemd" are at their defaults.
> My feeling is that systend is the most modern way to config the network (I do 
> not have any experience), but that that does not match the way Ubuntu is 
> setup and that all those network setup methods are conflicting with each 
> other.

My personal approach would be to track down and nuke from orbit all supposedly 
“smart” network management tools that are doing nothing but get in the way. 
IMO, none of these sort of tools have a place on a server with a static network 
config.

Once you get down to being able to configure the network via 
/etc/network/interfaces then it becomes fairly easy to do.

As suggested, these days it may be worth looking into openvswitch - but when I 
was doing this, it wasn’t quite mature enough. So I just used the built in 
tools.

The way I did it was :
Rename my physical interfaces to meaningful names - this means that if you 
change hardware in any way, the only place you need to change anything is 
wherever the interface name is configured (used to be 
/etc/udev/rules.d/70-persistent-net.rules).
In the absence of openvswitch, I split out each VLAN to a separate bridge, so 
something along the lines of : bridge “ethnic”, with a member pethtrunk.10; 
bridge “ethext” with member pethtrunk.11; and so on.

> iface ethint init static
>   bridge_ports pethtrunk.10
> iface ethext init static
>   bridge_ports pethtrunk.11

Then you can attach a guest to one or more of the bridges - with each VLAN 
appearing as a separate virtual interface.

I had a mix of trunked and physically separate LANs, so as well a pethtrunk, I 
had a pethext, pethback, and so on - just adjust the bridge declarations 
accordingly.

This obviously only scales so far, so I suspect these days going down the 
openvswitch route may make more sense - and present a trunk interface to the 
guest. But you will still need to track down and terminate with extreme 
prejudice all those tools getting in the way.


Just my 2d worth, Simon