On Wed, Jun 14, 2017 at 05:58:06PM -0000, Ryan Harper wrote:
> This is a known issue w.r.t waiting for IPV6 LL, on Xenial KVM, qemu -net
> user does not provide IPV6 LL response (yakkety and newer do), so there's a
> delay; it does sound like the IPV6 LL timeout is longer than it used to be
> as I've seen a 5 to 10 second delay in VMs launched on KVM on xenial, but
> not a full 120 seconds which breaks the wait-online.
If it were just a delay, networkd should still eventually recognize the
device as configured. Maybe some packets are going missing? We probably
need a network trace from within the guest.
Also probably interesting to know if 'sudo service networkd-resolved
restart' changes the state of things, or if the device remains
'configuring'.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>
On Wed, Jun 14, 2017 at 05:58:06PM -0000, Ryan Harper wrote:
> This is a known issue w.r.t waiting for IPV6 LL, on Xenial KVM, qemu -net
> user does not provide IPV6 LL response (yakkety and newer do), so there's a
> delay; it does sound like the IPV6 LL timeout is longer than it used to be
> as I've seen a 5 to 10 second delay in VMs launched on KVM on xenial, but
> not a full 120 seconds which breaks the wait-online.
If it were just a delay, networkd should still eventually recognize the
device as configured. Maybe some packets are going missing? We probably
need a network trace from within the guest.
Also probably interesting to know if 'sudo service networkd-resolved
restart' changes the state of things, or if the device remains
'configuring'.
-- www.debian. org/
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://
<email address hidden> <email address hidden>