Re: [libvirt-users] bridged networking using VLAN : guest with 2 NIC

(There is no need or advantage to Cc'ing individuals who are already subscribed to the mailing list.) On 10/28/2013 05:34 PM, Dan Sa wrote: See the comment below about <forward mode='bridge'>. you'll need some other entity on your vlan to run a dhcp server, because libvirt won't be doing it for you in this case. The output of "virsh dumpxml $guestname" is much more useful than a transcription of the virt-manager screens. I don't understand what you mean by "this is guest". It isn't a part of the guest; it is a bridge on the host that could be *used* by a guest. and that it is connected via the br0 bridge; apparently you took this output when neither of your dual-nic guests were running, as they should have each attached tun devices to both guest1-lan and virbr0. (You shouldn't be looking at/modifying the files in /etc/libvirt/qemu/networks directly. Instead, use "virsh net-dumpxml guest1-lan" (for example) to look at the network config, and "virsh net-edit guest1-lan" to modify it.) Any network with <forward mode='bridge'...> is an "unmanaged" network from libvirt's POV, and thus the <ip> element and all its subelements are ignored. If you use <forward mode='bridge'> then libvirt assumes that the bridge device is already configured by the base OS config. As of libvirt-1.0.1, attempts to define an <ip> element in a network with <forward mode='bridge'> are flagged as an error. (It would be helpful in future reports if you indicate your 1) libvirt version, 2) qemu version, 3) distro and version, 4) kernel version. Although not always applicable, sometime it can help in framing the issue. Since you're defining a vlan tag, I assume that the physical network attached to your host's em2 is actually using vlan 620? If not, and you just need a network that's private to your guests and the host, I would recommend simply defining a libvirt network with no <forward> element at all. This network *will* be managed by libvirt, so libvirt will create a bridge and give it an IP address, as well as running a dnsmasq instance to serve up IP addresses to guests, but the guests won't be able to get traffic anywhere beyond that bridge via their interface connected to the bridge. If you *are* using vlan 620 on the physical network, then you'll need to setup some other dhcp server somewhere on that network (either run a system instance of dnsmasq on the host that listens on em2.620, or run dnsmasq or dhcpd on some other physical host or guest that listens on its own vlan-tagged interface).