Re: [ovirt-users] R: R: PXE boot of a VM on vdsm don't read DHCP offer
On Fri, May 08, 2015 at 03:11:25PM +0200, NUNIN Roberto wrote: > Hi Dan > Thanks for answering > > > > > 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. > > Kernel is: 3.10.0-123.20.1.el7.x86_64, package is vdsm only. Brctl isn't > available within vdsm only package. Could you try upgrading to a more up-to-date http://mirror.centos.org/centos-7/7.1.1503/updates/x86_64/Packages/kernel-3.10.0-229.4.2.el7.x86_64.rpm ? bridge-utils is a vdsm dependency. It must exist on your host. Please see if the mac of the vNIC shows up on `brctl showmacs` as it should. > > > > 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? > > Yes: host "see" the broadcast : > 0.000.0.0.0 255.255.255.255 DHCP 346 > DHCP Discover - Transaction ID 0x69267b67 > It came from the right MAC: > Source: Qumranet_15:81:03 (00:1a:4a:15:81:03) > And it is tagged correctly: > 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 3500 > > This is the offer, on the bond interface: > 1.01235510.155.124.2 10.155.124.246DHCP 346 > DHCP Offer- Transaction ID 0x69267b67 > Layer 2 info: > Ethernet II, Src: Cisco_56:83:c3 (84:78:ac:56:83:c3), Dst: > Qumranet_15:81:03 (00:1a:4a:15:81:03) > Tagging on the bond: > 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 3500 > > The tag is correctly removed when DHCP offer is forwarded over the bond.3500. > Here's the offer content, seems everything right: > > Client IP address: 0.0.0.0 (0.0.0.0) > Your (client) IP address: 10.155.124.246 (10.155.124.246) > Next server IP address: 10.155.124.223 (10.155.124.223) > Relay agent IP address: 10.155.124.2 (10.155.124.2) > Client MAC address: Qumranet_15:81:03 (00:1a:4a:15:81:03) > Client hardware address padding: > Server host name: 10.155.124.223 > Boot file name: pxelinux.0 > Magic cookie: DHCP > > Nothing of this offer appear on the VM side. But does it show on the host's bridge? on the tap device? > > ether-wake -i bond0.3500 00:1a:4a:15:81:03 (started from the host) > reach the VM eth0 interface: > 2.002028 HewlettP_4a:47:b0 Qumranet_15:81:03 WOL 116 > MagicPacket for Qumranet_15:81:03 (00:1a:4a:15:81:03) > > Really strange behavior. > > Roberto ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] R: R: PXE boot of a VM on vdsm don't read DHCP offer
Hi Dan Thanks for answering > 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. Kernel is: 3.10.0-123.20.1.el7.x86_64, package is vdsm only. Brctl isn't available within vdsm only package. > > 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? Yes: host "see" the broadcast : 0.000.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x69267b67 It came from the right MAC: Source: Qumranet_15:81:03 (00:1a:4a:15:81:03) And it is tagged correctly: 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 3500 This is the offer, on the bond interface: 1.01235510.155.124.2 10.155.124.246DHCP 346 DHCP Offer- Transaction ID 0x69267b67 Layer 2 info: Ethernet II, Src: Cisco_56:83:c3 (84:78:ac:56:83:c3), Dst: Qumranet_15:81:03 (00:1a:4a:15:81:03) Tagging on the bond: 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 3500 The tag is correctly removed when DHCP offer is forwarded over the bond.3500. Here's the offer content, seems everything right: Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 10.155.124.246 (10.155.124.246) Next server IP address: 10.155.124.223 (10.155.124.223) Relay agent IP address: 10.155.124.2 (10.155.124.2) Client MAC address: Qumranet_15:81:03 (00:1a:4a:15:81:03) Client hardware address padding: Server host name: 10.155.124.223 Boot file name: pxelinux.0 Magic cookie: DHCP Nothing of this offer appear on the VM side. ether-wake -i bond0.3500 00:1a:4a:15:81:03 (started from the host) reach the VM eth0 interface: 2.002028 HewlettP_4a:47:b0 Qumranet_15:81:03 WOL 116 MagicPacket for Qumranet_15:81:03 (00:1a:4a:15:81:03) Really strange behavior. Roberto Questo messaggio e' indirizzato esclusivamente al destinatario indicato e potrebbe contenere informazioni confidenziali, riservate o proprietarie. Qualora la presente venisse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e distruggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potrebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately, deleting the original and all copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] R: R: PXE boot of a VM on vdsm don't read DHCP offer
Hi Rick No, DHCP is provided by an external appliance. Thanks for answering ! Roberto -Messaggio originale- Da: Rik Theys [mailto:rik.th...@esat.kuleuven.be] Inviato: giovedì 7 maggio 2015 20:46 A: NUNIN Roberto Cc: users@ovirt.org Oggetto: Re: [ovirt-users] R: PXE boot of a VM on vdsm don't read DHCP offer Hi, Is your DHCP server a VM running on the same host? I've seem some strange issues where a VM could not obtain a DHCP lease if it was running on the same physical machine as the client. If this is the case, I can look up what I had to change, otherwise ignore it. Regards, Rik > 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 > > > > > > 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 > > > > > > > > > ___ > Questo messaggio e' indirizzato esclusivamente al destinatario indicato e > potrebbe contenere informazioni > confidenziali, riservate o proprietarie. Qualora la presente venisse ricevuta > per errore, si prega di segnalarlo > immediatamente al mittente, cancellando l'originale e ogni sua copia e > distruggendo eventuali copie cartacee. Ogni > altro uso e' strettamente proibito e potrebbe essere fonte di violazione di > legge. > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise private > information. If you have received it in error, please notify the sender > immediately, deleting the original and all > copies and destroying any hard copies. Any other use is strictly prohibited > and may be unlawful. > > Questo messaggio e' indirizzato esclusivamente al destinatario indicato e potrebbe contenere informazioni confidenziali, riservate o proprietarie. Qualora la presente venisse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e distruggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potrebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately, deleting the original and all copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.
