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

-----Messaggio originale----- Da: Michael S. Tsirkin [mailto:mst@redhat.com] Inviato: mercoledì 8 luglio 2015 08:12 A: Dan Kenigsberg Cc: NUNIN Roberto; 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 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. -- MST