[CentOS-virt] xenbr0 isn't created anymore

Tue Apr 1 14:16:38 UTC 2008
Ross S. W. Walker <rwalker at medallion.com>

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.