[libvirt] PATCH: Fix setting of bridge forward-delay
by Daniel P. Berrange
The libvirt virtual networking allows setting of the forward-delay
parameter. This is the delay the kernel inserts before it starts
forwarding traffic when a guest VIF is added to a bridge. The default
network config sets this to zero, and previously we had a bug where
we accidentally called brSetForwardDelay() based on the STP parameter
which was zero, so we did in fact have a forward delay of 0 as desired.
Rich then fixed this bug, and thus we no longer accidentally call the
brSetForardDelay() method. Unfortuntely the place where we *do* delibrately
call it is conditionalized on
if (network->def->delay
So if you set a forward delay of zero, we never explicitly set this on
the bridge. Thus the kernel's default setting applies which is 15 seconds.
The fix is trivial - just remove the conditional.
So previously you could see traffic forwaarding delayed by the kernel
for 30 seconds
Aug 1 11:34:16 t60wlan kernel: device vnet0 entered promiscuous mode
Aug 1 11:34:16 t60wlan kernel: virbr0: port 1(vnet0) entering listening state
Aug 1 11:34:31 t60wlan kernel: virbr0: port 1(vnet0) entering learning state
Aug 1 11:34:46 t60wlan kernel: virbr0: topology change detected, propagating
Aug 1 11:34:46 t60wlan kernel: virbr0: port 1(vnet0) entering forwarding state
Now it applies immediately
Aug 1 11:40:07 t60wlan kernel: device vnet0 entered promiscuous mode
Aug 1 11:40:07 t60wlan kernel: virbr0: port 1(vnet0) entering listening state
Aug 1 11:40:07 t60wlan kernel: virbr0: port 1(vnet0) entering learning state
Aug 1 11:40:07 t60wlan kernel: virbr0: topology change detected, propagating
Aug 1 11:40:07 t60wlan kernel: virbr0: port 1(vnet0) entering forwarding state
Daniel
Index: src/qemu_driver.c
===================================================================
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.98
diff -u -r1.98 qemu_driver.c
--- src/qemu_driver.c 30 Jul 2008 09:20:19 -0000 1.98
+++ src/qemu_driver.c 1 Aug 2008 10:46:36 -0000
@@ -1480,8 +1480,7 @@
}
- if (network->def->delay &&
- (err = brSetForwardDelay(driver->brctl, network->def->bridge, network->def->delay))) {
+ if ((err = brSetForwardDelay(driver->brctl, network->def->bridge, network->def->delay))) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_("failed to set bridge forward delay to %ld"),
network->def->delay);
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
16 years, 3 months
[libvirt] [PATCH]: Add carriage returns to qemudLog
by Chris Lalancette
Since qemudLog just maps to fprintf(stderr), add carriage returns every where it
is used, so it's easier on the eyes while debugging.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
16 years, 3 months
[libvirt] libvirt, XEN, bridged network and arp
by Christoph Höger
Hi,
Ive got a severe networking problem over here: When I boot up my machine
(debian lenny) using virsh 0.4.4 on an debian etch, a new virtual eth
device (something like vif97.0) is assigned to that machine and that
device is attached to my bridge virbr1. That is fine. Not so fine is the
fact, that no arp packages come over to my bridge for about 5 seconds or
so.
During that time I can see a lot of arp-who-has on vifXX.0 but nothing
on virbr1 so there are no answers and the result is my guest machine not
mounting nfs directories on boot.
After some time (e.g. after login) networking works fine - but thats
definitely too late - I need those directories mounted on boot.
Is there a way to fix that?
16 years, 3 months
[libvirt] [PATCH] Minor doc tweaks
by Charles Duffy
Per subject; clarifies the distinction between virDomainCreateLinux and
virDomainDefineXML+virDomainCreate, and adds documentation for the
autoport display attribute.
16 years, 3 months
[libvirt] [Charles_Duffy@messageone.com: [PATCH] autoport overrides actual VNC port number in dump-xml]
by Daniel P. Berrange
Forwarding message that was sent to wrong list...
----- Forwarded message from Charles Duffy <Charles_Duffy(a)messageone.com> -----
> To: kvm(a)vger.kernel.org
> From: Charles Duffy <Charles_Duffy(a)messageone.com>
> Subject: [PATCH] autoport overrides actual VNC port number in dump-xml
> Date: Wed, 30 Jul 2008 00:32:57 -0500
>
> Per subject; if autoport is in use for a host, the current
> virDomainGraphicsDefFormat code always emits "port=-1", even if a port
> is assigned to the host; this leaves no way for a client to find the VNC
> port assigned to the host in question.
>
> --------------090103050500010408080902
> Content-Type: text/x-diff;
> name="libvirt-fix-vnc-port-output.patch"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="libvirt-fix-vnc-port-output.patch"
>
> diff --git a/src/domain_conf.c b/src/domain_conf.c
> index d629093..ece471e 100644
> --- a/src/domain_conf.c
> +++ b/src/domain_conf.c
> @@ -2431,11 +2431,11 @@ virDomainGraphicsDefFormat(virConnectPtr conn,
>
> switch (def->type) {
> case VIR_DOMAIN_GRAPHICS_TYPE_VNC:
> - if (def->data.vnc.autoport)
> - virBufferAddLit(buf, " port='-1'");
> - else if (def->data.vnc.port)
> + if (def->data.vnc.port)
> virBufferVSprintf(buf, " port='%d'",
> def->data.vnc.port);
> + else if (def->data.vnc.autoport)
> + virBufferAddLit(buf, " port='-1'");
>
> virBufferVSprintf(buf, " autoport='%s'",
> def->data.vnc.autoport ? "yes" : "no");
>
> --------------090103050500010408080902--
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
----- End forwarded message -----
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
16 years, 3 months
[libvirt] [PATCH] qemudDomainCreate check if domain is already active
by Guido Günther
Hi,
currently virsh create foo.xml overwrites running domains. In case of
qemu this leaves detached qemu processes around and the domain creation
fails later on being unable to start other domains afterwards - not
nice.
Attached patch checks if we already have a running domain by that name
and in this case refuses to create a new domain from xml by that name.
Probably this check needs to be pushed further upward since this might
affect other hypervisors too, haven't checked that though.
Cheers,
-- Guido
16 years, 3 months
