Comment 1 for bug 633392

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thanks very much for opening this bug.

Can you append the /etc/netstart script from openbsd here?

I notice that while you have the libvirt-defined virbr0, your VM is using
a hand-build br0 (which has stp off). Is there any particular reason for
this? It looks like you want the guests locked into eth1 only, is that
right?

1. If that is NOT what you necessarily wanted, then you might try editing
your VM xml to have:

    <interface type='network'>
      <mac address='52:54:00:53:2d:a1'/>
      <source network='default'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

instead of

    <interface type='bridge'>
      <mac address='52:54:00:53:2d:a1'/>
      <source bridge='br0'/>
      <model type='e1000'/>
    </interface>

and see whether that works.

2. Alternatively, you could see whether having libvirt create the equivalent of
br0 works better (or just turn on stp on br0). You could change eth1 to have a
static address, remove br0 from /etc/network/interfaces, and then create a file
/etc/libvirt/qemu/networks/private.xml (symlinked into
/etc/libvirt/qemu/networks/autostart as well) containing something like:

<network>
  <name>default</name>
  <bridge name="virbr%d" />
  <forward mode="route" dev="eth1"/>
  <ip address="192.168.123.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.123.2" end="192.168.123.254" />
    </dhcp>
  </ip>
</network>

3. Depending on the results of that, I may post a recipe for testing
attaching a veth tunnel to virbr0 and br0 and testing continuity through
that.

4. If none of these work, we can try backported kernels (from
https://launchpad.net/~kernel-ppa/+archive/pre-proposed) and/or
qemu-kvm (from https://launchpad.net/~serge-hallyn/+archive/lucid-kvm-test)
packages.