[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] No dom0/domU ping "out of the box"


After a morning at the dentist, I return to more enjoyable things ...

I think I have it:  Using debug traces as you suggested, I found that
ifdown on eth0 was failing but returning exit code 0.  It failed because
it thought the interface was not up -- because somehow the
ifupdown-clean link went missing from my boot scripts.  (I can see that
it's a reasonable thing for ifdown to use exit status 0 in this case,
but it was confusing.)

So, the subsequent renaming operation failed because the interface was
still up.  (Again confusing without the traces since the command doesn't
report its own name in its error message.)

Fixing the boot script link seems to make things work OK.

Thanks a lot for your suggestions,

Colin Brown

>>> Patrick Wolfe <pwolfe@xxxxxxxxxxxxxx> 03/29/06 5:18 PM >>>
Destination Host Unreachable means they cannot ARP one another.

I think the reason they cannot reach each other is because your
network-bridge script is failing, as you mentioned before.

For the domU to reach the dom0, they both must be on the same network.
You said "brctl show" only shows vif4.0 attached to xenbr0, which means
the domU is on a network all by itself, and the dom0 is using eth0 to
connect to the real world.

Since there is no network connection between the real world and your
internal "xenbr0" virtual ethernet hub, the two machines cannot talk to
each other.

The way "network-bridge" works, is to:
1) create a virtual ethernet hub called "xenbr0"
2) unplug your dom0 from the outside world (physical eth0)
3) connect the the physical interface eth0 to the xenbr0, and rename it
4) connect a virtual ethernet cable (veth0 and vif0.0) between the
xenbr0 ethernet hub and dom0.  The veth0 side gets attached to your dom0
(and gets renamed eth0), the vif0.0 side gets attached to the virtual
ethernet hub.
5) Then, when your domU comes up, it gets attached to the virtual
ethernet hub using it's eth0 which xen connects to dom0's vif#.0 (where
# is the domain id number).

You might need to enable xend debug, and review
the /var/log/xend-debug.log and syslog for xend messages indicating what
the problem is.  Maybe add some echo statements to the network bridge
script to help figure out what it is doing wrong.

I have brought up a number of xen installations using debian.  the
default config does work, for me.

On Wed, 2006-03-29 at 12:23 -0500, Colin Brown wrote:
> Sorry if this is covered somewhere else in the archives, but I don't
> a case that has symptoms that match my case.
> I installed Xen 3 in a pretty-close-to-vanilla Debian bootstrap. 
> the default Xen configuration (network-route and vif-route), I cannot
> get ping to work in either direction between a domU and dom0.  Both
> sides report "Destination Host Unreachable".  
> Domain config params (among others):
>   ip     = ""  
>   gateway= ""
>   netmask= ""
>   vif = [ '' ]
>   dhcp   = "off"
> If your debian host is configured correctly
> On dom0, ifconfig reports presence of eth0, lo, vif4.0 and xenbr0.  I
> see no signs of the peth0 or vif0.0 interfaces mentioned in the
> XenNetworking wiki article.  A brctl on xenbr0 reveals only one
> interface on xenbr0 (vif4.0).  So, what happened to peth0 and vif0.0? 
> How do I investigate further?
> I want to identify dom0 to the domUs as, so (and I'm
> out of ignorance here) I set the ip address on vif4.0 to
> under the assumption that the "virtual crossover cable" between eth0
> domain 4 and vif4.0 on dom0 is the moral equivalant of a cable between
> two physical machines.  Am I close here?
> On domU (domain 4), ifconfig reveals lo and eth0, the latter having
> correct ip address,
> However, pings from either vm to the other's ip address fail with
> "Destination Host Unreachable".  Yet I do see appropriate TX and RX
> packet counts in eth0 in domU and vif4.0 in dom0.
> Pings to do work on both machines.
> Suspecting routing/filtering issues, I checked that iptables on either
> machine reports accept policy for all filtering tables and no other
> entries.  And route reports what seem to be reasonable routing:
>  - on domU: 
> UH    0      0        0
> eth0
>   U     0      0        0If
your debian host is configured correctly
> eth0
>         UG    0      0        0
> eth0
> - on dom0
> UH    0      0        0
> vif4.0
>   U     0      0        0
> vif4.0
>   U     0      0        0
> eth0
>         UG    0      0        0
> eth0
> The 69.165.xxx is my ISP dynamically-assigned stuff.  (I'm not
> interested in the domUs having access to the ISP.)
> Those route entries, by the way, may not be exactly how they were
> automatically set up since I've been fiddling a bit and don't recall
> I did any route changes that I didn't undo.
> I'm guessing that my boot scripts in either dom0 or domU or both are
> doing some hidden mucking with networking that I'm not seeing -- the
> world of Linux networking is new to me, as you can probably tell.  I
> think I understand what I know but I think there is lots I'm not aware
> of.
> So I end with these questions:
> 1. Where do I look from here?
> 2. What are the possible causes of "Destination Host Unreachable"?
> 3. Why doesn't the bridge look like the wiki article XenNetworking
> describes so nicely?
> 4. Is my guess of setting the dom0 ip address on vif4.0 in anywhere
> the right direction?If your debian host is configured correctly
> 5. If not, how should I set things up if my primary ip address on dom0
> is dynamically assigned by my ISP and I want my domUs to have static
> addresses and static addresses for their gateway?
> Thanks in advance,
> Colin Brown
> CIS -- Franklin University
> Colin William Brown (Bill)
> Visiting Professor -- Computer Science
> Franklin University
> brownc@xxxxxxxxxxxx
> 1-614-341-6218
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
Patrick Wolfe  (pwolfe@xxxxxxxxxxxxxx)

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.