[CentOS-virt] xenbr0 isn't created anymore

Fri Mar 28 18:10:30 UTC 2008
Kai Schaetzl <maillists at conactive.com>

Ross S. W. Walker wrote on Fri, 28 Mar 2008 12:20:54 -0400:

> Hmmm, how about in the /xen/scripts/vif-bridge script? Does it provide
> those comments there?

No, none of the files contain "qemu".

> It may be that the implementation of Xen in CentOS depends on the libvirtd
> service installed and running and all VMs running off of virbr0?

No, it worked fine after the upgrade (there was at least one VM using xenbr0). I 
didn't create new VMs with virt-manager
after the upgrade for a while, I just cloned the config files. But then I started
testing VMs with LVM volumes and create a whole new one with virt-manager. That was
the first time I noticed that virbr0 gets used (and I started asking about it here).
Something must be changing the ip route output and that is the reason why the xen
bridging stopped working. I enabled portmap on that day, disabled a few services and
removed the Java yum group. That should be it, more or less.

> Here is the output of 'brctl show' on my box:
> bridge name     bridge id               STP enabled     interfaces
> eth0            8000.00188b717d72       no              vif2.0
>                                                         tap0
>                                                         peth0

Yeah, that looks like the description. What is tap0, a tape backup system?

> The second one:
> default via dev eth0


> I believe you get that src address if that route is discovered
> via ICMP router discovery. If it was given to you in DHCP or if you specified
> it in your ifcfg script with GATEWAY= then that probably wouldn't appear.

Hm. I didn't change anything in that area. The IP is set statically. It has a 
static private (on eth0:0) and a static public IP address (on eth0). The gateway
is set for the private IP on the firewall. There is no "discovery" AFAICS. And 
the other 5.1 (a Dom0) I compared is setup the same way just that the gateway
is the public one.
Could this be the cause, having different subnets? But, again, it's that way for 
some time ...
Just trying to compare with a VM that uses only private DHCP addresses, but just 
find that DHCP currently fails on it. I see dhcpd offering an IP, but the VM 
doesn't take it anymore. Hm. There still must be a networking problem somewhere.
My VMs with static IP work fine, though.

> The package doesn't even include the linux kernel. You will use the
> CentOS xen linux kernel, but everytime you install/upgrade the CentOS
> xen linux kernel you need to remember to edit your grub.conf to point
> the xen kernel to the xen 3.2 kernel instead of the xen 3.1 kernel
> that comes bundled with the CentOS xen linux kernel package.

I don't understand this. I have to admit I didn't take much effort to understand or 
investigate how Linux+Xen works. If I boot a different kernel I use a different 
kernel, don't I? Is /xen.gz-2.6.18-53.1.14.el5 the hypervisor? So, if I change to 
the 3.2 kernel I still have the same 5.1 CentOS kernel running the OS, just a 
different hypervisor? So, I can still use any updates to the Linux kernel? Just, 
if there is an (security) issue with the xen kernel I would need to wait for an 

> Yes 32-bit domUs run well on 64-bit dom0s, scripting works better of
> course. You have full access to all the Xen VM management using
> xenstore, for example add VMs to the store with 'xm new <config>'

Don't know yet the advantages of xenstore, documentation doesn't reveal much
about it and I surely don't want to program it's API ;-)

> then completely manage them through xm, xm start <name>, xm stop,
> and the VM will always be visible in 'xm list'

well, tiny advantage ;-)

Thanks, maybe I'll try 3.2, but first I have to troubleshoot that new DHCP problem 
on the VMs :-(


Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com