We messed up things:( 1. Unfortunately I was misinformed. In fact the problem was triggered by assigning the same VLAN ID-s within an SMP guest. Just as in the case discussed in the KVM list, it was simply resolved by assigning unique ids within the guest. 2. After all I unit tested the other case (different guests sharing the same VLAN ID) and found no problem. It just works, needs no resolution. Again thanks for the clarifications and sorry for the mistake, Cheers, Gyula -----Eredeti üzenet----- Feladó: libvir-list-bounces@xxxxxxxxxx meghatalmazó: Csom Gyula Küldve: 2010. 05. 19., Sze 17:00 Címzett: libvir-list@xxxxxxxxxx Tárgy: Re: Different VLAN IDs Thanks for your response! I didn't know that VLAN IDs are internal to the individual KVM/QEMU processes. In fact the VLAN IDs were different within our guests. So it was not a perfect match... Meanwhile the question remains, why their solution did work in our case. But this one should goe to the KVM/QEMU developer list..., I guess:) Cheers, Gyula -----Eredeti üzenet----- Feladó: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] Küldve: 2010. 05. 19., Sze 16:24 Címzett: Csom Gyula Másolatot kap: libvir-list@xxxxxxxxxx Tárgy: Re: Different VLAN IDs On Wed, May 19, 2010 at 04:11:36PM +0200, Csom Gyula wrote: > Hi there, > > We experienced network problems (namely net packet storm), when using multiple NICs and > the same VLAN ID-s for different KVM guests. It turned out that we could workaround the > problem by simply assigning different VLAN ID-s to the different NICs. (Btw our case > looked similar to the one that was posted and discussed on the KVM mailing list. Also the > solution was picked from that discussion. See: http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg24203.html, for details) That thread is discussing the case of 1 guest with 2 NICs, both connected to the same bridge on the host, thus creating a network loop between the guest & the host. The VLAN ID is a QEMU internal identifier / concept (not related to 802.11 VLANs), that doesn't propagate to the outside world. So in your scenario of having multiple guests, there is no association between the VLAN ids in each guest's NIC. > My questions: > > - Did anyone experience similar problems, and come up with a clean solution? Specially > is there any better way to provide unique VLAN ID-s thru libvirt then the above > one? > > As far as I see the upcoming -netdev option (introduced in QEMU 0.12) will solve the > question. However this was removed from libvirt, since the corresponding qemu monitor command > is not yet developed: > > - Do you have a target release for the -netdev option, or is it unknown (eg. dependent > on the yet unknown KVM/QEMU development schedule)? It will be enabled when 0.13 QEMU comes out. > > Cheers, > Gyula > > Ps.: our env: Debian GNU/Linux, libvirt, kvm, ebtables > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list