[CentOS-virt] CentOS 6 and KVM woes

Sun Jul 17 01:24:51 UTC 2011
Nataraj <incoming-centos at rjl.com>

On 07/16/2011 04:58 PM, Trey Dockendorf wrote:
>
>
> On Fri, Jul 15, 2011 at 6:24 PM, Emmanuel Noobadmin
> <centos.admin at gmail.com <mailto:centos.admin at gmail.com>> wrote:
>
>     On 7/16/11, Trey Dockendorf <treydock at gmail.com
>     <mailto:treydock at gmail.com>> wrote:
>     > I have successfully bridged one of the server's NICs to br0, and
>     I can ping
>     > the IP remotely that is assigned to br0, but none of the VMs
>     that worked in
>     > 5.6's KVM are able to access the network.  Please let me know what
>     > information would be useful to troubleshoot this.
>
>     Could you try creating a new VM using the GUI tool, then check if the
>     networking works from it?
>
>     I was having problems with KVM and part of the troubleshooting process
>     got me to try it on SL6, which finally led me to discover that the
>     command line tool generated XML doesn't work as well as the GUI tool
>     for some reason. So there's the possibility that it could be that the
>     definitions created through virsh in 5.6 has the same issues in CentOS
>     6.
>     _______________________________________________
>     CentOS-virt mailing list
>     CentOS-virt at centos.org <mailto:CentOS-virt at centos.org>
>     http://lists.centos.org/mailman/listinfo/centos-virt
>
>
>
> I did try another VM (CentOS 6) via virt-manager with the same
> results.  However I setup a test server at home, and am able to get
> both bridging and NAT to work so this may be an issue with the network
> on my server.  It's a University network and their switches tend to
> play havoc with virtual servers even though I've been assured enough
> MAC addresses have been allowed on my port.  
>
> How does one troubleshoot or provide debug information on a correctly
> or incorrectly functioning network bridge?  As I contact my
> University's helpdesk I'd like to be able to point out the fault is
> not with my KVM server.
>
> Thanks
> - Trey
>
>
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> http://lists.centos.org/mailman/listinfo/centos-virt
If both the VM's and the server are on the same bridge and they can't
talk to each other, I would from both the server and VM end, ping the
opposite end and check the arp table to see if arp entries are getting
resolved, then I would run tcpdump on each respective end and send
packets from the other end and see if they are getting through.  If not,
then their is either a problem with either the VM's config file or the
networking/bridge config on the server.  (Of course if you have any kind
of ipfilter access lists, then I would check those).

Once you've got the above working, I would attempt to perform similar
tests to the outside.  If you happen to have a login on another host on
the same subnet, you can ping your VM and check the arp table to see if
there is arp resolution.  (Also check that you don't have duplicate ip
address assignments).  If there is arp resolution, then run tcp dump on
the vm (or the physical interface of the server) and see if you can see
the packets from outside.  Checking the reverse direction is harder if
you don't have root access on the remote end.

If your going through gateways, then run traceroute to see how far your
getting.

As I thought about it more, it's unclear weather your VM's are on a
seperate bridge from your server's external interface or they are
bridged directly onto it.  If the VM's are on a bridge that also has an
external interface on it, then you don't use NAT.  NAT would be if you
wanted your server to act as a router/firewall for the VM's in which
case the VM's would be on a separate bridge and the server would have
another external interface and would act as a router between the bridge
network and the external network.

This should be a start anyway.

Nataraj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20110716/036a7cba/attachment-0003.html>