[CentOS-virt] xenbr0 isn't created anymore
rchapman at aardvark.com.au
Wed Apr 2 02:03:27 UTC 2008
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?
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.
>>> 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.
> 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
More information about the CentOS-virt