January 2016 - Devel - libvirt List Archives

[libvirt] [PATCH 0/3] build: drop some nested makefiles
by Cole Robinson 12 Jan '16

12 Jan '16

This kills some nested makefiles. They don't hurt much but they are largely redudant so don't serve much usefulness either. After this we have a strict two level Makefile hierarchy, which is an easy rule of thumb to follow. The first two patches clean up blantantly redundant makesfiles Patch 3 is a bit trickier with the wireshark plugin, but it's also more useful to fix since now it can be built in parallel with the rest of the tools/ directory. Cole Robinson (3): build: Kill include/libvirt/Makefile.am build: Kill docs/schemas/Makefile.am build: Kill tools/wireshark Makefiles Makefile.am | 2 +- configure.ac | 7 ++---- docs/Makefile.am | 10 ++++---- docs/schemas/Makefile.am | 35 --------------------------- include/Makefile.am | 19 +++++++++++++-- include/libvirt/Makefile.am | 44 ---------------------------------- tools/Makefile.am | 52 ++++++++++++++++++++++++++++++++++++++--- tools/wireshark/Makefile.am | 23 ------------------ tools/wireshark/src/Makefile.am | 49 -------------------------------------- 9 files changed, 75 insertions(+), 166 deletions(-) delete mode 100644 docs/schemas/Makefile.am delete mode 100644 include/libvirt/Makefile.am delete mode 100644 tools/wireshark/Makefile.am delete mode 100644 tools/wireshark/src/Makefile.am -- 2.5.0

3 8

[libvirt] [PATCH] testutils: Fix coverity warning with REGENERATE_OUTPUT
by Cole Robinson 12 Jan '16

12 Jan '16

