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@centos.org
http://lists.centos.org/mailman/listinfo/centos-virt
_______________________________________________
CentOS-virt mailing list
CentOS-virt@centos.org
http://lists.centos.org/mailman/listinfo/centos-virt
