Search results

just to thank you for your time !!! regards

ok thanks for your help

yes we have support for this application. The problem, oracle doesn't validate proxmox as a supported platform virtualization...... That just running find for 2 years now... I'm thinking about sysctl value difference between squeez kernel pve2.4 and rhel kernel pve2.6/7 What do you think about...

My idea was just to confirm you encounter the same problem in your platform. The application is java based but can't affirm all the code is accessible.

All seems ok with ssmping. Here the result on the client side : [root@test1 ssmping-0.9.1]# ./asmping -4v 228.5.6.7 192.93.172.210 asmping joined (S,G) = (*,228.5.6.234) pinging 192.93.172.210 from 192.93.172.209 Server version: 0.9.1 (20080418) [asm][size] unicast from 192.93.172.210, seq=1...

yep i will test it ;) i'm currently installing the tool on the openvz containers do you want i send you my "application archive" in order you test it on your platform ? perhaps it's a local problem and i don't want consume your time badly.

I think not. It's only when we used the oracle tool that provide the error. Like i was saying in a precedent post, replaying the packet sent by the application with tcpreplay doesn't produce the problem.... On our proxmox cluster we have "clustered vm machine" which uses corosync which is based...

We have already disable it virt4:~# sysctl -a | grep all.rp_filter net.ipv4.conf.all.rp_filter = 0

Sorry if i'm not clear.... I make the two scema in ordre to clarify the problem : The first show than when we issued the multicast from an outside host, the proxmox bridge receive the packet but the guests never receive any packets. The second show than when we issued the multicast from a...

I confirm the problem arise with 2 vm on the same proxmoxbridge :)

No i always sent multicast packet from out of proxmox machine. I only get yesterday the "partial oracle application" to reproduce the problem. Since yesterday i can copy this "application" on any server to make tests........ But i make a mistake, we receive the packet at the bridge level...

yes you are right. All test we made before, we sent packet from external server (out of proxmox).

We have made the test with another multicast address , it's the same problem.

sorry i have not see your response. I maked the test and it's the same problem. With 2 openvz containers, one sending packet and the other receiving packet, nothing appear at the bridge level........ Guest A ----> | proxmox bridge | <---- Guest B Guest A send the packet, tcpdump on bridge get...

we don't use openvz but i will attempt to test it.... Just to be sure i'm correct. I make 2 openvz containers and i connect them to the ethernet bridge ?

yes there is the same problem with 2 vms on the same proxmox host on the same bridge

we have tested removing bonding and vlan tagging. Always the same problem.

The mac adress of the vm is : 00:16:3E:5C:13:5F (old imported Xen vm)

Thanks. A bug report was submitted on openvz bugzilla. http://bugzilla.openvz.org/show_bug.cgi?id=2201

thks, Could you say me if the following is correct : the pve2.6.32-4 is not openvz patched the two others are openvz patched That's why you think it's a openvz patch problem ?