Serge,
I think I'm starting to understand this issue and I'm fairly certain the
problem is in libvirt.
First off, it seems like I can repeatedly checkout depot_tools in a KVM
using a setup that I think matches your example except for a new (and
different) error.
My first step was shutdown libvirt-bin. Then I modified interfaces on the host
to look like:
# The primary network interface
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 10.10.224.21
netmask 255.255.255.0
gateway 10.10.224.254
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
and restarted networking. Next I:
ifconfig tap1 0.0.0.0 up
brctl addif br0 tap1
and invoked KVM like so:
/usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 8192 -smp 8 -name
hound-lucid -uuid 0e32438c-cb4d-1eb9-a560-f25c89c1dbf6 -boot c -drive
file=/opt/hound-lucid,if=virtio,index=0,boot=on -drive
if=ide,media=cdrom,index=2 -net nic,macaddr=52:54:8b:3d:1a:82,model=virtio -net
tap,ifname=tap1,script=no,downscript=no -vnc :1
Finally, I used vnc on the guest to statically configure networking.
With this set up I tried the svn co of depot tools 3 times. However,
the guest now seems to lose all networking connectivity after a few
short minutes. eth0 on the host loses its IP configuration. The
workaround is to "/etc/init/d/networking restart". This symptom is
different from the error originally described in this bug but may be
related to some manual step in my testing.
Back to the original issue (failed 'svn co'), the most notable difference
between the working setup and the broken one is the network architecture. In
my original posts, tap0 and tap1 formed a private LAN hidden behind the host's
eth0 via NAT and IP forwarding and using a separate IP address space. This was
managed by libvirt and is described here:
http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29
In the scenario you suggested which seemed to work, tap1 was bridged directly
to eth0 and used an IP address from the host's actual subnet. This is similar
to:
http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29
I'm not sure if this problem is the networking architecture itself or libvirt's
management of it.
I'm not 100% sure what my next steps should be. Is there a different
mechanism to manage KVM "virtual networks" without using libvirt? Or
should I give up on that approach and use shared physical device, in
which case I need to allocate additional IPs for the guests and ensure
that they're properly secured from the LAN.
brian
--
Broken networking in kvm guests
https://bugs.launchpad.net/bugs/616064
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
