- Users - libvirt List Archives

[libvirt-users] Trouble with volume permissions
by Frank Laszlo 20 Jan '16

20 Jan '16

I'm working on an integration that uses QCOW2 volumes with backing stores. I have qemu configured to run as the "qemu" user, which seems to be fine. I now need to make sure my volumes are readable by this user. However, it seems the volume being created is owned by root, instead of "qemu" as I'd expect it to be. I tried various things and was unable to get it to create the file as the correct user. I've supplied a link to the XML I'm using to create the volumes. If anyone has any ideas it would be massively helpful. Thanks Link to XML: http://pastebin.com/kbg9n6kW -- Frank Laszlo Nexcess - Beyond Hosting 21700 Melrose Ave. Southfield, MI. 48075 Cell: +1.248.602.6123 Phone: +1.866.639.2377 Fax: +1.248.281.0473

2 1

[libvirt-users] guest memory monitor
by frankpersist＠gmail.com 20 Jan '16

20 Jan '16

Hi, everyone, My hypervisor is kvm, when I use libvirt-java api to get guest vm memory information, I found what libvirt can not get real memory(within the vm)statistic, libvirt can only get information from .xml file(such as vmName.xml <currentMemory> lable) in host. My question is, does libvirt support memory monitor(within vm)? if it's true, how to get. if false, what is the difficulty? Thank you. frankpersist(a)gmail.com

2 1

[libvirt-users] how to setup a watchdog?
by lejeczek 14 Jan '16

14 Jan '16

hi everybody I'm testing Qemu's watchdog. My understanding was that hardware (here qemu's watchdog) would take action(cold reboot) the system if there is no ping from the OS watchdog, so I thought stopping watchdog service in VM should be a quick test. I have this in the guest: <watchdog model='i6300esb' action='reset'> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </watchdog> and I see /dev/watchdog in my guest. Yet nothing happens. I must be missing something, an expert said it's config problem? many thanks

1 0

[libvirt-users] libvirt + ceph rbd will hang
by 王李明 14 Jan '16

14 Jan '16

hi all： I use openstack icehouse and libvirt 0.10 version use the quem+ceph to save vm disk when I do serval operation for example migrate vm、snapshot vm the libvirtd will be hang I guess whether the ceph rbd will cause this error anyone can help me? Wang Liming

1 0

[libvirt-users] virsh attach-device : Bus 'pci.0' does not support hotplugging.
by Keyur Bhalerao 14 Jan '16

14 Jan '16

Hi , Trying to attach a disk to existing VM using virsh attach-device - XML <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'/> <source file='/var/lib/libvirt/images/guest.qcow2'/> <target dev='vdc' bus='virtio'/> </disk> After executing the command I am getting - [root@cent7 ~]# virsh attach-device lib-virt-man-001 newDisk.xml error: Failed to attach device from newDisk.xml error: internal error: unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging. [root@cent7 ~]# virsh version Compiled against library: libvirt 1.2.17 Using library: libvirt 1.2.17 Using API: QEMU 1.2.17 Running hypervisor: QEMU 1.5.3 While searching on this issue found that some have suggested to install following - modprobe acpiphp modprobe pci_hotplug I am not sure if this is QEMU issue or libvirt issue. Any help in this would be appreciated. Thanks, Keyur Bhalerao

1 0

[libvirt-users] RBD snapshots
by Emmanuel Lacour 13 Jan '16

13 Jan '16

Dear libvirt users, I'm stuck on this subject and would appreciate a working example as this looks a supported feature :) After many tries and packages backports, here is my current setup: qemu 2.5 libvirt 3.0 ceph hammer on Debian jessie. Here is the relevent domain xml parts: <disk type='network' device='disk' snapshot='internal'> <driver name='qemu' type='raw'/> <auth username='libvirt'> <secret type='ceph' uuid='xxxxxxxxxxxxxxxx'/> </auth> <source protocol='rbd' name='libvirt-pool/vm-test'> <host name='192.168.253.1' port='6789'/> <host name='192.168.253.3' port='6789'/> <host name='192.168.253.254' port='6789'/> <snapshot name='backup'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> After several tries, I discovered the snapshot option in source tag, and that I need to pre-create this snapshot using rbd so the vm can start. But then I tried: # virsh snapshot-create-as vm-test error: unsupported configuration: internal snapshot for disk vda unsupported for storage type raw # virsh snapshot-create-as vm-test snap1 --memspec file=/tmp/vm-test.mem --diskspec vda,snapshot=internal error: unsupported configuration: internal snapshot for disk vda unsupported for storage type raw # virsh snapshot-create-as vm-test snap1 --disk-only --atomic --diskspec vda,snapshot=internal error: unsupported configuration: active qemu domains require external disk snapshots; disk vda requested internal and some other test, without any success:( What I just would like to achieve is to do a consistent disk snapshot of the VM without VM shutdown (suspend is ok) and using virsh as this seems supported (I can manually run rbd snap create, I know). And if possible whol mem+disk consistent snapshot without downtime :) Any hint to make this working, as anyone out ther having succes in such process?

1 0

[libvirt-users] vdsm hook issues
by Jean-Pierre Ribeauville 12 Jan '16

12 Jan '16

Hi, 1) is it enough to add a hook.py in /usr/libexec/vdsm/hooks/before_vm_start directory , and then shut down and reboot a guest to see this hook.py invoked ? 2) when running manually my hook.py, I got following error : ImportError: No module named hooking Do I have to install anything to solve this issue ? Thanks for help. Regards, J.P. Ribeauville P: +33.(0).1.47.17.20.49 . Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant d'imprimer.

