8:38 p.m.
Hi list,
this probably isn't a completely libvirt-specific question but I'll try
anyway. Please ignore if it is too much off-topic.
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and
several guests (Debian, Ubuntu, Windows Server 2003) in a bridged
network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to
manually shutdown and restart (virsh shutdown GUEST && virsh start
GUEST, a mere reboot doesn't suffice) them to get them onto the network
again. Obviously that's not ideal.
Is this the expected behaviour? Can I somehow re-establish guest network
connectivity without shutting down the guest first? Is my setup somehow
wrong or do I expect too much?
Any insight, explanation or pointers would be much appreciated!
Thanks,
Andreas
[1] http://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging
[2] http://wiki.libvirt.org/page/Networking#Guest_configuration_2
--
Andreas Ntaflos
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
4:52 a.m.
2010/4/18 Andreas Ntaflos <daff(a)pseudoterminal.org>:
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and
several guests (Debian, Ubuntu, Windows Server 2003) in a bridged
network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to
manually shutdown and restart (virsh shutdown GUEST && virsh start
GUEST, a mere reboot doesn't suffice) them to get them onto the network
again. Obviously that's not ideal.
Confirmed, I have the same problem. Even with bridged configuration,
do you have dnsmasq running elsewhere (maybe with --bind-inferfaces
flag)? If i got it right, an application can bind to an "handle" of an
ethernet device and not its name, so when you restart networking, the
handle will change and apps binded to the previous handle will stop
working. Maybe it's the hypervisor itself (the ubuntu default is kvm)
to bind to the interface, so it maybe not be related at all with
libvirt.
Another thing I have observerd in a NAT configuration is that there
are problems in setting port forwarding from the host to guests when
libvirt is not yet started (= default network "libvirt0" bridge not
created and proper route to the NATed subnetwork not added). It seems
it just doesn't work, and it seems strange to me because I thought
iptables rules should have held even devices or hosts/networks didn't
exist. I "sorted" editing libvirt-bin init script adding a line that
adds port forwarding after libvirt have been started. This is the kind
of "ugly workarounds" I hate, but at the time it was the quicker
working (and safe) solution and din't have time to do a proper
reporting.
Maybe it does worth report this to ubuntu and/or kvm.
Greetings,
Francesco
8:02 a.m.
On 04/17/2010 09:38 PM, Andreas Ntaflos wrote:
Hi list,
this probably isn't a completely libvirt-specific question but I'll try
anyway. Please ignore if it is too much off-topic.
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and
several guests (Debian, Ubuntu, Windows Server 2003) in a bridged
network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to
manually shutdown and restart (virsh shutdown GUEST && virsh start
GUEST, a mere reboot doesn't suffice) them to get them onto the network
again. Obviously that's not ideal.
Is this the expected behaviour? Can I somehow re-establish guest network
connectivity without shutting down the guest first? Is my setup somehow
wrong or do I expect too much?
Unfortunately, that is the expected behavior. If you do:
# brctl show
# /etc/init.d/networking restart
# brctl show
You'll see that the list of interfaces attached to the bridge is different
before and after. The problem is that as libvirt starts a guest, it plugs
the virtual interface into the bridge device. When you do a networking
restart, all of those interfaces are lost from the bridge, and there is no
way currently to re-attach them. It's probably fix-able, but non-trivial;
libvirt would have to be notified by the system (via D-bus?) that the bridge
was restarted, and then it would have to re-plug the interfaces on the "new"
bridge.
--
Chris Lalancette
11:51 a.m.
On Mon, Apr 19, 2010 at 6:02 AM, Chris Lalancette <clalance(a)redhat.com>wrote:
Unfortunately, that is the expected behavior. If you do:
# brctl show
# /etc/init.d/networking restart
# brctl show
I also have this problem when I net-destroy/net-start the libvirt network in
order to load a new network definition (typically, new DHCP hosts). I made a
script which captures the br interfaces, restarts the network, then
reattaches, but it seems like there should be a way for libvirt to do this
for me since I'm restarting it's network and it's the one that plugged the
interfaces in. Is there something I'm missing?
Ubuntu 9.10 / libvirt 0.7.0.
.:. jeremy
4:05 p.m.
On Monday 19 April 2010 15:02:59 Chris Lalancette wrote:
On 04/17/2010 09:38 PM, Andreas Ntaflos wrote:
> Hi list,
>
> this probably isn't a completely libvirt-specific question but I'll
> try anyway. Please ignore if it is too much off-topic.
>
> On an Ubuntu (9.10) virtualisation host, running KVM and libvirt
> and several guests (Debian, Ubuntu, Windows Server 2003) in a
> bridged network fashion [1,2] I noticed that performing
>
> /etc/init.d/networking restart
>
> on the host completely cuts off all guests from the network. I have
> to manually shutdown and restart (virsh shutdown GUEST && virsh
> start GUEST, a mere reboot doesn't suffice) them to get them onto
> the network again. Obviously that's not ideal.
>
> Is this the expected behaviour? Can I somehow re-establish guest
> network connectivity without shutting down the guest first? Is my
> setup somehow wrong or do I expect too much?
Unfortunately, that is the expected behavior. If you do:
Hi,
thank you for the clarification and confirmation. I'll be keeping it in
mind. Hopefully libvirt will someday support restarting the network;
unfortunately there isn't much I can do to help except testing.
Thanks,
Andreas
--
Andreas Ntaflos
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
5364
days inactive
5365
days old
4 comments
4 participants
participants (4)
-
Andreas Ntaflos -
Chris Lalancette -
Francesco Pretto -
jeremy avnet