I haven't investigated what you describe so can't offer much help...
But my reaction is that if it's not possible to configure some kind of
"master vlan tag" I'd consider "packaging" all the VLANs through a VPN
just long enough to pass through any major obstacles (technical or
onerous work). Of course such an approach would likely come with
significant overhead but it's a matter of trade-offs.
Or, I suppose that you could attempt to script the creation of your
bridges and just deal with them all.
Tony
On Thu, Aug 22, 2013 at 10:49 AM, Stephan von Krawczynski
<address@hidden> wrote:
> Sorry, you misunderstood my writing. I am talking of several hundred vlans
> with - of course - different ids and quite some guests (around 50).
> There is no way to simplify this setup besides the trivial way of a bridge
> that carries all vlan-tagged interfaces. The trivial thing about it is all
> these different vlans come in through one trunk. So if vlan-tagged bridging
> worked I would have only one bridge interface with 50 guests connected ...
>
> --
> Regards,
> Stephan
>
>
>
> On Thu, 22 Aug 2013 10:29:59 -0700
> Tony Su <address@hidden> wrote:
>
>> If you're configuring the all your "hundreds" of guests to connect to
>> the same VLAN, then you should able to simply configure all guests to
>> connect to the same working bridge device without further
>> configuration.
>>
>> You're surely not trying to configure hundreds of individual vlans,
>> separate ones for each guest?
>>
>> Tony
>>
>> On Thu, Aug 22, 2013 at 10:04 AM, Stephan von Krawczynski
>> <address@hidden> wrote:
>> > Hello Tony,
>> >
>> > thank you for answering, my comments are inline. Just as an additional
hint to
>> > what I've tested so far. Since I found vlan bridging not working I
configured
>> > the vlan on the host and put that interface to a bridge and over to a
virtio
>> > device (non-vlan-tagged) in the guest. As you might expect this works
>> > perfectly. Unfortunately it is not useable for me, because if you want
several
>> > hundred vlans to several guests you will end up configuring hundreds of
>> > bridges and interfaces.
>> >
>> >
>> > On Thu, 22 Aug 2013 09:32:42 -0700
>> > Tony Su <address@hidden> wrote:
>> >
>> >> Have you
>> >> - Tested without VLAN tags?
>> >
>> > Yes, works perfectly.
>> >
>> >> - Verified IP Forwarding is enabled, I usually see this implemented in
>> >> /etc/sysctl.conf and not written directly to the /proc files
>> >
>> > Yes, forwarding is active.
>> >
>> >> - Disabled all the transparent bridge filters, typicallly at
>> >> /proc/sys/net/bridge/* again, although you can write directly to these
>> >> files I'd recommend you simply add the commands to your sysctl.conf
>> >
>> > Yes, I played with these a bit but found out that there is no effect on my
>> > problem.
>> >
>> >> - Verified any personal FW is configured properly.
>> >
>> > There is none.
>> >
>> >> Tony
>> >>
>> >> On Thu, Aug 22, 2013 at 7:39 AM, Stephan von Krawczynski
>> >> <address@hidden> wrote:
>> >> > Hello all,
>> >> >
>> >> > I'd like to do something very simple - at least that's what I thought
>> >> > I want a guest to have access to a network just as if he was connected
to the
>> >> > real card, but set up as bridge on the host and virtio network driver.
The
>> >> > guest should be able to configure and use some or maybe even many
802.1q vlans
>> >> > on this network and the traffic should go out tagged.
>> >> >
>> >> > So I setup the hosts bridge and connected an intel network card and a
qemu
>> >> > virtio card. Now the problem: No vlan-tagged traffic from the physical
>> >> > interface reaches the guest at all, and no vlan-tagged traffic from the
guest
>> >> > reaches the physical net over the bridge. One major reason for this is
the
>> >> > vlan offloading by the host interface card (intel). Another seems to be
that
>> >> > arp requests are somehow not going through the bridge for the vlans.
>> >> >
>> >> > I hope that someone here has used 802.1q vlans inside guests before and
can
>> >> > share some tips how to make this work. Because out-of-the-box it does
not. All
>> >> > system are linux of course and with latest kernels (3.10.9 currently).
>> >> > qemu is 1.5.2.
>> >> > Thanks for any hints.
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Stephan