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

-----Messaggio originale----- Da: Dan Kenigsberg [mailto:danken@redhat.com] Inviato: martedì 7 luglio 2015 18:13 A: NUNIN Roberto; mst(a)redhat.com Cc: users(a)ovirt.org; ibarkan(a)redhat.com Oggetto: Re: R: R: R: R: R: [ovirt-users] R: PXE boot of a VM on vdsm don't read DHCP offer 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?