[ovirt-users] R: PXE boot of a VM on vdsm don't read DHCP offer
Dan Kenigsberg
danken at redhat.com
Fri May 8 06:08:24 EDT 2015
On Thu, May 07, 2015 at 06:01:14PM +0200, NUNIN Roberto wrote:
> Further info about this case:
>
> An already installed and running VM (Centos7) with static IPv4 assignment, if changed to DHCP mode, do not acquire the IP address.
>
> In this case, tcpdump taken on the VM, do not show DHCP offer packets that are instead seen on the host bond interface.
> Seems that something is filtering DHCP offers between host physical eth interfaces and VM virtio eth interface.
> Physical servers on the same VLAN keep DHCP offers and boot from PXE correctly.
>
> Roberto
>
>
>
> >Hi all
>
> >We are using oVirt engine 3.5.1-0.0 on Centos 6.6
> >We are deploying two hosts with vdsm-4.16.10-8.gitc937927.el7.x86_64
> >No hosted-engine, it run on a dedicates VM, outside oVirt.
>
> >Behavior: PXE boot of a VM, ends in timeout (0x4c106035), instead to accept the DHCP offer coming from DHCP server.
> >Tcpdump capture started on the vdsm host, bond0 interface shows clearly that DHCP offers reach the vdsm interfaces >three times before PXE client ends in timeout.
> >Incoming DHCP offer is correctly tagged when it comes to the bond0 interface and forwarded to the bond0.bridge >interface.
> >PXE simply ignore it. PXE version is gPXE 0.9.7.
> >bond0.bridge interface is already setup with STP=off and DELAY=0.
>
> >If we install a VM using command line boot parameters, VM install & run fine. The issue is only related to PXE process, >when it is expected to use the DHCP offer.
>
> >I can provide tcpdump capture, but I've not attached to the email because I'm quite new of the community and don't >know if it is allowed/correct.
>
> >On another host, under the same engine, running vdsm-4.16.12-7.gita30da75.el6.x86_64 on Centos6.6, this behavior is >not happening, everything works fine.
>
> >Any idea/suggestion/further investigation ?
> >Thanks for attention
> >Best regards
Which kernel does the el7 host run? I think that Ido has seen a case
where `brctl showmacs` was not populated with the VM mac, despite a
packet coming out of it.
Can you tcpdump and check whether the bridge propogated the DHCP offer
to the tap device of the said VM? Does the packet generated by
`ether-wake MAC-of-VM` reach the tap device?
>
>
> Roberto Nunin
> Infrastructure Manager
> Italy
>
>
> Here are interfaces configs:
> eno1:
> DEVICE="eno1"
> HWADDR="38:63:bb:4a:47:b0"
> MASTER="bond0"
> NM_CONTROLLED="no"
> ONBOOT="yes"
> SLAVE="yes"
> eno2:
> DEVICE="eno2"
> HWADDR="38:63:bb:4a:47:b4"
> MASTER="bond0"
> NM_CONTROLLED="no"
> ONBOOT="yes"
> SLAVE="yes"
> bond0:
> BONDING_OPTS="mode=4 miimon=100"
> DEVICE="bond0"
> NM_CONTROLLED="no"
> ONBOOT="yes"
> TYPE="Bond"
> bond0.3500:
> DEVICE=bond0.3500
> VLAN=yes
> BRIDGE=DMZ3_DEV
> ONBOOT=no
> MTU=1500
> NM_CONTROLLED=no
> HOTPLUG=no
> DMZ3_DEV:
> DEVICE=DMZ3_DEV
> TYPE=Bridge
> DELAY=0
> STP=off
> ONBOOT=no
> MTU=1500
> DEFROUTE=no
> NM_CONTROLLED=no
> HOTPLUG=no
>
More information about the Users
mailing list