<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/16/2011 04:58 PM, Trey Dockendorf wrote:
<blockquote
cite="mid:CAN0oX1aAmdmFWdV8pyFRagG1B507p+TiZqTDzigx9S5sifOJ7Q@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Fri, Jul 15, 2011 at 6:24 PM, Emmanuel
Noobadmin <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:centos.admin@gmail.com">centos.admin@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">On 7/16/11, Trey Dockendorf <<a
moz-do-not-send="true" href="mailto:treydock@gmail.com">treydock@gmail.com</a>>
wrote:<br>
> I have successfully bridged one of the server's NICs to
br0, and I can ping<br>
> the IP remotely that is assigned to br0, but none of
the VMs that worked in<br>
> 5.6's KVM are able to access the network. Please let
me know what<br>
> information would be useful to troubleshoot this.<br>
<br>
</div>
Could you try creating a new VM using the GUI tool, then check
if the<br>
networking works from it?<br>
<br>
I was having problems with KVM and part of the troubleshooting
process<br>
got me to try it on SL6, which finally led me to discover that
the<br>
command line tool generated XML doesn't work as well as the
GUI tool<br>
for some reason. So there's the possibility that it could be
that the<br>
definitions created through virsh in 5.6 has the same issues
in CentOS<br>
6.<br>
<div>
<div class="h5">_______________________________________________<br>
CentOS-virt mailing list<br>
<a moz-do-not-send="true"
href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a><br>
<a moz-do-not-send="true"
href="http://lists.centos.org/mailman/listinfo/centos-virt"
target="_blank">http://lists.centos.org/mailman/listinfo/centos-virt</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks</div>
<div>- Trey</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
CentOS-virt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a>
<a class="moz-txt-link-freetext" href="http://lists.centos.org/mailman/listinfo/centos-virt">http://lists.centos.org/mailman/listinfo/centos-virt</a>
</pre>
</blockquote>
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).<br>
<br>
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.<br>
<br>
If your going through gateways, then run traceroute to see how far
your getting.<br>
<br>
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.<br>
<br>
This should be a start anyway.<br>
<br>
Nataraj<br>
<br>
</body>
</html>