Hi Ross et al I noticed your comment about disabling dnsmasq below.... I am a relatively new Linux user... I have built Centos 4 and Centos 5 servers over the last year or so - but still have much to learn I'm sure. I am mostly using webmin to manage Centos. I am running (mostly) the non-xen kernel on a Centos 5 server. I have ISC DHCPd version 3.0.5 running on the Centos 5 box. I saw in the release notes for Centos 5 a comment about possible conflict between dnsmasq and DHCP servers. In my startup scripts - dnsmasq is set to "not start on boot" so I thought there was no problem - but I find that in spite of the startup script - dnsmasq appears to be running. As far as I can tell - the DHCP server is working as I want it to - so maybe I don't have a problem. It concerns me that dnsmasq appears to be running - and maybe it is sticking its nose in where I don't really want it to. I haven't found a config file for dnsmasq - so I don't know how or where it is configured. Can anyone tell me how the two DHCP servers will interact? Should I disable dnsmasq - and if so - how do I do this? Thanks Richard. Ross S. W. Walker wrote: > Kai Schaetzl wrote: > >> Ross S. W. Walker wrote on Mon, 31 Mar 2008 17:45:24 -0400: >> >> >>> It's not all port 67, the DHCP client sends DHCPREQ via UDP port 67 to >>> the broadcast address UDP port 68, the DHCP server responds with a >>> DHCPOFFER from it's IP address UDP port 68 to the clients broadcast >>> address UDP port 67. >>> >> Ah, many thanks. Ok, what happens is that the request appears on all interfaces >> but the reply goes out on peth0 only. And that never reaches the DomU on vifx.0. >> If I start libvirtd and then kill dnsmasq (as I want dhcpd to answer) the reply >> propagates further and DomU takes the IP address. There's obviously something in >> the routing/forwarding that the startup of libvirtd changes. Output of iptables >> -L suggests it adds a forwarding rule to forward from anywhere to anywhere. But >> that's not true. This seems to be a limitation of the iptables -L output: it >> doesn't show the interface (and I don't see a way to change this, if I try to >> specify an interface I get an error that thi9s is not allowed with -L). Well, I >> saved iptables and from that it seems that all the forwarding rules apply to >> virbr0 only. As virbr0 isn't attached to anything anymore these rules should be >> useless. libvirtd also adds NAT rules, but I don't see how these could affect >> this either. So, there might be something else needed. >> > > dnsmasq is going to filter out the incoming dhcp requests as it acts as a > dhcp server itself. Try disabling dnsmasq, or move your VMs off of virbr0 > onto xenbr0. > > >>> BTW I discovered that the tap devices are from qemu running in HVM >>> mode. In HVM qemu does the network emulation and uses the kernel >>> tun device for creating it's network interfaces. >>> >> Ah, I see. I'm not running fully virtualized. >> >> >>>> Thanks, I have looked at the patches, but they seem to be for something >>>> different. I checked if I can create a new VM with virt-manager and this >>>> fails in the network device step. But I think that's yet another bug, we >>>> already discussed here, there's also a patch for that. >>>> >>> If you can create a VM with virt-manager, then you don't have Xen 3.2 >>> installed or properly installed... >>> >> no, no, no. "I can create a new VM with virt-manager and this fails in the >> network device step". It cannot get any interfaces. I think there is a patch >> floating around for this, already mentioned on this list, but it's not the patch >> (es) you mentioned. Those two patches seem to apply to HVM only, so I shouldn't >> need them. If I wanted to create new VMs with virt-manager I would need to apply >> this other patch, though. >> > > Ok... > > >>> I never encountered this error. >>> >> I feared that :-( >> >> If you upgraded to Xen 3.2 did you upgrade >> >>> both the xen-3.2 and xen-libs-3.2 packages? Did you edit your grub config >>> too to load xen-3.2 as well? >>> >> Sure. I also installed xen-devel. Ahm, is that "xm new" supposed to do what I >> think or is it doing something else? I mean I understand that "xm new vmname" >> should take the VM of that name (identified by the existing config file of that >> name) and add it to the xenstore, so that I can "manage" from there. Meaning >> being able to use "start" (there's no stop?) and list it even when not running. >> > > Yes, 'xm new' adds a vm to the store and you can manage it via xm > or virsh. There is 'save', 'shutdown', 'destroy', 'suspend' all > having to deal with VM running state. > > >>> BTW xmlproc is handled completely in xend I believe, it all works >>> fine on my host and I have no python-xml installed! >>> >> Hm, may need to subscribe to the xen list ;-) >> > > I suggest it, there is definitely more traffic there. > > -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. > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt > >