[PVE-User] VM inaccessible, Virtual LAN CARD issue
Muhammad Yousuf Khan
sirtcp at gmail.com
Sun Jul 28 14:56:11 CEST 2013
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
> 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
> 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?
> *) 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,
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pve-user