[PVE-User] VM inaccessible, Virtual LAN CARD issue

[Paul Gray]

>         On Sat, Jul 27, 2013 at 4:45 PM, Muhammad Yousuf Khan
>         <sirtcp at gmail.com <mailto:sirtcp at gmail.com>> 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.

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.

*) Check ifconfig on the host - does it show the state of the interface
as UP?  Are there errors?  For example:

gray at 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.

If the interface is not up or there are errors, check the logs on the
host for possible causes.

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?)

*) 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)?

*) 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?

*) Anything such as iptable scripts, fail2ban or portsentry in place
that would be intercepting traffic?

If none of the above apply, please provide more specifics on your
implementation: The OS's involved, the .conf file for the VM, etc.
-- 
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."