similar to: Bug#679533: Traffic forwarding issue between Xen domU/dom0

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-5.2 Hi, We're seeing weird behaviour regarding network traffic between a Xen dom0 and domU. I reported this issue yesterday to the openvswitch-discuss mailing list, but it seems this could also be a (regression?) bug in the xen hypervisor or the linux kernel... (we've upgraded xen-hypervisor-4.0-amd64 4.0.1-4 -> 4.0.1-5.2 and

After turning off hibernation this issue did not occur anymore in Squeeze. Now we've turned on hibernation again, ran the test to reproduce this issue and this issue occurred within 10 minutes on Squeeze with Hibernation on. Then we've upgraded our test environment from Squeeze to Wheezy and ran the test to reproduce this issue again on Wheezy with hibernation turned on. This test

Obviously i meant hyperthreading. Probably need more coffee:) -- Frank Baalbergen - System / Network Administrator T +31 (0)10 2760434 | frank.baalbergen at mendix.com | www.mendix.com

Package: xcp-networkd Version: 1.3.2-11 Severity: normal Given that openvswitch is one of the networking modes, it should be in the Recommends: than being in the Depends: -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64

Hi I am using Libvirt 1.1.2 with Openstack Havana (RC2, nova-network) and openvswitch 1.4.2+git20120612-9.1. Libvirt vif driver ( nova.virt.libvirt.vif.LibvirtGenericVIFDriver) generates config likes this: <interface type='bridge'> <mac address='fa:16:3e:44:30:a4'/> <source bridge='br0'/> <model type='virtio'/>

Kevin, Would you mind taking a look at #679533 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679533) and give some feedback about how similar this issue is to your report in #631102 here? There was a hint 631102 might be similar, but from the text in this bug report it's not clear to me if this is about the same issue. Maybe you could comment on it. First results of a big shoot-out

On Wed, Oct 16, 2013 at 01:52:57PM +0200, Maciej Gałkiewicz wrote: > Hi > > I am using Libvirt 1.1.2 with Openstack Havana (RC2, nova-network) and > openvswitch 1.4.2+git20120612-9.1. Libvirt vif driver ( > nova.virt.libvirt.vif.LibvirtGenericVIFDriver) generates config likes this: > > <interface type='bridge'> > <mac

I'm just dumping all I got in here, after initial feedback we can see how to organize todo's around it. tl;dr: * Does not upgrade cleanly from 4.8 packages, so we have to prevent this from entering testing until we fix that. * Live migration is broken, explodes with memory allocation errors. ---- >8 ---- 1. Build packages * I have built salsa/master using pbuilder targeting sid.

Package: xen-utils-common Version: 4.1.2-3 Severity: normal When configurating a duplicate custom vifname for interfaces in the Xen dom0 that are added to a bridge (which is obviously a configuration error), the hotplug scripts fail silently to rename the new vifX.0 to the custom vifname, if it's already existing. The result of this, is that the domU will start normally, but no network

Whoops, that patch is obviously missing an extra line containing a fi statement. Fixed version attached. And configurating is obviously not english. :) -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg at mendix.com | www.mendix.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Package: xen-utils-common Version: 4.1.4-2 Severity: normal Hi, During some research I encountered incorrect information in the man page of xm, about the dump-core functionality: The man page says: "Defaults to dumping the core without pausing the domain if no I<OPTIONS> are specified." When taking a look at the source code of this process, the default behaviour is to actually

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-8 Severity: normal Tags: patch The Xen hypervisor in Debian Jessie does not boot on recent HP server hardware (e.g. the current dl360 gen9 series) when using normal "legacy" boot. During boot, it panics with the message "System without CMOS RTC must be booted from EFI". This message was introduced in upstream commit

Hello. On 12/17/2014 09:20 PM, Vladislav Yasevich wrote: > Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks > to handel UFO6 flows. > Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, > so we need to continue to handle them correclty. > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- >

Hello. On 12/17/2014 09:20 PM, Vladislav Yasevich wrote: > Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks > to handel UFO6 flows. > Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, > so we need to continue to handle them correclty. > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- >

A huge thank you to mario from the ''openvswitch on Xen 4.1'' post. I was having some trouble with using openvswitch with Xen 4.1 (I''m currently migrating from 4.0.1) until I saw his post and noticed that the xl.conf needed the full path to the networking script. Made this change and all is good now. Thank you. I would like to contribute what I have for using

Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks to handel UFO6 flows. Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, so we need to continue to handle them correclty. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- net/openvswitch/datapath.c | 3 ++- net/openvswitch/flow.c | 2 +- 2 files changed, 3 insertions(+), 2

Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks to handel UFO6 flows. Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, so we need to continue to handle them correclty. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- net/openvswitch/datapath.c | 3 ++- net/openvswitch/flow.c | 2 +- 2 files changed, 3 insertions(+), 2

Package: xcp-xapi Version: 1.3.2-6 Severity: important Looks like on Wheezy, /etc/default/xen is not created by xen-utils-common. Since xcp-xapi depends on its existence and further declaration of the toolstack in it, it should take extra care to ensure that it is present. root at debian:~# aptitude install xcp-xapi The following NEW packages will be installed: blktap-dkms{a} blktap-utils{a}

Hi All, First time mailing here. I have installed on a CentOS 7.0 KVM (with DPDK and OVS) one Deep Packet Inspection VM. I have one channel and some virtual traffic generator. The traffic is lost between dpdk vhostuser and the DPI VM. The setup is attached. Any suggestions or ideas? Regarding the OVS+DPDK configuration, the following configuration is already made: - SELINUX is disabled - QEMU

Hi I wrote a vif script to support openvswitch. I use it on some of my machines, so it works for non-qemu domains. Ian asked me to send it here, maybe someone wants to take a look. Bastian #!/bin/bash #============================================================================ # ${XEN_SCRIPT_DIR}/vif-openvswitch # # Script for configuring a vif in openvswitch mode. # The hotplugging system