I've got a Centos guest and a Windows 2003 server guest running in Xen under Centos (5.2 in both cases), and they can get out to the network, and I can ping them from dom0. This is my first Xen install, and I haven't used Linux as a router before (I'm very familiar with it as a webserver and development platform) so I'm a bit weak on the bridging code and NAT / IP masquerading. (Amusingly, I was a voting member of IEEE 802.1 and worked on the .d standard for bridging; that was back when it was new, more than a decade ago, and my memories from then may be doing more harm than good now.)
The problem is, I can't originate a connection to either guest from outside.
Dom0 is getting IP 192.168.1.91 (from our enterprise DHCP server), which is a reasonable address. There are two bridges created, xenbr0 and virbr0. Virbr0 has an IP of 192.168.122.1 assigned to it, which evidence suggests did *not* come from our DHCP server. The interfaces for the two guest domains have 192.168.122.185 and .198 assigned, also not from our DHCP server. The IPs plus the behavior (can't connect in, can connect out) make it look very much like NAT has been setup, but I can't find any evidence like a "MASQUERADE" target in the dom0 iptables or anything (I've never run NAT on Linux, I could be looking for the wrong thing in the wrong place).
This setup does not look anything like the "default" bridging config I find documented on various Xen websites (particularly http://wiki.xensource.com/xenwiki/XenNetworking). None of them have "virbr0". I've seen a number of reports that people's working configurations broke when the upgraded to Centos 5.2, so I'm suspecting that what I'm seeing here is how Centos 5.2 chooses to package Xen. And hence I'm asking on a Centos list :-).
I created these guests in virt-manager. I selected the "bridging" network configuration.
Oh, ip forwarding is on in dom0; that was one of the things several places I looked said was an obvious fix for my problem, but it was already on in the default config, and it wasn't helping.
I'm currently not using either vlan or bonding, though I believe both are in my future. One thing at a time; and if I understand the basics I think I just might be able to take it to the next stage.
This has gotta be simple; I want the most basic bridged configuration, with the guests directly visible to the outside world. Any ideas?
On Thu, August 21, 2008 10:23, David Dyer-Bennet wrote:
The problem is, I can't originate a connection to either guest from outside.
Solved my own problem. And found I'd forgotten the choices, so maybe my description didn't fully make sense either.
I was indeed running my guests behind NAT, and eventually found that "iptables -t nat -L" would show the MASQUERADE target I believed was there. So I confirmed that I'd ended up, unintentionally, behind NAT.
By creating a new guest, I found that the networking choices were not what I had remembered. Clearly my NAT situation came from selecting "virtual networking". When I instead told it to associate the network with a physical device, I got my new guest connected to xenbr0 as I had expected all along.
I had tried to change my guests over to connecting to xenbr0 previously, and it turns out I got the syntax slightly wrong -- the two arguments in the config file to vif should have been in a single set of quotes, separated by commas, rather than two separate arguments each quoted. When I had the config file for the new guest that wasn't behind NAT to compare to, that became obvious, and making the change to the config files changed the way they were connected as expected. And so now all three guests, the two old ones and the new one, are externally visible, and get IPs in our normal range from the DHCP server. (Well, actually I've made another change since then, and went in and attached the static internal IPs I'd been assigned to them.)
I've still got virbr0 and the NAT setup sitting around vestigially; I haven't looked closely at how to get rid of that. Not important for now, because this is a scratch install (as I said, my first time using Xen), so next time when I do it right I won't have that left over.
To recap, and put the search terms closer together for future users, the presence of virbr0 with the IP address 192.168.122.1, and a NAT setup, was a consequence of selecting "virtual networking" for my original Xen guest OSs.
Win!
Hope this helps somebody in the future.
-
David Dyer-Bennet