Kai Schaetzl wrote: > 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". Wasn't necessarily talking qemu, just the comments about how the network bridging has changed... > > > > 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? No, it's a network TAP device for layer2 access to the network bridge. I have libvirt installed it probably is coming from there, maybe so when it brings up virbr0 it can tap into eth0 bridge. > > 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 ... Not sure what you mean? You mean you have your GATEWAY set to an IP outside your subnet? If so, then yes, your host is finding the default gateway for your subnet through router discovery and that explains the output. Set your interfaces GATEWAY to the IP address marked as the 'src' in ip route. > 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. Weird... > > 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 the hypervisor runs before the kernel is booted. Linux runs as a PV guest in domain0 with full access to the systems resources and manages those for the other domains. > > 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 ;-) Well you don't really have to program the API, but it allows your VMs to exist within the Xen database and to be managed by third party applications/interfaces that support the Xen 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 :-( Good luck. I would take a look at your primary interface setup, it sounds like it might be a little off. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.