10:10 a.m.
On Wed, Dec 7, 2016 at 2:36 PM, Leon Goldberg <lgoldber(a)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).
Y.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/lago-devel