On Wed, Dec 7, 2016 at 2:36 PM, Leon Goldberg <lgoldber@redhat.com> wrote:

Hey,

I suspect there's an issue where the current configuration of o-s-t (I've only tried basic-suite-4.0, but I guess it is not suite related), and more specifically dnsmasq's dhcp configuration under Lago/o-s-t (or otherwise) fails to serve VLAN interfaces.

Lago (and specifically libvirt from Lago) is providing DHCP - at least to the L1 hosts. I believe L2 (the VMs) are not being served - would be interesting to see if they can get an IP. Perhaps we need to remove the (default?) no mac spoofing network filter? Not even sure if we handle it!

Need to see how the Hosted-Engine VM (now going back to o-s-t) does work - it is defined on the Lago Init file (so libvirt is 'aware' of it, for example).

After successfully running basic-suite-4.0, I'm trying to call dhclient to serve eth0.600 on host0 (created in 005_network_by_label), which fails. DHCPDISCOVER(s) are reaching the bridge dnsmasq listen on, however no offers are being sent.

A couple of things I've tried and the relevant conclusions:

1) After hotplugging a nic (eth1) on host0 via virsh (using the same source network/bridge), I've set a VLAN interface on top of it (eth1.600). Calling dhclient for eth1 worked; eth1.600 failed. I've tried this to rule out the cause being some configuration used in 005_network_by_label.

2) I've added a veth pair, with veth0 being added to Lago's bridge, and with having a VLAN interface (using the same ID) on top of veth1 (veth1.600)

dnsmasq was set to listen on/serve veth1.600 without any success, although the VLAN tag is effectively removed. Similarly, DHCPDISCOVER(s) are being received, without any offers being sent. After setting an address manually on eth0.600, I was able to ping veth1.600 <-> eth0.600.

Thanks,
Leon

_______________________________________________
lago-devel mailing list
lago-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/lago-devel