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.