2 2

Re: [libvirt-users] libvirt-users Digest, Vol 73, Issue 12 ] Failure when attaching a device
by Jean-Pierre Ribeauville 12 Jan '16

12 Jan '16

Hi, I think that issue is due to the fact that my Guest is a transient domain. When shutting down it or migrating to another host , then virsh list --all doesn't show this Guest anymore. How may I make this Guest a persistent one ? ( i.e. this Guest has been created via RHEV-M GUI) Thx for hlep. Regards, J.P. -----Message d'origine----- De : libvirt-users-bounces(a)redhat.com [mailto:libvirt-users-bounces@redhat.com] De la part de libvirt-users-request(a)redhat.com Envoyé : lundi 11 janvier 2016 21:25 À : libvirt-users(a)redhat.com Objet : libvirt-users Digest, Vol 73, Issue 12 Send libvirt-users mailing list submissions to libvirt-users(a)redhat.com To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/libvirt-users or, via email, send a message with subject or body 'help' to libvirt-users-request(a)redhat.com You can reach the person managing the list at libvirt-users-owner(a)redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of libvirt-users digest..." Today's Topics: 1. Networking with qemu/kvm+libvirt (Andre Goree) 2. Failure when attaching a device (Jean-Pierre Ribeauville) 3. Re: Networking with qemu/kvm+libvirt (Laine Stump) 4. Unable to validate doc against .... (Jean-Pierre Ribeauville) ---------------------------------------------------------------------- Message: 1 Date: Mon, 11 Jan 2016 14:25:21 -0500 From: Andre Goree <andre(a)drenet.net> To: libvirt-users(a)redhat.com Subject: [libvirt-users] Networking with qemu/kvm+libvirt Message-ID: <100725aa681e75449b9da623e7a7cf1a(a)drenet.net> Content-Type: text/plain; charset=UTF-8; format=flowed I have some questions regarding the way that networking is handled via qemu/kvm+libvirt -- my apologies in advance if this is not the proper mailing list for such a question. I am trying to determine how exactly I can manipulate traffic from a?_guest's_ NIC using iptables on the _host_. On the host, there is a bridged virtual NIC that corresponds to the guest's NIC. That interface does not have an IP setup on it on the host, however within the vm itself the IP is configured and everything works as expected. During my testing, I've seemingly determined that traffic from the vm does NOT traverse iptables on the host, but I _can_ in fact see the traffic via tcpdump on the host. This seems odd to me, unless the traffic is passed on during interaction with the kernel, and thus never actually reaches iptables. I've gone as far as trying to log via iptables any and all traffic traversing the guest's interface on the host, but to no avail (iptables does not see any traffic from the guest's NIC on the host). Is this the way it's supposed to work? And if so, is there any way I can do IP/port redirection silently on the _host_? Thanks in advance for any insight that anyone can share :) -- Andre Goree -=-=-=-=-=- Email - andre at drenet.net Website - http://www.drenet.net PGP key - http://www.drenet.net/pubkey.txt -=-=-=-=-=- ------------------------------ Message: 2 Date: Mon, 11 Jan 2016 19:35:29 +0000 From: Jean-Pierre Ribeauville <jpribeauville(a)axway.com> To: "libvirt-users(a)redhat.com" <libvirt-users(a)redhat.com> Subject: [libvirt-users] Failure when attaching a device Message-ID: <1051EFB4D3A1704680C38CCAAC5836D292F0218E(a)WPTXMAIL2.ptx.axway.int> Content-Type: text/plain; charset="iso-8859-1" Hi, I'm facing following issue ( or misunderstanding from my side) I try to attach a device to a running guest ; I want to do it persistently and without having to restart the GUEST . By using options "-live - persistent" , I got following error : [root@ldc01omv01 data]# virsh attach-device VM_RHEL7-1 "../data/channel_omnivision_to_be_used.xml" --live --persistent Please enter your authentication name: root@ldc01omv01 Please enter your password: error: Failed to attach device from ../data/channel_omnivision_to_be_used.xml error: Requested operation is not valid: cannot modify device on transient domain [root@ldc01omv01 data]# virsh -r list --all Id Name State ---------------------------------------------------- 8 VM_RHEL7-2 running 11 W2008R2-2 running 12 VM_RHEL7-1 running By using options "-live " , I got following error : [root@ldc01omv01 data]# virsh attach-device VM_RHEL7-1 "../data/channel_omnivision_to_be_used.xml" --live Please enter your authentication name: root@ldc01omv01 Please enter your password: error: Failed to attach device from ../data/channel_omnivision_to_be_used.xml error: Unable to read from monitor: Connection reset by peer [root@ldc01omv01 data]# virsh -r list --all Id Name State ---------------------------------------------------- 8 VM_RHEL7-2 running 11 W2008R2-2 running [root@ldc01omv01 data]# And then the Guest is powered off !! If I try to attach device when the Guest is off , then : [root@ldc01omv01 data]# virsh attach-device VM_RHEL7-1 "../data/channel_omnivision_to_be_used_1.xml" --config --persistent Please enter your authentication name: root@ldc01omv01 Please enter your password: error: failed to get domain 'VM_RHEL7-1' error: Domain not found: no domain with matching name 'VM_RHEL7-1' FYI , xml file contents is : <channel type='unix'> <source mode='bind' path='//var/lib/libvirt/qemu/VM_RHEL7-1_omnivision_1.agent'/> <target type='virtio' name='omnivision_1.agent'/> </channel> I'm using libvirt-1.2.17-13.el7.x86_64 Any help is welcome. Thanks. Regards, J.P. Ribeauville P: +33.(0).1.47.17.20.49 . Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez ? l'environnement avant d'imprimer.

2 2

[libvirt-users] Unable to validate doc against ....
by Jean-Pierre Ribeauville 12 Jan '16

12 Jan '16

Hi, By trying to add this device : <channel type='unix'> <source mode='bind' path='//var/lib/libvirt/qemu/VM_RHEL7-1_omnivision_1.agent'/> <target type='virtio' name='omnivision_1.agent'/> </channel> Within config file by issuing virsh edit , I got following error when to saving the config file : Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Extra element devices in interleave I'm using libvirt-1.2.17-13.el7.x86_64 Is there my mistake or a known issue ( quite sure it was working with former release) Thx for help. Regards, J.P. Ribeauville P: +33.(0).1.47.17.20.49 . Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant d'imprimer.

2 1

[libvirt-users] 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