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