[CentOS-virt] xenbr0 isn't created anymore

Wed Apr 2 02:03:27 UTC 2008
Richard Chapman <rchapman at aardvark.com.au>

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
>
>