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

[Jorick Astrego]

On 07/29/2015 12:12 PM, NUNIN Roberto wrote:
>> -----Messaggio originale-----
>> Da: Michael S. Tsirkin [mailto:mst at redhat.com]
>> Inviato: mercoledì 29 luglio 2015 12:03
>> A: NUNIN Roberto
>> Cc: Fabian Deutsch; users at ovirt.org
>> Oggetto: Re: R: [ovirt-users] R: R: R: R: R: R: PXE boot of a VM on vdsm don't
>> read DHCP offer
>>
>> On Wed, Jul 29, 2015 at 12:00:38PM +0200, NUNIN Roberto wrote:
>>>> -----Messaggio originale-----
>>>> Da: users-bounces at ovirt.org [mailto:users-bounces at ovirt.org] Per conto
>> di
>>>> Michael S. Tsirkin
>>>> Inviato: giovedì 9 luglio 2015 15:15
>>>> A: Fabian Deutsch
>>>> Cc: users at ovirt.org
>>>> Oggetto: Re: [ovirt-users] R: R: R: R: R: R: PXE boot of a VM on vdsm don't
>> read
>>>> DHCP offer
>>>>
>>>> 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.
>>> Someone is checking this ?
>>> In tested config SPT was off.
>> Then maybe you have a loop :)
> That was already checked, the MAC was unique in the VLAN.
>
> RN
>

Did you also try a reboot of the VM? We have the same issue with foreman
and both Libvirt and oVirt. On second boot PXE boots properly from DHCP.

Haven't had the time to investigate yet so we're using mostly image
based provisioning on oVirt at the moment.





Met vriendelijke groet, With kind regards,

Jorick Astrego

Netbulae Virtualization Experts 

----------------

	Tel: 053 20 30 270 	info at netbulae.eu 	Staalsteden 4-3A 	KvK 08198180
 	Fax: 053 20 30 271 	www.netbulae.eu 	7547 TA Enschede 	BTW NL821234584B01

----------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150729/ea9992b7/attachment-0001.html>