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 10.1.3.1 dev eth0 Hm. > I believe you get that src 192.168.1.231 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 update? > 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 -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com