<div dir="ltr"><div><div><div><div>same issue encounter once again in another machine this time i am sure about the MAC that it was not conflicting and it was Console generated machine which means i did not created the LAN manually.<br>
<br></div>one more thing i observe is that, if i restart the machine it does not fix the issue. <br></div>but when i shutdown the machine and start it again. it resolve the issue.<br><br></div>any idea please.<br><br>Thanks,<br>
<br></div>Myk<br><div><div><div><div><br><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 28, 2013 at 5:56 PM, Muhammad Yousuf Khan <span dir="ltr"><<a href="mailto:sirtcp@gmail.com" target="_blank">sirtcp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Sun, Jul 28, 2013 at 4:46 PM, Paul Gray <span dir="ltr"><<a href="mailto:gray@cs.uni.edu" target="_blank">gray@cs.uni.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> On Sat, Jul 27, 2013 at 4:45 PM, Muhammad Yousuf Khan<br>
</div><div>> <<a href="mailto:sirtcp@gmail.com" target="_blank">sirtcp@gmail.com</a> <mailto:<a href="mailto:sirtcp@gmail.com" target="_blank">sirtcp@gmail.com</a>>> wrote:<br>
<br>
> this is not happening very frequently . but happen once in a<br>
> 3 month and not on all machines but few machines.<br>
><br>
> the problem is, VM stop reaching the LAN and WAN.<br>
><br>
> when i ping , it says "destination host unreachable"<br>
<br>
</div>If you've verified the machine is up and ruled out any possible cabling<br>
issue, then I'd recommend the following to troubleshoot this further:<br>
<br>
*) Verify that the MAC assigned for the VM is unique. This really<br>
shouldn't be the issue, but you didn't state how the VMs were created<br>
nor whether this issue was aligned with VMs with certain<br>
characteristics. So I mention this just because it'd be one of the<br>
first things I'd check if I was manually scripting the creation of a the<br>
VMs.<br>
<br></blockquote></div><div>i use mostly command line to create VM, and there could not be an issue in MAC address since i bind the back with VM ID and VM ID is always unique. my binding i means i use VM ID in mack addresses. so i am very vigilant when i am creating LAN Cards <br>
</div><div class="im"><div><br> </div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You also didn't mention if this was across all OS'es in your system, or<br>
one particular OS. I'll assume that your issue is with Linux VMs, and<br>
if that's not the case, then read on for your enjoyment knowing that the<br>
same approach to troubleshooting works for other OS's as well.<br>
<br></blockquote><div><br></div></div><div>no i clearly mention that it is "windows 7", and no, i never observe such thing happening in Linux machine. i do not use openvz, instead only KVM. and never found anything like this happening in debian.<br>
</div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*) Check ifconfig on the host - does it show the state of the interface<br>
as UP? Are there errors? For example:<br>
<br>
gray@debian:~$ /sbin/ifconfig eth0<br>
eth0 Link encap:Ethernet HWaddr 00:aa:00:ae:5d:d0<br>
inet addr:192.168.10.211 Bcast:192.168.10.255 Mask:255.255.255.0<br>
inet6 addr: fe80::2aa:00ff:feae:5dd0/64 Scope:Link<br>
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
RX packets:260024861 errors:0 dropped:0 overruns:0 frame:0<br>
TX packets:139022869 errors:0 dropped:0 overruns:0 carrier:0<br>
collisions:0 txqueuelen:1000<br>
RX bytes:294358199688 (274.1 GiB) TX bytes:429610650518<br>
(400.1 GiB)<br>
Interrupt:23 Base address:0x2000<br>
<br>
Note on the 3rd line, the interface is listed as "UP".<br>
Note on the 4th and 5th lines, there have been no receive or<br>
transmission errors.<br></blockquote><div><br></div></div><div>bytheway, i will definitly try to check this next time on OS guest virtual network adapters bind to the VMs<br><br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If the interface is not up or there are errors, check the logs on the<br>
host for possible causes.<br>
<br></blockquote><div><br></div></div><div>nope it is up and showing limited connectivity "!" mark<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Check the same fields on the tap/bridge interface on the Proxmox hosts<br>
as well. (Are the hosts with problems connected to the bridge or NAT'd?<br>
or a mix of both?)<br>
<br></blockquote></div><div>yes, as i said i will try suggested next time when it happens. <br><br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*) If the interfaces are all up and no errors reported, ping from and to<br>
the host again (which is going to fail...yes). Immediate afterward,<br>
check the arp tables on both the host and the proxmox server to see if<br>
the arp tables are correct. Check "/usr/sbin/arp -n". Is the target<br>
MAC listed as (incomplete)?<br>
<br></blockquote><div><br></div></div><div>ok, thanks for the tip<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*) Fire up tcpdump and watch for ARP negotiation and subsequent ICMP<br>
packets working their way across the network. Where does the paradigm<br>
start to fail?<br></blockquote><div><br></div></div><div>ok!<br><br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
*) Anything such as iptable scripts, fail2ban or portsentry in place<br>
that would be intercepting traffic?<br>
<br></blockquote></div><div>nope, my OS is clean from all of that because they are already behind a firewall so no need for iptable<br><br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If none of the above apply, please provide more specifics on your<br>
implementation: The OS's involved, the .conf file for the VM, etc.<br>
<span><font color="#888888"></font></span></blockquote><div><br></div></div><div>ok i will do that, <br><br></div><div>Thanks<br></div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888">--<br>
Paul Gray -o)<br>
314 East Gym, Dept. of Computer Science /\\<br>
University of Northern Iowa _\_V<br>
Message void if penguin violated ... Don't mess with the penguin<br>
No one says, "Hey, I can't read that ASCII attachment ya sent me."<br>
</font></span><div><div>_______________________________________________<br>
pve-user mailing list<br>
<a href="mailto:pve-user@pve.proxmox.com" target="_blank">pve-user@pve.proxmox.com</a><br>
<a href="http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user" target="_blank">http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user</a><br>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div>