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

[Muhammad Yousuf Khan]

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 <sirtcp at gmail.com>wrote:

>
>
>
> On Sun, Jul 28, 2013 at 4:46 PM, Paul Gray <gray at cs.uni.edu> wrote:
>
>> >         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.
>>
>> 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 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.
>>
>
> 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
>> pve-user at pve.proxmox.com
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20130731/4a0873c3/attachment.htm>