[ovirt-users] R: R: R: R: R: R: PXE boot of a VM on vdsm don't read DHCP offer

[Michael S. Tsirkin]

On Thu, Jul 09, 2015 at 08:57:50AM -0400, Fabian Deutsch wrote:
> ----- Original Message -----
> > On Wed, Jul 08, 2015 at 09:11:42AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Jul 07, 2015 at 05:13:28PM +0100, Dan Kenigsberg wrote:
> > > > On Tue, Jul 07, 2015 at 10:14:54AM +0200, NUNIN Roberto wrote:
> > > > > >
> > > > > > On Mon, Jul 06, 2015 at 10:33:59AM +0200, NUNIN Roberto wrote:
> > > > > > > Hi Dan
> > > > > > >
> > > > > > > Sorry for question: what do you mean for interface vnetxxxx ?
> > > > > > > Currently our path is :
> > > > > > > eno1 - eno2  ---- bond0 ----- bond.3500 (VLAN) ------ bridge -----
> > > > > > > vm.
> > > > > > >
> > > > > > > Which one of these ?
> > > > > > > Moreover, reading Fabian statements about bonding limits, today I
> > > > > > > can try
> > > > > > to switch to a config without bonding.
> > > > > >
> > > > > > "vm" is a complicated term.
> > > > > >
> > > > > > `brctl show` would not show you a "vm" connected to a bridge. When
> > > > > > you
> > > > > > WOULD see is a vnet888 tap device. The "other side" of this device is
> > > > > > held by qemu, which implement the VM.
> > > > > 
> > > > > Ok, understood and found it, vnet2
> > > > > 
> > > > > >
> > > > > > I'm asking if the dhcp offer has reached that tap device.
> > > > > 
> > > > > No, the DHCP offer packet do not reach the vnet2 interface, I can see
> > > > > only DHCP DISCOVER.
> > > > 
> > > > Ok, so it seems that we have a problem in the host bridging.
> > > > 
> > > > Is it the latest kernel-3.10.0-229.7.2.el7.x86_64 ?
> > > > 
> > > > Michael, a DHCP DISCOVER is sent out of a just-booted guest, and OFFER
> > > > returns to the bridge, but is not propagated to the tap device.
> > > > Can you suggest how to debug this further?
> > > 
> > > Dump packets including the ethernet headers.
> > > Likely something interfered with them so the eth address is wrong.
> > > 
> > > Since bonding does this sometimes, this is the most likely culprit.
> > 
> > We've ruled this out already - Roberto reproduces the issue without a
> > bond.
> 
> To me this looks like either a regression in the host side bridging. But otoh it doesn't look
> like it's happening always, because otherwise I'd expect more noise around this issue.
> 
> - fabian

Hard to say. E.g. forwarding delay would do this for a while.
If eth address of the packets is okay, poke at the fbd, maybe there's
something wrong there. Maybe stp is detecting a loop - try checking that.

-- 
MST