tag must be greater than 1 (ve 4)

[gimpbully]

Updated from the last beta to the stable ve 4 and got the following on trying to start any of my containers:

root@eduardo:~# pct start 100
vm 100 - unable to parse value of 'net0' - format error at /usr/share/perl5/PVE/JSONSchema.pm line 529
tag: value must have a minimum value of 2
format error at /usr/share/perl5/PVE/JSONSchema.pm line 529
tag: value must have a minimum value of 2
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 346 To get more details, run the container in foreground mode.
lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.
root@eduardo:~#

Changing my tag to 2 in /etc/network/interfaces as well as the container config fixes the issue but... why is this a limitation?

 

[blood]

I'm hitting this too running: pve-manager/4.0-48/0d8559d0 (running kernel: 4.2.0-1-pve) - This started as 4.0 beta 1, but has been brought forward.In case it matters I'm using Open vSwitch rather than kernel bridges. I followed the directions from the wiki article on Open vSwitch that say to apply a VLAN tag for untagged physical ports, and then to use that tag for VMs/containers that you want to use it. I chose tag 1 because although the physical interface is untagged, it's a member of VLAN 1 on the physical switch. It is working fine for a handful of VMs and containers with tag 1, but now when I add another container to VLAN 1 I get the error about needing to use at least VLAN 2. I forget whether this is the first container that I've added since upgrading from beta1 or not.Editing the config file for the container or VM and adding "tag=1" works, so this appears to just be a validation error. With that in mind, /usr/share/perl5/PVE/LXC.pm line 320 seems to indicate the minimum value for an LXC container's tag to be 2. Since a tag of 1 is perfectly valid, why is this? Changing it to 1 and restarting pvedaemon got past that error, but then I started to get others (something about "bridge" not being defined, which I couldn't immediately explain...), and frankly this perl code is sadly under-commented, so I am just going to go with the config file edit for now.Any thoughts on this? Any chance this would work better if I performed a clean install of 4.0 now that it's out of beta? I don't want to do that, but I also don't want to have to edit the config file by hand every time I want to bring up another instance.Thanks!

 

[dietmar]

Since a tag of 1 is perfectly valid, why is this?

We use this internally, so this tag is reserved.

 

[spirit]

As Alternative, linux bridges now support vlans tagging, and set vlan1 when no vlan are defined.

In the gui, in network config, linux bridge , they are a new checkbox : "vlan aware bridge."

 

[dietmar]

FYI: the use of VLAN ID 1 as default VLAN is quite common and documented:

https://en.wikipedia.org/wiki/IEEE_802.1Q

VID 0x001 (the default VLAN ID) is often reserved for a management VLAN

 

[dietmar]

FYI: the use of VLAN ID 1 as default VLAN is quite common and documented:

@spirit: but wouldn't it be possible to allow ID 1? Or does it break something?

 

[spirit]

@spirit: but wouldn't it be possible to allow ID 1? Or does it break something?

I didn't known that vlan1 was no more allowed in gui or script.
It's only used by default with vlan aware bridge, to tag with vlan1 the untagged packets.
I'm not sure what happen if a vlan1 if defined on a vm interface in this case.

For openvswitch, I think it's also possible to tag to a specific default vlan untagged packets (pvid)
ovs-vsctl add-port vmbr0 eth0 tag=1 vlan_mode=native-tagged|native-untagged

The correct way should be to not defined tag on the vm, but keep the bridge/ovs tagged default vlan when
packet is outgoing to physical switch;



Edit : They are some doc in proxmox wiki:

https://pve.proxmox.com/wiki/Open_vSwitch#Example_1:_Bridge_.2B_Internal_Ports_.2B_Untagged_traffic

auto eth0
allow-vmbr0 eth0
iface eth0 inet manual
  ovs_bridge vmbr0
  ovs_type OVSPort
  ovs_options tag=1 vlan_mode=native-untagged

 

[blood]

I'm fine with Proxmox using VLAN 1 as its management VLAN, but that doesn't by itself mean that instances cannot or should not be able to access that network directly. Many switches use VLAN 1 as their native VLAN which is almost definitely what that wikipedia quote is referencing, but they generally still allow the use of that VLAN tag for tagged interfaces. The current behavior violates the "principle of least astonishment", which while not uncommon, is still not desirable.

Really though as long as this is documented it's fine. The error message, while correct, could be more clear (make it explicitly say that 1 is reserved), include it in the product documentation, and put a comment in the code explaining it.