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

2015-05-08 Thread Dan Kenigsberg
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
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2015-05-07 Thread Rik Theys

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.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users