- Don't double check for expectName - actual is always non-NULL by this point, so don't check it either --- tests/testutils.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tests/testutils.c b/tests/testutils.c index 4ffea0c..b587f83 100644 --- a/tests/testutils.c +++ b/tests/testutils.c @@ -469,15 +469,14 @@ virtTestDifferenceFullInternal(FILE *stream, actualStart = actual; actualEnd = actual + (strlen(actual)-1); - if (regenerate && (virTestGetRegenerate() > 0) && expectName && actual) { + if (expectName && regenerate && (virTestGetRegenerate() > 0)) { char *regencontent; /* Try to properly indent qemu argv files */ if (!(regencontent = virStringReplace(actual, " -", " \\\n-"))) return -1; - if (expectName && actual && - virFileWriteStr(expectName, regencontent, 0666) < 0) { + if (virFileWriteStr(expectName, regencontent, 0666) < 0) { VIR_FREE(regencontent); return -1; } -- 2.5.0

3 3

[libvirt] [PATCH 0/6] tests: misc collection of improvments
by Cole Robinson 12 Jan '16

12 Jan '16

Small collection of test suite improvements that were getting mixed in with other patches I'm working on. Patch #1 is a REGENERATE tweak for qemu argvs (this is already on list) Patch #2 fixes running schema tests from top git dir Patch #3-4 simplify the domain xml2xml tests Patch #5 adds a new driver agnostic genericxml2xml test (to be used later) Patch #6 adds QEMUCaps plumbing to qemuxml2xml (to be used later) Cole Robinson (6): tests: Add newlines with VIR_TEST_REGENERATE_OUTPUT tests: Fix running schematests directly from topdir tests: Share domain XML2XML compare helper tests: qemuxml2xml: drop early file loading tests: add genericxml2xmltest tests: qemuxml2xml: Wire up QEMUCaps usage tests/Makefile.am | 9 ++ tests/bhyvexml2xmltest.c | 30 +------ tests/capabilityschematest | 2 +- tests/domaincapsschematest | 2 +- tests/domainschematest | 4 +- tests/domainsnapshotschematest | 2 +- tests/genericxml2xmlindata/generic-disk-virtio.xml | 45 ++++++++++ .../genericxml2xmloutdata/generic-disk-virtio.xml | 45 ++++++++++ tests/genericxml2xmltest.c | 83 +++++++++++++++++++ tests/interfaceschematest | 2 +- tests/lxcxml2xmltest.c | 50 +---------- tests/networkschematest | 2 +- tests/nodedevschematest | 2 +- tests/nwfilterschematest | 2 +- tests/qemuxml2xmltest.c | 96 ++++++---------------- tests/secretschematest | 2 +- tests/storagepoolschematest | 2 +- tests/storagevolschematest | 2 +- tests/test-lib.sh | 9 +- tests/testutils.c | 47 ++++++++++- tests/testutils.h | 6 ++ 21 files changed, 281 insertions(+), 163 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-disk-virtio.xml create mode 100644 tests/genericxml2xmloutdata/generic-disk-virtio.xml create mode 100644 tests/genericxml2xmltest.c -- 2.5.0

3 16

[libvirt] [PATCH] Add missing virxdrdefs.h include to log_protocol
by Roman Bogorodskiy 12 Jan '16

12 Jan '16

Commit 2b6f6ad introduced the virxdrdefs.h header with common definitions to be included in the protocol files, but logging/log_protocol.x was missed, so add it there as well. Hopefully this fixes build on OS X. --- src/logging/log_protocol.x | 1 + 1 file changed, 1 insertion(+) diff --git a/src/logging/log_protocol.x b/src/logging/log_protocol.x index a07334f..b0ac31b 100644 --- a/src/logging/log_protocol.x +++ b/src/logging/log_protocol.x @@ -2,6 +2,7 @@ */ %#include "internal.h" +%#include "virxdrdefs.h" typedef opaque virLogManagerProtocolUUID[VIR_UUID_BUFLEN]; -- 2.4.6

3 3

[libvirt] [PATCH 0/3] fix qemu:///session startup errors (bz 1271183)
by Cole Robinson 12 Jan '16

12 Jan '16

libguestfs and gnome-boxes users have been reporting intermittent qemu:///session launch errors for a while: https://bugzilla.redhat.com/show_bug.cgi?id=1271183 This series fixes it, see individual patches for details Cole Robinson (3): rpc: socket: Minor cleanups rpc: socket: Explicitly error if we exceed retry count rpc: socket: Don't repeatedly attempt to launch daemon src/rpc/virnetsocket.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) -- 2.5.0

2 6

[libvirt] [PATCH V2 0/3] Xen: Support vif outging bandwidth QoS
by Jim Fehlig 12 Jan '16

12 Jan '16

Happy New Year! This small series adds support for specifying vif outgoing rate limits in Xen. The first patch adds support for converting rate limits between sexpr config and domXML. The second patch does the same for xl/xm config. The third patch adds outgoing rate limiting to the libxl driver. V1 here https://www.redhat.com/archives/libvir-list/2015-December/msg00899.html In V2 I've extended support to include the sexpr config format Jim Fehlig (3): xenconfig: support vif bandwidth in sexpr parser and formatter xenconfig: support vif bandwidth in xm and xl parser and formatter libxl: support vif outgoing bandwidth QoS src/libvirt_xenconfig.syms | 1 + src/libxl/libxl_conf.c | 39 +++++++++++++ src/xenconfig/xen_common.c | 30 ++++++++++ src/xenconfig/xen_sxpr.c | 74 +++++++++++++++++++++++++ src/xenconfig/xen_sxpr.h | 2 + tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr | 11 ++++ tests/sexpr2xmldata/sexpr2xml-vif-rate.xml | 51 +++++++++++++++++ tests/sexpr2xmltest.c | 2 + tests/xlconfigdata/test-vif-rate.cfg | 26 +++++++++ tests/xlconfigdata/test-vif-rate.xml | 57 +++++++++++++++++++ tests/xlconfigtest.c | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 10 ++++ tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml | 34 ++++++++++++ tests/xml2sexprtest.c | 1 + 14 files changed, 339 insertions(+) create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.xml create mode 100644 tests/xlconfigdata/test-vif-rate.cfg create mode 100644 tests/xlconfigdata/test-vif-rate.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml -- 2.1.4

3 6

[libvirt] [PATCH v3 00/14] Use macros for more common virsh command options
by John Ferlan 12 Jan '16

12 Jan '16

v2: http://www.redhat.com/archives/libvir-list/2015-December/msg00766.html Changes since v2: Use VIRSH_COMMON_OPT_<optname> for option prefix instead of VIRSH_<optname>_OPT_COMMON Patches have a few thumbs up already, figured I'd post it one last time for perusal and checks of the naming 'algorithm. John Ferlan (14): virsh: Covert VSH_POOL_ macro to VIRSH_COMMON_OPT_ virsh: Move VIRSH_COMMON_OPT_POOL to virsh.h virsh: Create macro for common "domain" option virsh: Create macro for common "persistent" option virsh: Create macro for common "config" option virsh: Create macro for common "live" option virsh: Create macro for common "current" option virsh: Create macro for common "file" option virsh: Create macros for common "pool" options virsh: Create macros for common "vol" options virsh: Have domain-monitor use common "domain" option virsh: have snapshot use common "domain" option virsh: Create macro for common "network" option virsh: Create macro for common "interface" option po/POTFILES.in | 1 + tools/virsh-domain-monitor.c | 77 +--- tools/virsh-domain.c | 911 +++++++++---------------------------------- tools/virsh-interface.c | 37 +- tools/virsh-network.c | 61 +-- tools/virsh-pool.c | 71 ++-- tools/virsh-snapshot.c | 60 +-- tools/virsh-volume.c | 148 ++----- tools/virsh.h | 17 + 9 files changed, 334 insertions(+), 1049 deletions(-) -- 2.5.0

4 45

Re: [libvirt] [PATCH 1/4] cgroup: Fix possible bug as a result of code motion for vcpu cgroup setup
by Henning Schild 12 Jan '16

12 Jan '16

On Mon, 11 Jan 2016 13:50:32 -0500 John Ferlan <jferlan(a)redhat.com> wrote: > Commit id '90b721e43' moved where the virCgroupAddTask was made until > after the check for the vcpupin checks. However, in doing so it missed > an option where if the cpumap didn't exist, then the code would > continue back to the top of the current vcpu loop. The results was > that the virCgroupAddTask wouldn't be called. > > Signed-off-by: John Ferlan <jferlan(a)redhat.com> > --- > src/qemu/qemu_cgroup.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c > index 1c406ce..91b3328 100644 > --- a/src/qemu/qemu_cgroup.c > +++ b/src/qemu/qemu_cgroup.c > @@ -1079,10 +1079,7 @@ qemuSetupCgroupForVcpu(virDomainObjPtr vm) > } > } > > - if (!cpumap) > - continue; > - > - if (qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < 0) > + if (cpumap && qemuSetupCgroupCpusetCpus(cgroup_vcpu, > cpumap) < 0) goto cleanup; > } > Good catch, should be applied! Henning

1 0

Re: [libvirt] Fwd: DNS for IPv6 addresses?
by hongming 12 Jan '16

12 Jan '16

Hi Yaniv Please refer to the following . [root@localhost images]# virsh net-dumpxml dhcp <network connections='2'> <name>dhcp</name> <uuid>066f0d89-67a6-42c8-bdeb-ed9420aaaf4f</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr4' stp='on' delay='0'/> <mac address='52:54:00:c8:29:9f'/> <ip address='192.168.123.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.123.2' end='192.168.123.254'/> </dhcp> </ip> <ip family='ipv6' address='2001:db8:ca2:2::1' prefix='64'> <dhcp> <range start='2001:db8:ca2:2:1::10' end='2001:db8:ca2:2:1::ff'/> </dhcp> </ip> </network> [root@localhost images]# virsh dumpxml rhel7.1|grep /interface -B7 <interface type='network'> <mac address='52:54:00:82:49:b1'/> <source network='dhcp' bridge='virbr4'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> [root@localhost images]# virsh domifaddr rhel7.1 --source lease Name MAC address Protocol Address ------------------------------------------------------------------------------- vnet1 52:54:00:82:49:b1 ipv4 192.168.123.171/24 - - ipv6 2001:db8:ca2:2:1::1a/64 [root@localhost images]# cat /var/lib/libvirt/dnsmasq/virbr4.status [ { "ip-address": "192.168.123.171", "mac-address": "52:54:00:82:49:b1", "expiry-time": 1452594968 }, { "iaid": "8538545", "ip-address": "2001:db8:ca2:2:1::1a", "mac-address": "52:54:00:82:49:b1", "client-id": "00:04:ee:53:b7:a8:c7:46:ab:95:d0:86:88:ee:6e:51:a0:2a", "server-duid": "", "expiry-time": 1452594971 } ] Login guest to check ipv6 address . It is the same as the result returned by "domifaddr" Thanks Hongming On 01/11/2016 03:24 PM, Min Zhan wrote: > @shyu, > > Could you help have a look and reply this question? > > Regards, > Min Zhan > > ----- Forwarded Message ----- >> From: "Yaniv Kaul" <ykaul(a)redhat.com> >> To: libvirt-list(a)redhat.com >> Sent: Friday, January 8, 2016 5:40:09 PM >> Subject: [libvirt] DNS for IPv6 addresses? >> >> Is there a way to define DNS for IPv6 addresses? >> Something like: >> <dns forwardPlainNames =" yes " > >> <host ip =" 192.168.200.4 " > >> <hostname> lago_basic_suite_3_6_storage-iscsi </hostname> >> </host> >> </dns> >> >> >> >> Only for IPv6? >> I reckon I can't just use an IPv6 address in the 'IP' attribute? >> >> TIA, >> Y. >> >> -- >> libvir-list mailing list >> libvir-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list

1 0

[libvirt] Software Offloading Performance Issue on increasing VM's (TSO enabled ) pushing traffic
by Piyush R Srivastava1 12 Jan '16

12 Jan '16

Hi, Problem- Offloading (in Software) for VM generated packets ( TSO enabled in VM's ) degrades severely with increase in VM's on a host. On increasing VM's ( which are pushing traffic simultaneously ) on a compute node- - % offloaded packets coming out of VM's ( TSO enabled ) on tap port / veth-pair decreases significantly - Size of offloaded packets coming out of VM's (TSO enabled ) on tap porty / veth pair decreases significantly We are using OpenStack setup. Throughput for SNAT Test ( iperf client at VM and server at external network machine ) is SIGNIFICANTLY less that DNAT Test ( server at VM and client at external network machine). For 50 VM's ( 25 VM on each compute node on a 2 Compute Node setup ) SNAT throughput is 30% less than DNAT Throughput. I was hoping to get community feedback on what is controlling the software offloading of VM packets and how can we improve it ? NOTE- This seems to be one of the bottlenecks in SNAT which is affecting throughput at TX side on Compute Node. Improving this would help in improving SNAT test network performance. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Description- We have a testbed OpenStack deployment. We boot 1, 10 and 25 VM's on a single compute node and start iperf traffic. ( VM's are iperf client ). We then simultaneously do tcpdump at the veth-pair connecting the VM to the OVS Bridges. Tcpdump data shows that on increasing the VM's on a host, the % of offloaded packets degrades severely ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Host configuration- 12 cores ( 24 vCPU ), 40 GB RAM [root rhel7-25 ~]# uname -a Linux rhel7-25.in.ibm.com 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux VM MTU is set to 1450 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Analysis- Following is the % of non-offloaded packets observed at the tap ports / veth pair ( connected to VM's TO OVS Bridge ) ------------------------------------ | VMs on 1 Compute Node | % Non-Offloaded packets | |-----------------------------------| | 1 | 11.11% | | 10 | 71.78% | | 25 | 80.44% | |----|--------- | Thus we see significant degradation in offloaded packets when 10 and 25 VM's are sending iperf data simultaneously. ( TSO enabled VM's ) Non-Offloaded packets means Ethernet Frame of size 1464 ( VM MTU is 1450 ). Thus the packets coming out of the VM's (TSO enabled ) are majority non-offloaded as we increase VM's on a host. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tcpdump details- Iperf Server IP- 1.1.1.34 For 1 VM, we see majority offloaded packets and also large sized offloaded frames- [piyush rhel7-34 25]$ cat qvoed7aa38d-22.log | grep "> 1.1.1.34.5001" | head -n 30 14:36:26.331073 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 74: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 0 14:36:26.331917 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 66: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 0 14:36:26.331946 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 90: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 24 14:36:26.331977 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.332018 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 5658: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 5592 14:36:26.332527 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.332560 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 9852: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 9786 14:36:26.333024 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 8454: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 8388 14:36:26.333054 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.333076 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 4260: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 4194 14:36:26.333530 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 16842: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 16776 14:36:26.333568 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 4260: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 4194 14:36:26.333886 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 21036: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 20970 14:36:26.333925 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 2862: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 2796 14:36:26.334303 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 21036: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 20970 14:36:26.334349 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 2862: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 2796 14:36:26.334741 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 22434: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 22368 14:36:26.335118 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 25230: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 25164 14:36:26.335566 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 25230: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 25164 14:36:26.336007 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 23832: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 23766 For 20 VM's, we see reduction is size of offloaded packets and also the size of offloaded packets is reduced. Tcpdump for one of the 10 VM's ( similar characterization for all 10 VM's )- [piyush rhel7-34 25]$ cat qvo255d8cdd-90.log | grep "> 1.1.1.34.5001" | head -n 30 15:09:25.024790 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 74: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 0 15:09:25.026834 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 66: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 0 15:09:25.026870 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 90: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 24 15:09:25.027186 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.027213 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 5658: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 5592 15:09:25.032500 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 5658: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 5592 15:09:25.032539 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 1464: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 1398 15:09:25.032567 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035122 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035631 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035661 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.038508 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.038904 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.039300 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 For 25 VM's, we see very less offloaded packets and also the size of offloaded packets is reduced. Tcpdump for one of the 25 VM's ( similar characterization for all 25 VM's )- 15:52:31.544316 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.544340 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545034 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545066 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 5658: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 5592 15:52:31.545474 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545501 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 2862: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 2796 15:52:31.545539 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 2862: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 2796 15:52:31.545572 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 7056: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 6990 15:52:31.545736 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545807 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545813 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545934 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545956 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545974 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.546012 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 Thanks and regards, Piyush Raman Mail: pirsriva(a)in.ibm.com

1 0