Hi,

I have a CentOS 5.2 dom0 running several CentOS domU guests with statically assigned IP addresses and LVM for their block devices.

The specific configuration I have for a domU:

name = "zimbra.lireo.net"
memory = "512"
disk = [ 'phy:vg00/lv04,xvda,w', ]
vif = [ 'bridge=xenbr0', ]
vcpus=1
bootloader="/usr/bin/pygrub"
on_reboot = 'restart'
on_crash = 'restart'

The IP address is configured in domU's /etc/sysconfig/network-scripts/ifcfg-eth0 and works properly.

However, if the domU is restarted for any reason, the configuration in domU reverts to DHCP, and is inaccessible from the Internet until I console in from dom0 and reset it.

[root@zimbra ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Xen Virtual Ethernet
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes


I tried changing the vif paramater in the domU's config above to the following:

vif = [ 'bridge=xenbr0', 'ipaddr=75.127.98.92', 'netmask=255.255.255.0' ]

But that gives me Invalid vif upon "xm create" command.


Questions:
1. Can I assign the IP address through Xen config file? If so, what's the correct format? (the Xensource wiki and CentOS/RHEL docs and the xmexamples don't give clear info on this).
2. If I can't, how do I get the IP address configured in the domU to persist across reboots, and NOT be reset to DHCP?


The Googling I've done so far all point to modifying the xen network-bridge script, but they're all mailing list posts from 2005. I suspect I'm missing something quite simple and obvious.

In the future, I'll probably set up DHCP to manage IP address assignments when I have enough Xen domUs to make it worth it. But with one dom0 and two or three personal-use domUs, I don't exactly need that just yet.

I use Xen on Ubuntu but I believe the answer is Yes you can and should use the domU's own configuration.(the config it uses AFTER booting) lol it gets confusing.
In Ubuntu the file to edit is /etc/network/interfaces (once you boot the xen domU /guest machine)

and the lines in there goes something like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 123.213.12.23
netmask 255.255.255.0
gateway 123.213.12.1

auto eth1
iface eth1 inet static
address 10.0.50.23
netmask 255.255.255.0

as you can see the # is the remarks and the IP addresses are set manually for eth0 and eth1 (in your case only eth0).

I have only seen DHCP used in the domU config file (The config file you use FOR Booting the xen guest/domU machine and in Ubuntu the xen directory is under /etc/)but I have not seen that for static IP. I guess the static IP should be configured within the xen guest machines.(the configuration it uses After it boots)

dhcp example in xen guest (domU config file):


# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:1D:24:00' ]

#

Sorry I am not very familiar with CentOS but they should be similar configuration

You can assign static IP with xen. Try using ip instead of ipaddr. Also, you want to quote the entire string in brackets, not each parameter string. For example try:

vif= ["bridge=xenbr0,ip=75.127.98.92,netmask=255.255.255.0" ] <-- (you should probably add a "gateway=" to this and maybe a "mac=" just to keep everything sorted out)

That way, if you have 2 or more NICs, you add another quoted string separated by a comma for each interface.

I suggest do all network configuration inside domU itself
dont config network inside xenhost for domU,

inside domU run system-config-network or you can edit this file directly
1) /etc/sysconfig/network
2) /etc/sysconfig/network-scripts/ifcfg-eth0

then reboot from it

That's the problem. The ifcfg-eth0 file *is* configured inside the domU, but it completely reverts to DHCP on reboot. It's like something in Xen is forcing a DHCP configuration on all domUs.

This happens to all domUs on this box, by the way.

Thanks kbgreen72. Using "ip=" instead of "ipaddr" got rid of that error. Though it didn't like the netmask argument (which I found out below needs to be set elsewhere). I removed the netmask and started the domU (gateway is already set in /etc/sysconfig/network in the domU itself...that at least is not being overwritten).

but again, upon boot, the ifcfg-eth0 file is reverted:

[root@zimbra ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Xen Virtual Ethernet
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
HWADDR=00:16:3e:60:88:65

So, something in Xen is setting this "default" DHCP configuration.
In the xmexample1 file, there is this:

Since dhcp="dhcp" is NOT set in my domU config, and since the domU's IP address info *is* configured in /etc/sysconfig/network-scripts/ifcfg-eth0, it should work as currently configured. But something in Xen (as best I can tell) is still overwriting that file with a default DHCP configuration from somewhere.

Thanks Matey. It sounds like your Ubuntu config is similar to my CentOS config (that is, the IP is configured *inside* domU and not in the domU config file residing on dom0).

So my question now is, "why is dom0 overriding domU's statically configured info for network addressing"?

That's the $64,000 question, which I hope will be answered by someone's $0.02 .

I exactly have the same problem, and same conf as you...
As far as I went on googling this problem I only could guess it comes from CentOS as domU which can't get static ip when rebooting.
I know my answer sounds like a joke but I really can't find anything else,
Did you find any clue or answer to that problem ?

That is a good question, I think the one (configuration) that gets executed Last is the one that sticks!

I think the configurations in the Xen script is necessary for the guest machine to boot (not 100% sure but taking a guess) but once it boots the kernel file takes over and tells it to look under /etc for configurations just like any other machine.

I usually mount the xen guest machine at /mnt/xen/ directory then do a chroot to it then I make changes to configurations (set root password and hostname too) and then exit, umount it then xm create -c it.

regards;

Well, I found a partial solution since then, but never found the exact cause yet.

This install was largely to learn Xen and test for use with certain clients (the people kind, not the network kind). I used a couple of HOWTOforge/Linuxtopia guides for the set up, ,which were based on xm commands to load an installer image rather than using RHEL/CentOS libvirt tools . Since then, I've installed a newer machine that will go into production and used the Red Hat documentation to set up the Xen guests using virt-install/virt-manager.

The guests I configured with virt-install do not suffer from this problem, so it's probably something with the way the network is set up from the various guides I originally followed.

So my original problem is resolved.

I just stumbled on your question.

The problem is most likely that you are not specifying a mac address for the vif in you domU configuration.

Try:
Where x can be any hexadecimal digit (0-F).

If you don't specify a mac address explicitly, xen will generate another one each time the domU is created. Since the mac address has changed, CentOS detects the nic as a new nic (and the old one is considered removed from the machine). CentOS will try to autoconfigure this new nic, and for that it chooses dhcp.
This is much the same as would happen with real physical hardware actually. If you swap a network card in an ordinary server, CentOS will remove the configuration for the old nic and create a new configuration for the new one.

So see if setting a fixed mac address for your domU solves the issue. This is what virt-install does as well, by the way.

Hopefully this answers your $64,000 question.

As a sidenote, the choice of these numbers comes from the xen networking wiki. You could use any mac address, but this series is reserved for xen use.

Old post but you solved the same problem I had with KVM using virt-install (copy and existing image and using --import caused a new ifcfg-eth0 file to be created with DHCP).

Thanks gjanssens!