Re: [ovirt-users] R: 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-boun...@ovirt.org [mailto:users-boun...@ovirt.org] Per conto di Michael S. Tsirkin Inviato: giovedì 9 luglio 2015 15:15 A: Fabian Deutsch Cc: users@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 vnet ? 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 :) RN -- MST ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users 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: R: R: R: R: R: PXE boot of a VM on vdsm don't read DHCP offer
-Messaggio originale- Da: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] Per conto di Michael S. Tsirkin Inviato: giovedì 9 luglio 2015 15:15 A: Fabian Deutsch Cc: users@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 vnet ? 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. RN -- MST ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users 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: R: R: R: R: R: PXE boot of a VM on vdsm don't read DHCP offer
-Messaggio originale- Da: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] Per conto di Michael S. Tsirkin Inviato: giovedì 9 luglio 2015 15:15 A: Fabian Deutsch Cc: users@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 vnet ? 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. I've the tcpdump captures, let me know if are useful to analyze. In the VLAN interface, STP=off. RN -- MST ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users 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: R: R: R: R: R: PXE boot of a VM on vdsm don't read DHCP offer
-Messaggio originale- Da: Michael S. Tsirkin [mailto:m...@redhat.com] Inviato: mercoledì 8 luglio 2015 08:12 A: Dan Kenigsberg Cc: NUNIN Roberto; users@ovirt.org; ibar...@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 vnet ? 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. I have both tcpdump capture, on the bridge interface and on the vnet interface. How I can upload output files ? Sorry for probably obvious question, first time for me :) Roberto Nunin Likely something interfered with them so the eth address is wrong. Since bonding does this sometimes, this is the most likely culprit. -- MST 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: R: R: R: R: R: PXE boot of a VM on vdsm don't read DHCP offer
-Messaggio originale- Da: Dan Kenigsberg [mailto:dan...@redhat.com] Inviato: martedì 7 luglio 2015 18:13 A: NUNIN Roberto; m...@redhat.com Cc: users@ovirt.org; ibar...@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 vnet ? 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 ? It is 3.10.0-229.7.2.el7.x86_64 on the host with installed Centos7.1, update, then vdsm It is 3.10.0-123.20.1.el7.x86_64 on the host installed with vdsm iso Both hosts show the issue 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? 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
