just wanna bring to notice, that the suggested solution fixed our problem with some of the virtual machines (kvm-85, debian lenny + latest backport, tho).
Not sure, if it belongs into "wishlist" then.
The virtual machines use the bridge "br0" for having their own interface, they run Java and get network traffic constantly.
We had the phenomenon of broken sockets. On the virtual machine the "serving" socket was already gone while on the client side the socket was still intact (established). As if the traffic gets swallowed somewhere.
Salute,
just wanna bring to notice, that the suggested solution fixed our problem with some of the virtual machines (kvm-85, debian lenny + latest backport, tho).
Not sure, if it belongs into "wishlist" then.
The virtual machines use the bridge "br0" for having their own interface, they run Java and get network traffic constantly.
We had the phenomenon of broken sockets. On the virtual machine the "serving" socket was already gone while on the client side the socket was still intact (established). As if the traffic gets swallowed somewhere.
On the physical machine:
$ cat /etc/network/ interfaces
...
auto br0
iface br0 inet static
address ...
netmask ...
network ...
broadcast ...
gateway ...
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
The template for the virtual machine shows:
$ sudo virsh edit virtualmachine '53:52: 00:24:95: 90'/>
...
<interface type='bridge'>
<mac address=
<source bridge='br0'/>
<target dev='vnet0'/>
<model type='virtio'/>
...
So when i start the virtual machine:
$ sudo virsh start virtualmachine
it shows:
$ sudo ip -6 route show
fe80::/64 dev br0 ...
fe80::/64 dev eth0 ...
fe80::/64 dev vnet0 ...
And since we did this, as suggested:
$ sudo ip -6 route del fe80::/64 dev eth0
$ sudo ip -6 route del fe80::/64 dev vnet0
everything seems to work fine. The machines are stable now for several days.