Why cannot I ping an xen domU with Bridge mode connection

bridgenetworkingxen

I am on a Debian upgraded from 7.11 to 8.5, so the xen package is upgraded from 4.1 to 4.4.

I do not know much about networks, but when I see a diagram like this (taken from the Xen Networking wiki page), I expect to be able to ping 198.51.100.27 with ping -I xenbr0 198.51.100.27, and vice versa from the virtual machine ping 198.51.100.1.

However, this is not the case. I set up a clean xenbr0 with

# brctl addbr xenbr0
# ifconfig xenbr0 192.168.12.1 netmask 255.255.255.0 up

and in the HVM configuration file

vif=["mac=11:22:33:44:55:66, ip='192.168.12.2', bridge=xenbr0"]

After I start the VM with xl create, this is the output from brctl show:

bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              vif3.0
                                                        vif3.0-emu

I connect to the VM with SPICE and configure it as shown below:

enter image description here

And since I am only trying to ping the default gateway I assume no name resolving will take place.

With this setup, ping 192.168.12.2 -I xenbr0 on the dom0 results in

PING 192.168.12.2 (192.168.12.2) from 192.168.12.1 xenbr0: 56(84) bytes of data.
From 192.168.12.1 icmp_seq=1 Destination Host Unreachable

and from the Windows VM, ping 192.168.12.1 from cmd has the output

Pinging 192.168.12.1 with 32 bytes of data:
Reply from 192.168.12.2: Destination host unreachable.

which suggests the machines have no idea about how to reach each other. Aren't they supposed to be linked by xl create? Why does this happen?

Best Answer

If everything is setup correctly, you should be able to ping, no problem.

At first, try the recommended configurations:

If you are just wanting to study how the routes work, you might make a paravirtualized (PV) setup, instead of HVM, as you mentioned; but if you stick with HVM make sure you have the drivers for Windows installed. This is all outlined at the very top of the Xen guide. It also explains how to assign a MAC address, the MAC address in the post as of writing, is invalid--which is ok sometimes for virtual situations, but not for every configuration.

When you setup your xenbr0 on the host, the bridge essentially replaces the eth0 interface on Debian-based systems. It is true that (from the xen guide) eth0 is optional "By omitting the physical Ethernet device an isolated network containing only guest domains can be created," but the examples in the guide, as well as your post here, are not worded that way. For future readers as well, in a Fedora-family virtual client, as well with Windows, please see all the documentation for slightly different configuration requirements. This, specifically sounds like your problem, unless you are blocked by a firewall, tcp wrappers, or anything else not mentioned in the original post.

Confirmation

In Windows you can verify the network setup with, for example, ipconfig /all.

In the Xen sample configurations from the same website that we both already referenced, it suggests below, as well as other configurations, for the host; for example, type all of the below, without skipping the first part.

Example 2: A single bridged network using eth0 configured with a static local IP address

iface eth0 inet manual

iface xenbr0 inet static

    bridge_ports eth0
    address 192.168.1.2
    broadcast 192.168.1.255
    netmask 255.255.255.0
    gateway 192.168.1.1

You can confirm this with ifconfig and route on both your dom0 and dom1, or similar tools on the host, as explained in the link above and make sure that it is all configured correctly.

Basic tweaking

If you want to make sure that neither reach the internet (or other parts of a network, in general), other than keeping the physical cable unplugged of course, you could change the default gateway to 0.0.0.0, and then add a "route" (a box should be just below in most Network Manager-style GUIs), with the same client IP address and subnet mask, but then with the address of the host, as a gateway. In some GUIs there is even a box that says something like "allow this connection route only for the local network."

Adding a "route" in your Windows client may also act as a work around to solve your original problem.

Related Question